Да, вы правы. Я как-то попробовал сделать через Remove() у коллекции - записи не удалились, поэтому пошел другим путем.
Наверное что-то не так пробовал, сейчас все ок :)
Спасибо, поправил. Это я боролся с тем как лучше в хабр код вставлять..
PS. В сети столько хороших конвертеров C# to HTML, а на хабре ними и не воспользуешься.. (
Спасибо.
Не знаю, может что-нить придумаю, скриншотами неудобно будет, а читабельность действительно никакая сейчас.. Да и на форматирование всего этого много времени уходит. Несовсем удобно сделано..
Помучился я немного, но похоже код на хабр никак красиво не запостить, сильно ограничение наложено на HTML. + непонятно почему если ставишь флаг "отключить форматирование HTML", то оно все равно половину заменяет на свое усмотрение.. :(
Не знаю всех тонкостей Хабра, но в голове крутится мысль о ссылке на исходники. Ну или внешние пэйджы с отформатированным кодом.
Но сразу же проблема хостинг. Если в первом случае достаточно какого-нибудь ifolder'a, то во втором сложнее.
Так тоже не совсем удобно будет, прийдется постоянно переключаться между окнами, что с мысли сбивает.
Нужно действительно до завтра подождать, вдруг что изменится в эту сторону.
Если убрать в авторском коде new перед конструкторами, то получится практически Lisp. Ждем окончательной победы функционального программирования в C# 4.0 (и Java 2.0) :)
Мне кажется существует большое количество .net разработчиков, которые читают хабр, но не понимая ничего в php, python, apache и ubuntu c linux, темах которые главенствуют на сайте, молчат в тряпочку. Конкретный пример - я. Хабр читаю, что-то около полугода. Решил зарегистрироваться только сегодня, когда увидел новый блог ".NET". Теперь, когда накоплю достаточно кармы, намерен пописывать опусы про интересные вещи в .net.
Три замечания. Во-первых, в C# 3.0 есть "var". Во-вторых, анонимные типы. И, наконец, foreach(var track in tracks) читается лучше, нежели foreach (XElement t in tracks)
Статья ведь о том, как с XML работать, и я попытался её не перегрузить проекцией на типы, трансформацией и т.д. Именно поэтому и использовался XElement, для наглядности.
Не совсем понял, вам не понравилось однобуквенное название переменной? Это уж на вкус и цвет. У меня циклы все на одну две строчки кода, в таких случаях абсолютно не вижу никакой необходимости писать длинные названия переменных. Если код итерации более объемный, то, безусловно, с вами соглашусь.
Не соглашусь насчет того, что var в данном контексте читается лучше. Считаю, что указание конкретного типа в foreach - это признак хороший тона хотя бы потому, что тогда контекст итераций будет самодостаточным. Разбирая в дальнейшем тело цикла не нужно будет искать определение tracks. Особенно это актуально для тяжелых циклов. Это мое личное мнение, дело вкуса. Я сам стараюсь использовать var в основном для промежуточного буфера. Например, когда LINQ-строка уже слишком длинная, но необходимо все же произвести еще какие-то действия типа ToList или Remove.
Ввела в ступор дата регистрации ваша. Подумал, что из будущего не обратил внимание на год. :)
Вообще с XML и старыми методами довольно таки неплохо работать, только более объемно как-то получалось.
PS. А карма.. не знаю.. было бы когда материал готовить.
Наверно дело в том, что в боевых условиях я полноценно с xml не работал. Сейчас использую только как хранилище алиасов для enum'ов а там сериализация. А вот как-то с ходу написать (или по крайней мере придумать как написать) helper для xml файлов не получается.
Про будущее сам пугаюсь в этом месяце =)
А про карму: поделиться про логирование в экстэншенах хочется. =)
Сбило с толку не подключенная System.Linq в начале кода.
Пожалуйста, явно указывайте новые пространства имён, а то я с 3.5 фреймворком только начинаю разбираться :).
Да, C# неплохо развивается. Для любознательных: в динамических языках можно создать XML ИМХО ещё проще и красивее. Например в Groovy с помощью builders (прошу прощения за некрасивый вид - code не работает):
writer = new StringWriter()
builder = new groovy.xml.MarkupBuilder(writer)
invoices = builder.invoices {
for(day in 1..3) {
invoice(date: new Date(106,0,day)){
item(count:day){
product(name:'ULC', dollar:1499)
}
}
}
}
На выходе получаем:
<invoices>
<invoice date='Sun Jan 01 00:00:00 CET 2006'>
<item count='1'>
<product name='ULC' dollar='1499' />
</item>
</invoice>
<invoice date='Mon Jan 02 00:00:00 CET 2006'>
<item count='2'>
<product name='ULC' dollar='1499' />
</item>
</invoice>
<invoice date='Tue Jan 03 00:00:00 CET 2006'>
<item count='3'>
<product name='ULC' dollar='1499' />
</item>
</invoice>
</invoices>
Вызов метода = создание элемента, параметры метода = атрибуты.
Да, сейчас в эту сторону активно все движется. В VB вообще XML поддерживается прямо из кода. Чем-то это программирование напомнило старый добырй ASP, только наоборот :)
Уже готовлю материал по LINQ to SQL ;) Не знаю правда насколько меня хватит во время рабочей недели, но радует, что грядут выходные снова :)
У меня тоже старые проекты под 2.0. В общем-то ничего, живут потихоньку, и я вместе с ними. В 2.0 очень жизнь облегчает по работе с данными Enterprice Library Data Application Block. Очень советую, если ещё не пользуетесь.
DAB это, простите, жуть и тот факт, что он входит во "фреймворк" в названии которого фигурирует магическое "Enterprise", лучше его не делает. Посмотрите лучше в сторону NHibernate/BLToolkit.
Да нестрашно :)
Мое мнение ведь не единственно правильное.
Вообще я DAAB изначально начал использовать как только перешел от ручного кодирования, мои задачи эта библиотека выполняла вполне нормально. Насколько я понял предложенные вами - это ORM решения, а это для меня было немного с избытком. У DAAB и NHibernate, на мой взгляд, немного разные сферы применения изначально.
BLToolkit может, а NHibernate ORM.
Возможно мне не повезло, что оно мне первым не попалось. Говорю без иронии. Просто все время разбираться с новыми библиотеками тоже не правильно. По NHibernate в свое время не нашел какой-то хорошей статьи с обзором возможностей, в общем не зацепило тогда когда смотрел.
Не хотите написать краткий обзор? :) Я думаю тема интересна многим будет.
Воо, здорово! LINQ - это однозначно будущее .NET. Спасибо за статью, я надеюсь многих .NET-чиков, которые еще не пользуются, заставит задуматься о том, что стоит попробовать LINQ ;)
Можно еще удалить все записи и в функциональном стиле: :-)
<pre>
doc.Root.Descendants ( "track" ).Where (
t => t.Element("artist").Value == "DMX").ToList ( ).ForEach (
t => t.Remove ( ) );
<pre></code>
В работе как-то не приходилось писать такое, но для сортировки треков по длине названия получилось следующее:
1. Нужно создать свой класс, реализующий интерфейс IComparer<>:
class MyComparer<T> : IComparer<string>
{
public int Compare(string x, string y)
{
return x.Length.CompareTo(y.Length);
}
}
2. Отсортировать треки, используя наш компарер:
var tracks = doc.Root.Elements("track").OrderBy(x => x.Element("name").Value, new MyComparer<string>());
Первым параметров в OrderBy передаем, используя лямбда выражения, то, по чему мы хотим отсортировать наши записи. Вторым - экземпляр класса MyComparer, который мы только что описали.
Уж сори, что пишу код простым текстом, но ни poison.qsh.ru корректно не работает, и хабр че-то начал теги жевать. Думаю вы разберетесь что к чему ;)
Работаем с LINQ to XML