Гы, "слишком" хорошего или мощьного не бывает, также как не бывает слишком много денег :p :beer:

Hubbitus
В плане небезопасности мощный.
Ладна, завязываю тута :end:

Кстати (или некстати) о поддержке XHTML браузерами.
 

Я тут тоже провел аналогичный эксперимент... Результаты необнадеживающие.
Попробуйте сами промотреть приведенный ниже HTML в любом браузере.

Опробовано на IE 6.0, Mozilla Firefox 1.0, Opera 7.51. Печально что даже Mozilla, считающийся надеждой W3C, успешно провалил данный пустяковый тест...

NB. Можно менять DOCTYPE на любой или вообще его убрать, похоже в данном случае он ни на что не влияет.

Konqueror из КДЕ 3.4 отобразил правильно....
т.е. черным цветом оба

Дак о чем это говорит-то? Не о том ли о чем я говорил - что проблем с XHTML еще предостаточно...

Кстати, http://feofanov.fizteh.ru/anal/xsltbug.html вот тут еще наткнулся на критику XML + XSLT, помоему весьма аргументировано. И тут не все гладко... :(

Надо отдать должное автору, - аргументация и вправду понятная и убедительная. Хороший пример нам всем :cool:

Hubbitus
На месте его клиентов я бы тоже голосовал рублем в пользу другой компании. Из-за вот таких вот решений:
Тут налицо явная некомпетенция этого "директора", которого ввели в заблуждение горе специалисты. Так как описано делать действительно глупо и нерационально.

ЗЫ. Все остальное уже дососано из пальца (XSLT это сложно, XSLT это не так мощно, XSLT это опять сложно... и т.п.)

Денвер, обосрать можно кого угодно. Говори по делу. "Вот так неправльно, правильно так-то"...

RaZEr
Вот так неправильно: при каждом запросе перегонять все (!) данные из MSSQL в XML чтобы потом XSLT сделал выборку. Это так же неправильно как делать SELECT * FROM table; чтобы потом этот массив обрабатывал ASP или PHP или еще там что. А то что они именно так и делали говорят фразы типа:
Неудивительно что масштабируемые, если постараться можно и непродуманными SQL запросами увеличить "масштабируемость" MySQL, MSSQL и т.п.

Что они так НЕ делали, - очевидно. При простой выборке новостей, статей, тем форума и т.д., получим десятки тысяч записей БД (SELECT * FROM table;). Памяти для такой XML структуры не хватит и для одного пользователя на весь сервер.

Тут имелось ввиду то, что при обработке XSLT мы вынуждены грузить в пямять два "текстовых файла" (*.xml и *.xsl) что жрёт довольно много памяти.

RaZEr
Ну и что за сарказм заключается в кавычках? Или без сарказма? Тогда фраза вызывает сомнения... ну скажем есть 10 Кб XML и XSL 10Kb, "довольно много" это 20Кб?

Вот "огромный" тут я подозреваю совсем не 10 Кб. Поэтому и сделал вывод что кое-чего в XML они пихали действительно лишнего...

В кавычках цитата. Памяти XSLT-обработка жрёт нестолько "много" сколько "больше чем".

Вобщем пришлось мне столкнуться с парсингом XML на PHP и результат вполне ожидаем - XML-файл порядка 2МБ, при выборке и обработке его потребовал больше 10 метров оперативки!!! Ну да, у меня на серваке гиг стоит, но всеравно при таких объемах (и это без XSLT и прочего всего, просто из него выбирались элементы, получались данные) сколько пользователей одновреименно можно будет обслужить??? Ответ в любом случае (предвижу оптимистичную критику denver'а) весьма удручающий...
Тут я тоже полностью согласен - НЕ так!
denver, ты сам подумай, это какой бы у них должен был бы быть мэйнфрейм на каждый магазин, чтобы перегонять базу всю в XML ("Самые большие каталоги вмещали по 70000 товаров.") да еще потом и обрабатывать, при посещаемости от 1000 человек!!! Это терабайты оперативы и сотни процов!! Так что это просто исключено - там делались нормальные выборки.

Hubbitus
Как думаешь, сколько занимает итоговый XML при "нормальной" выборке?

Даже при выжимке самых необходимых данных XML занимает довольно много. Вот простой пример:Итого данных - 3 байта, оформление - 19 байт. Это хорошо расходует память. А там ещё XSL где почти всегда есть неиспользуемые xsl:template блоки ... хорошо вообщем получается. Не смертельно. Но тем не менее.

RaZEr
Не смешите меня. И вообще, я хотел услышать размер *итогового* XML, по вашему мнению.

Вот взял базу мп3 ... 10МБ ... 80К записей => ~125 байт на каждую. Скажем выводим по 20 на странице. 125*20 = 2.5К что у нас там ... id,title,artist,album,kbps,time,size + оформление 30*2+3*7=621. *20 = 12420. Итого ... на одном XML мы получили вместо 2.5 - 15 (2.5+12.5) т.е. в разы увеличили расход памяти. Для хорошо посещаемых проектов (100К хитов и больше) учитывать это немаловажно.

Ок, все правильно. Однако я не вижу "огромного массива данных" как в случае с "нормальными выборками" от той компании.
Что в принципе и правильно. Никаких действительно огромных массивов не должно быть, выводим лишь то что в последствие будем использовать.

А наезды на тэги, которые занимают лишнее место, конечно обоснованы. Но это наезды на идею всего XML. Может вы противники XML как такового? :biggrin:
Хочешь "машинно+человеко-ориентированно" -- выводи/храни в XML, хочешь оптимизированно и понятно только машинам -- храни в своем формате. XML+XSLT это прежде всего для программеров и верстальщиков (для человеков), а потом уже для машины. Не нужна абстракция используй FastTemplates или вставки <?=$foo?>.

Боже упаси ;)

