Цитата:

нужен продвинутый редактор данных (точнее, визард, который помогает редактировать)

каким образом тут хмл поможет???

Цитата:

нужен анализ данных (контента страницы)

опять таки - зачем хмл? анализ на пхп не пойдет?

Цитата:

нужен анализ структуры (дерева сайта)

чем хуже анализ на пхп?
если анализ должен происходить в момент сборки конечной страницы - переложить работу на обработчик.
не не вижу я тут разницы. по большому счету - делать нужно так как удобнее. но я пока задач, в которых удобнее на хмл реализовывать было бы я не встречал (за исключением - обмена данными, тут однозначно лучше хмл не придумать).

ЗЫ. Можно конечно, но в программе было только "рассчитать" - выводится диалоговое окно с параметрами и "выход". Так что реализация того, что ты предлагаешь было бы ну совсем не уместно

Long,
Редактор контента нужен именно для его разработки, и редактирования. Это не просто текст и картинки вогнать, в этом и разница. Визард должен уметь помогать подбирать материал: картинки, страницы, на которые сошлется этот документ и т.п. XML здесь поможет в нескольких аспектах:
- Строгого представления данных контента. Это именно не единый блок контента страницы, а несколько, разнотипных, со своей структурой. Намного легче парсить.
- С помощью XML можно отличить однотипные данные, такие как, например, различные куски текста. То есть если в HTML текст - просто текст со стандартными тэгами, то с помощью XML представляется, например, возможным отдельно обозначить куски текста, имеющие разное значение, смысл, специфику, сложность - именно отталкиваясь от предметной области ресурса. Т.е. существует механизм эту структуру описать, и стандартными средствами разобрать.

Анализ на PHP не подойдет не потому, что этого нельзя запрограммировать на PHP, а потому, что не будет нужного представления данных. Или его придется реализовывать как самопальный механизм.

Я же говорю, что разница именно в том, что разработка контента, проектирование - тоже у меня. В этом отличие. Дело не в сборке конечной страницы, и не в том, как удобнее дизайнить представление. Это меня волнует меньше всего, т.к. XHTML страницу уж соберем, а XSL, или шаблон, или черта лысого я уж как-нить из готового дизайна сделаю. Или вообще напишу представление сам сразу в этом формате. Не вопрос.

Вопрос в представление и обработке контента - сложных текстовых (в основном) данных.

ЗЫ. Уместно, более того, намного проще. ООП очень сильно рулит в прикладной математике, а особенно в ее расчетной части. Что совершенно даже и неудивительно.

@TSV, все равно не въезжаю зачем хмл тебе. ну да ладно, для этого нужно в задачу вникать. а вникать, чесно говоря, некогда.

ЗЫ. Не, вычисления по одной формуле, пусть и сложной, цепочки значений проще без ООП сделать

Long, да ладно, там действительно надо контекстный юмор знать, не буду грузить.

ЗЫ. Ничё подобного. И проще, и нагляднее, и модифицируется на ура.
Некоторые из используемых механизмов:

1. Абстрактный класс TFunction, с кучей методов, которые нужны всегда, типа интеграл по полиномам Чебышева взять, график нарисовать - все, что нужно, короче говоря.
- virtual double operator () (double x) const; Абстрактный метод.
- class myFunction : public TFunction, переопределяем оператор ()
- myFunction f(coeff1,coeff2,coeff3);
- y = f(x);
- z = f.Integral(a,b);
- q = f.max(a,b);
- f.drawGraph(graphicDevice,a,b);

2. Перегрузка операторов - вообще первое дело.
// Решение системы линейных уравнений Ax = y, A - матрица, x и y - вектора.
x = y / A;

Ты небось, просто не пробовал.

@TSV, еще раз повторюсь - вычисляется одна единственная функция и результат в файл сохраняется. писать для этого класс - это микроскопом гвозди заколачивать.

Long, тады ой.

Хотя нет, не совсем ой. Всё равно проще. Это заблуждение, что нужно дополнительные усилия применять, если делать с помощью класса. Усилий - меньше. Тут скорее дело в привычке.

@TSV писал(а):

x = y / A

смИшно.

Long писал(а):

@TSV, еще раз повторюсь - вычисляется одна единственная функция и результат в файл сохраняется. писать для этого класс - это микроскопом гвозди заколачивать.

это нормальный подход ООП, когда нет ничего, кроме классов.

Original Demon, чё ж такого смешного там нашел? То, что все эти матрицы и векторы - мои, и я примерно знаю, что там лежит, не забыл?

Original Demon, нормальный подход - микроскопом гвозди закалачивать?

Long, о том и речь, что ООП - не микроскоп, а универсальный инструмент. Просто кому им удобно пользоваться для решения всех задач в программировании, и простых, и сложных, а кому - нет. Дело привычки.

@TSV, я разве говорю, что микроскопом не получится забить гвоздь? получится. только, имхо, надо применять инструмент именно там, где он подходит, а не там, где его можно использовать.

Long, ООП != микроскоп; ООП == универсальный_инструмент.
Хочешь - дай пример, который, для которого, по-твоему, ООП не подходит.
А я покажу, почему мне, например, ООП в данном случае подходит.
Просто чтобы не быть голословным.
ЗЫ. Дело в привычке, и только в ней.

