|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : pavel kurnosoff 2:5030/661.25 30 Jun 2001 21:56:10
To : Serge Shikov
Subject : Литература по PHP
--------------------------------------------------------------------------------
29 Jun 01 15:15, you wrote to all:
>> SS> <esql:connection>
>> SS> </esql:connection>
>> боже. ну и галиматья.
SS> Т.е. ты нихрена не понял? Hу это конечно аргумент, но какой-то не
SS> слишком аргументированный ;-).
понять-то я понял. но в глазах до сих пор рябит :)
>> это писали либо машина, либо человек, которому себя не
>> жалко. скажи мне, что это автогенерированный код. скажи пожалуйста,
>> а то я оканчательно разочаруюсь.
SS> Да, это автогенерированный код, если угодно. У меня просто есть DTD,
SS> или XML Schema, которые описывают синтаксис того, чего можно генерить.
SS> Какие тэги и какие атрибуты. И если мне охота - я просто юзаю для
SS> написания этого _любой_ XML-редактор.
любой - это какой?
>> {% USE db=DB(dsn=>"...",user=>"...",password=>"...") %}
>> {% BLOCK deps %}
>> <header>...</header>
>> {% FOREACH dep=db.query("select id,name from dep_table"); %}
>> <departament>
>> <name>{% dep.name | xml %}</name>
>> <id>{% dep.id | xml %}</id>
>> {% FOREACH user=db.query("select name from dep_users where
>> id=?",dep.id) %} <user>{% user.name | xml %}</user> {% END
>> %} </departament> {% END %} <footer>...</footer> {% END %}
SS> боже. ну и галиматья. это писали либо машина, либо человек, которому
SS> _меня_ не
SS> жалко ;-) И ты правда думаешь, что твой вариант лучше с какой-то точки
SS> зрения?
он меньше занимает. он проще синтаксически. он читабельнее.
SS> Hу для начала - где у тебя esql:? Или ты думаешь, что
SS> namespace в XML придумали идиоты, и это никому не нужная фича? Так ты
SS> это зря, зря...
у меня инкапсуляция обеспечивается на уровне объектов. в xml - это нужно. а в
с++, если интересно моё мнение, - нет ;)
SS> Синтаксис тебе такой мил? А почему, собственно? Мне он
SS> наоборот кажется уродским - потому что это вроде как перл, а с другой
SS> стороны - вроде как и нет.
а причём тут перл? у тебя тоже какой-то уродский - вроде html, а вроде и язык
процедурный ;)
SS> Левота, одним словом. У меня если в
SS> документе и используется процедурный код, то синтаксис в любом случае
SS> либо XML, либо Java (ну или на чем я там пишу). И никакой другой нафиг
SS> не нужен, что на самом деле значительно упрощает дело.
враньё. у тебя еще по крайней мере ТРИ ориентированных на конкретную задачу
языка (регэкспы в схемах, xpath и sql). почему бы для того, для чего удобно, не
завести еще один? на мой взгляд, ребята сильно переусердствовали в уложении
всего, чего можно в xml. всё-таки визарды - визардами, а руками что-то писать
всё-равно придётся.
что, кстати, подтверждается существованием в резине (вообще, в caucho ребята -
молодцы! единственный продукт во всём этом мутном царстве, который мне реально
нравится) фигни под названием stylescript. и вообще более "расслабленному"
подходу ко всей это хардкоровой иксемельной хренотени.
``The following syntax uses Resin's StyleScript as the stylesheet language.
StyleScript is semantically equivalent to strict XSL, but it less verbose and
more readable.''
>> вот. я мог бы сделать это через {% VIEW %}, но моих изменений,
>> которыми бы я воспользовался еще пока нет в основном дереве, так что
>> это нечестно ;)
SS> Я мог бы сделать это через: XLE, dbXML, XML2DBMS и еще кучку других
SS> средств. И все это вылилось бы примерно в одну-две строчки кода.
SS> Причем это все не мои изменения, с стандартные фичи этих продуктов -
когда доведу до ума - тоже будет стандартная фича продукта.
SS> т.е. все более чем честно. Hу и?
>> SS> (Это кокуновский подход, есть еще и поудобнее средства, XLE
>> SS> например). Заметь - тут два вложенных select, так что твой
>> SS> db.getrow("select date from table") уже пошел лесом - у тебя
>> SS> уже будет два цикла.
>> а у тебя два уровня вложенности. и что? будешь утверждать, что там
>> нет внутри циклов?
SS> Есть. Hо это не совсем циклы, если ты понимаешь, о чем я.
а что же?
SS> XLExtractor xt = new XLExtractor();
SS> java.lang.String args2[]= { "-config", "access.cfg","po.dtdsa", "100"
SS> };
SS> java.lang.String output = xt.extract(args2);
SS> В результате в output я получу большой длинный XML, вытянутый из
SS> нескольких таблиц, все циклы тут будут сугубо внутри extract. То что
SS> я
SS> тебе написал - просто лишняя демонстрация, что и так тоже можно. Можно
SS> писать также длинно и нудно, как ты пишешь на TT2 (но совершенно не
SS> нужно) ;-)
ух ты. искуственный интеллект. и оно само догадается про таблицы и всё такое?
или может всё-таки приведешь содержимое вот этих access.cfg и po.dtdsa?
>> SS> знакомый со структурой базы.
>> SS> Дальше он сказал другому человеку, что тот получит данные такой
>> SS> структуры:
>> SS> <header>...</header>
>> SS> <department>
>> SS> <id>...</id>
>> SS> <name>...</name>
>> SS> <user>...</user>
>> SS> </department>
>> SS> ...
>> SS> <footer>footer info</footer>
>> ну, аналогично.
SS> Возможно. Хотя я пока этого не увидел. Hа это можно будет потом
твои проблемы.
SS> натравить еще пару стадий обработки? Т.е. скажем - достать еще
SS> данные,
SS> из другого источника, сгенерить вторую подобную структуру, а потом их
SS> совместно переработать в HTML при помощи XSLT (или чего угодно, на
SS> твой вкус)? Т.е. можно так:
SS> XML -> SQL-процессор -> XML -> LDAP -> XML -> хрен-знает-что -> XSLT
SS> ->HTML? Любая последовательность фильтров, короче?
конечно. это ведь всё ненавистные тебе переменные, не забыл? ;) можно сразу
выводить в конечный поток, а можно сохранять до поры - до времени. да, это будет
не dom дерево, а просто текст. но это из-за того, что я подстраиваюсь под
неродной метод. в реальности я бы все эти структуры в спискохэшах держал.
>> SS> Теперь представим себе, что в каждой строке этого безобразия
>> SS> есть поле типа дата, и наш контрол dates:input надо повторить
>> SS> тоже для каждой строки. Каким образом ты собрался ссылаться на
>> SS> одно из полей, выбранных твоим select-ом - я не понимаю. Я
>> SS> лично сошлюсь на него при помощи XPath - потому что у меня _на
>> SS> самом деле_ все в XML.
>> XPath? пожалуйста.
SS> Чего пожалуйста? У тебя все в переменных, а не в XPath. А результаты
SS> XPath ты сначала достаешь в переменные, а потом подставляешь в
SS> документ. У тебя _два_ этапа.
конечно. я ведь в данном случае пользуюсь адаптерами, а не родными методами. а
адаптеры - это всегда лишний уровень.
>> SS> Что интересно - на данном этапе человек уже может быть
>> SS> дизайнером. Ему максимум что надо знать, так это XPath, который
>> SS> в общем выучить не сложно. Во всяком случае что-то типа
>> SS> //department/user/birthdate напишет любой дурак.
>> {% USE deps=XML::XPath(xml=>deps) %}
>> {% FOREACH date=deps.findnodes('//departament/user/birthdate') %]
>> {% INCLUDE dates/input ... value=date.string_value %}
>> {% END %}
SS> Ой чтой-то ты в данном случае гонишь, как я погляжу...
плохо глядишь. это реальный пример. хочешь в инет полжу, чтоб ты посмотрел?
SS> В какой момент
SS> это все выполняется, и где находится тот документ, откуда ты берешь
SS> //departament/user/birthdate? Я сильно подозреваю, что его в этот
SS> момент еще не существует.
в deps он лежит. в переменной :-]
>> SS> А у тебя на самом деле все будет в перле и в его переменных,
>> SS> которые тебе придется заводить для этой задачки.
>> а у тебя на самом деле всё будет в java в куче(heap). и чего? чем
>> тебя так пугают переменные?
SS> Тем что это бред и галиматья.
а, тоже бизон? значит я твой иксемел не могу обзывать, а ты процедурный подход
можешь? :) учение маркса всесильно, потому что оно верно, да?
SS> Хотя я готов согласиться, что если
SS> _тебе_ так кажется удобнее - то и флаг в руки, почему нет?
>> SS> А все почему - потому что ты
>> SS> не можешь вкладывать свои операции %INCLUDE друг в друга - у
>> SS> них синтаксис не XML-ный.
>> мда... аргумент. ну есть есть {%wrapper%} - их можно вкладывать.
SS> Hу и чем они тогда отличаются, кроме синтаксиса?
include не подставляет в локальном контексте значение переменной content. ибо не
из чего. обычный syntax sugar- чтобы лишний {end} не писать. точно так же как
сокращенныя запись пустых тэгов в иксемеле.
>> SS> Потому что у них нету контекста, как в XML-документе,
>> SS> взаимосвязей типа родитель-ребенок-сосед и т.п. Поэтому у тебя
>> SS> XPath нету, а у меня - есть.
>> ой, гонишь...
SS> Куды гонишь? Hету ведь контекста-то... Hу хорошо - конечно есть, есть
SS> контекст перловый, скажем локальные переменные в циклах. Hу например
SS> вот тут:
>> {% FOREACH user=db.query("select name from dep_users where
>> id=?",dep.id) %} <user>{% user.name | xml %}</user> {% END %}
SS> контекст - это user, а также db, ну и так далее. Т.е. у тебя _два_
SS> контекста, они - это перловые переменные, второй - это документ, в
SS> котором это все записано. Hу и нафиг он тебе?
чего? один у меня контекст. перловые переменные. какие документы, если это всё в
перловый код компилится? и у тебя один - дом дерево. или если применять твой
подход - у тебя тоже два. всё равно эти <esql:> вызывают исполнение какого-то
левого кода.
>> SS> Может ты XML и знаешь, но пока ты предлагаешь
>> SS> совершенно не-XML-ные решения, на мой взгляд совершенно кривые
>> SS> и негибкие.
>> ну да - вот то, что там сверху, оно действительно кривое. ибо хрен
>> бы я в этой ситуации стал туда еще и xml вводить. лишний он там,
>> лишний... ну раз уж ты просишь...
SS> Он лишний, пока ты данные из одного источника достаешь. А как их
SS> становится два и более - надо иметь один общий формат.
perldoc perllol? xml - это не формат, это обёрточная бумага. ты всё равно каждый
раз специфицируешь названия этих самых departament, user и т.д.
SS> Вот XML - это
SS> он и есть. Hа месте esql мог бы быть кто угодно, причем без всяких
SS> усилий. А esql мог бы например быть сгенерен на предыдущей стадии
SS> обработки XML-я.
да, eval у меня тоже есть.
pavel
--- GoldED+/W32 1.1.4.7
* Origin: there's no tomorrow (2:5030/661.25)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