Ты не так давно говорил что XML прежде всего для машины, а не для человека. Противоречишь себе. Но в данном случае я с тобой согласен - размер возрастает из-за удобочитаемости, которая необходима т.к. XSL создаёт человек.

RaZEr
Если я так и говорил то я неверно сформулировал :) Конечно XML в равной степени (не)удобен и тем и другим.

Вот еще одно необдуманное утверждение из статьи:
В рядовых случаях полная смена дизайна (именно его, т.е. оформления данных) требует полного переписывания лишь HTML. Не обязательно знать XSLT чтобы найти и изменить HTML блоки в нем. Когда же встает вопрос об полном изменении XSLT тогда (при граммотном PHP) очень редко встает вопрос об изменении еще и PHP. Но если не XSLT задает логику отображения (допустим мы используем FastTemplate), тогда это делает PHP. И это еще вопрос -- кто из спецов дороже -- (программер PHP + верстальщик HTML) или только (верстальщик XSLT+HTML).

Высказывание в высшей степени необдуманное. Не обратил на него внимание. XSLT в моём понимании это то, что позволило наконец полносью абстрагировать оформление. Т.е. решить задачу с которой так и не справился CSS. Поэтому смена дизайна XSLT сайта на порядок проще аналогов. Конечно при условии что разработчики понимали что делали ;)

Вот перечитал на досуге топик - развели тут святую войну аж жуть...

Большинство фраз которые тут прозвучали - надуманные и получаются из за непонимания web технологий и концепций построения приложений в целом.

Хотя Я сам являюсь ярым приверженцем рационального использования xml+xslt, Я никого не заставляю пользоваться этими мощными инструментамим - на все свое время.

Кому-то и plain html сейчас до сих пор подходит.

Вышеприведенная статья имхо "умная" но бездарная...

З.Ы. xml+xslt это ведь не только быстрая смена дизайна, версии для печати, wap версии, pdf и тд.

Ты не счтаешь преждевременным критиковать аргументацию других, когда сам вообще не привёл никаких аргументов? Твой пост оскорбляет участников топика обвиняя их в некомпетентности, и ты получаешь от меня предупреждение. Пока устное.

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

Писать тонну информации о том какие сложные шаблоны xslt, про большие и маленькие иксэмэли и другие надуманные проблемы (ведь 90% этих проблем просто надуманно), как неправильно работает xhtml в браузерах и тд. То же не вижу смысла.

Основная проблема использования этой связки это низкий уровень подготовки персонала так как сразу с php или чего то друго го не перескочишь, потому что надо за один раз разобраться аж в 3 вещах как минимум (DOM, XML,XSLT,XPATH итд.)

По этому для некотрых эта связка является обычным рабочим инструментом, а для других чем то божественным на которое надо молится.

Sych
Типа "пробегал я мимо, спорите о чепухе, я бы тоже поспорил да не о чем, вы все лохи а я дартаньян, учите матчасть" :yees:

У каждого разный взгляд на одну и ту же проблему. И если некоторые себя тут считают "не сильно компетентными" в вопросе по данной теме то это уже личное дело каждого.

Можете бросить в меня камень за этот простейший пример который как мне кажется наглядно демонстрирует приемущества работы такой связки. см.так же пост 42 в этом топике

Для людей которые особо не верят в магию - напомню что XSLT это офф. стандарт W3C - который по моему мнению у разработчиков должен быть по приоритетам на 1 месте.

Кстати про память. Считать нужно не так. Считать нужно исходя из того, сколько занимает в памяти все дерево xml(при использованиии DOM), а это напомню:

экземпляры классов;
методы;
поля;
метаданные и т.д. и т.п.

Sheryld
Я согласен с тем что в памяти должно храниться дерево элементов, так назыв. Document Object Model.
Поля и метаданные -- еще можно отнести к DOM, но о каких экземплярах класса и методах идет речь? Где такой RTFM брали? :confused:

Ну а как же. Создается когда экземпляр класса(например, DomDocument) он же требует выделения памяти? Насколько я себе представляю php. Он написан на с++. Поэтому там действуют те же самые законы, при этом работает интерпретатор и парсер(которые и обеспечивают поддержку данного синтаксиса).

Кстати, интересно, а можно ли напрямую вызвать функцию(экспортируемую) из бибилиотеки, если писать программу на с++?:)

Sheryld
Насколько мне известно в XML нет ни методов, ни функций, ни класов, ни их экземпляров :-/
Ничего не понятно, когда создается?

---8<-------8<-------8<----
...Вырезано так как чушь :)
---8<-------8<-------8<----

Погляди реализацию DOM в исходниках.