@TSV, привычка - это не правильный подход. правильный подход - использовать тот инструмент, который для решения более всего подходит. дело не том можно ли ООП применять к конкретной задаче, а втом на сколько решение на базе ООП подходит к задаче.
для примера того о чем я говорю - из другой области - можно применять пхп для написания поисковой машины аналогичной по мощьности яндексу? можно. на сколько применимо данное решение? применимо только для представления обработанных результатов. понимаешь о чем я?

Long, понимаю и согласен, но речь идет вообще-то о другом.

или (зачем далеко ходить?) - http://www.deforum.ru/forum/viewtopic.php?t=20436 нужно применять тот инструмент который для решения больше подходит.

@TSV, ну речь, если быть честным, в самом топике шла совсем о другом. и совсем не о том, о чем я или ты говорили последние n-постов я думаю, что автор темы простит наш офтоп

Long, обратно неправильное сравнение. Речь идет о том, применять ООП или нет. На примере, который рассматривался выше - писать вычислительную программу на основе функций C (процедурно) или с помощью классов C++. Второй способ (1)применим, (2)подходит, (3)удобнее.

Long, тем более, что, если по-честному, это не совсем уж и оффтоп.

@TSV, применим твои рассуждения к забиванию микроскопом гвоздя. способ применим, подходит (ведь забивается же!), удобнее (а чего, держать удобно, да и масса микроскопа побольше среднего молотка )

Long, нет, лучше не так. Давай применим к сравнению двух отверток: (1) простой крестовой (2) с обрезиненной ручкой, чтобы не скользила в руке, и с кучей насадок (особенно подчеркиваю, что такая же крестовая - тоже есть). Или к написанию вычислительной программы.

@TSV, ты предлагаешь гвоздь отверткой забивать?

Long, молотком. А шурупчики заворачивать - отверткой.
К ООП достаточно перестать относиться как к какому-то очень навороченному механизму, и просто начать рассматривать как обыденный инструмент. Навороченность и сложность применения, что харАктерно, сразу куда-то девается. А удобство в обыденном применении - остаётся. Я ж грю - давай разберем на любом конкретном примере, если хочешь.

@TSV, я к ООП отношусь как к любому инструменту - он должен применяться там, где это целесобразно. хочешь пример? пожалуста. вывести на экран "Hello, world!" помнишь тему в общем "эволюция программиста"?

Long, А над темой про эволюцию - да, ржал долго.

@TSV, а где определение класса?
если серьезно, то надо не только смеятся над тем, что в той теме было. но после того, как посмеялся задуматься о том, что часто мы применяем не те инструменты для решения задачи. и я думаю, что это было главной задачей того, кто писал "код", показать именно это, а уж на втором месте - рассмешить.

Long,
- #include <iostream> // там
- угу, согласен абсолютно. Только ведь ООП - если быть точным, не инструмент, а подход. Языковые средства, которые его поддерживают - вещь отдельная. То есть, грубо говоря, это не "class foo { … }", а правильная декомпозиция и иже с ними.

инструмент более широкое понятие. именно поэтому я его и использую, ведь утверждение об использовании правильного инструмента касается не только программирования.

Long, пусть будет инструмент. В рассмотренном примере данный инструмент оказался весьма удобен. Ощущения забивания микроскопом гвоздя не возникло. М.б. это можно ощутить на другом примере? Хотя я всё равно подозреваю, что устойчивого сильного ощущения достичь не удастся.

@TSV, если не возникло, очень жаль прежде всего потому, что именно из-за отсутствия этого чувства начинают выростать те монстровые коды, которые были в теме про эволюцию или возникать вопросы - чем лучше рисовать - карандашем на бумаге или на планшете.

Long, не-а. Те монтруозные коды, которые в "эволюции", это просто не OOP (Object Oriented Programming). Это LMCSA (Lamerris Marrazzmus Coding Style & Architecture).
А ООП совсем не такой.

@TSV писал(а):

Original Demon, чё ж такого смешного там нашел? То, что все эти матрицы и векторы - мои, и я примерно знаю, что там лежит, не забыл?

смешно то, что матричное уравнение не так решается.

Long писал(а):

Original Demon, нормальный подход - микроскопом гвозди закалачивать?

в C++ у тебя еще был выбор: использовать классы или написать процедуру. в C# этого выбора уже нет - только классы. то же в Java, если не ошибаюсь.

так что вопрос даже так не стоит "использовать ли микроскоп?". ничего кроме микроскопа нет.

@TSV писал(а):

Long, не-а. Те монтруозные коды, которые в "эволюции", это просто не OOP (Object Oriented Programming). Это LMCSA (Lamerris Marrazzmus Coding Style & Architecture). А ООП совсем не такой.

ООП и COM - они как бы совсем не связаны.

Original Demon, решается. На ура.
И вообще, это не решение: x = y / A; Это перегруженный оператор.
Который является удобной для C++ (и для меня) записью того, что систему линейных уравнений надо решить. А решения ты и не видел, соответственно сказать, так оно решается или не так - не можешь.

P.S. Это была строчка из рабочего отлаженного кода, если что.
P.P.S. Нету таких слов "матричное уравнение".