|
ru.website
- RU.WEBSITE -------------------------------------------------------------------
From : Serge Shikov 2:5020/400 01 Jul 2001 12:20:07
To : All
Subject : Re: Литература по PHP
--------------------------------------------------------------------------------
pavel kurnosoff wrote:
>
> >> это писали либо машина, либо человек, которому себя не
> >> жалко. скажи мне, что это автогенерированный код. скажи пожалуйста,
> >> а то я оканчательно разочаруюсь.
> SS> Да, это автогенерированный код, если угодно. У меня просто есть DTD,
> SS> или XML Schema, которые описывают синтаксис того, чего можно генерить.
> SS> Какие тэги и какие атрибуты. И если мне охота - я просто юзаю для
> SS> написания этого _любой_ XML-редактор.
> любой - это какой?
Hу почти любой, который по DTD умеет проверять.
> >> {% 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> зрения?
> он меньше занимает.
Hа это наплевать.
> он проще синтаксически.
Вовсе нет.
> он читабельнее.
Тоже самое. Хотя могу согласиться на то, что тут дело вкуса.
> SS> Hу для начала - где у тебя esql:? Или ты думаешь, что
> SS> namespace в XML придумали идиоты, и это никому не нужная фича? Так ты
> SS> это зря, зря...
> у меня инкапсуляция обеспечивается на уровне объектов. в xml - это нужно. а в
> с++, если интересно моё мнение, - нет ;)
Понятно. Т.е. у тебя синтаксис шаблонов таким способом, как в XML - не
расширяется? namespace - они же для того, чтобы при независимом
расширении имена тэгов могли пересекаться, так? Т.е. у меня дизайнер
пишет <dates:mmm> и <util:mmm> - и все окей, а у тебя он все время пишет
{% INCLUDE mmm %}. Hу и где тут "читабельнее"?
> SS> Синтаксис тебе такой мил? А почему, собственно? Мне он
> SS> наоборот кажется уродским - потому что это вроде как перл, а с другой
> SS> стороны - вроде как и нет.
> а причём тут перл? у тебя тоже какой-то уродский - вроде html, а вроде и язык
> процедурный ;)
Где ты видел процедурный? Пальцем покажи, да?
> SS> Левота, одним словом. У меня если в
> SS> документе и используется процедурный код, то синтаксис в любом случае
> SS> либо XML, либо Java (ну или на чем я там пишу). И никакой другой нафиг
> SS> не нужен, что на самом деле значительно упрощает дело.
> враньё. у тебя еще по крайней мере ТРИ ориентированных на конкретную задачу
> языка (регэкспы в схемах, xpath и sql).
Hу хорошо, но тогда у тебя их пять ;-) Впрочем, хочу заметить, что схемы
ты тут не видел, и регекспы в ней находятся в отдельном файле и пишутся
отдельным человеком, так что тут как раз все нормально. SQL - да, от
этого вряд ли просто уйдешь (хотя разделить на разные файлы я тоже
могу). Остается XML и XPath, ну и?
> почему бы для того, для чего удобно, не
> завести еще один? на мой взгляд, ребята сильно переусердствовали в уложении
> всего, чего можно в xml. всё-таки визарды - визардами, а руками что-то писать
> всё-равно придётся.
Дело, повторю, не в написании руками. Все что уложено в XML, я могу
формально проверить, причем сразу в редакторе, дав ему DTD или схему.
Тебе это придется скомпилирвать и запустить.
> что, кстати, подтверждается существованием в резине (вообще, в 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.''
Зато XSLT генерируется, поскольку он XML, а их язык - левота.
> >> вот. я мог бы сделать это через {% VIEW %}, но моих изменений,
> >> которыми бы я воспользовался еще пока нет в основном дереве, так что
> >> это нечестно ;)
> SS> Я мог бы сделать это через: XLE, dbXML, XML2DBMS и еще кучку других
> SS> средств. И все это вылилось бы примерно в одну-две строчки кода.
> SS> Причем это все не мои изменения, с стандартные фичи этих продуктов -
> когда доведу до ума - тоже будет стандартная фича продукта.
Вот тогда с XLE и сравним ;-)
> 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> нужно) ;-)
> ух ты. искуственный интеллект. и оно само догадается про таблицы и всё такое?
Может и само. Если вместо XLE взять например IBM WSDE. Или еще парочку
продуктов.
> или может всё-таки приведешь содержимое вот этих access.cfg и po.dtdsa?
access.cfg - это полная фигня, там база, юзер и пароль. А po.dtdsa
генерируется гуевой программой, это мап базы в XML, в виде комментариев
к DTD:
<!DOCTYPE po [
<!ELEMENT po (id, buyer, seller,
(lineitem)* :: w:= SQL("SELECT * FROM lineitem WHERE poid=$r.poid") )
:: r:=SQL("SELECT * FROM po WHERE poid = $in0") >
<!ELEMENT id (#PCDATA :r.POID)>
<!ELEMENT buyer (name, address) :: x:=sql("select * from company where
coid = $r.buyerid")>
<!ELEMENT seller (name, address) :: x:=sql("select * from company where
coid=$r.sellerid")>
<!ELEMENT name (#PCDATA :x.name)>
<!ELEMENT address (#PCDATA :x.addr)>
<!ELEMENT lineitem (productname, BillTo, ShipTo, productMeasure,
description,
amount) :: v:= SQL("SELECT * FROM product WHERE prodid = $w.prodid")
>
<!ELEMENT productname (#PCDATA :v.name)>
<!ELEMENT productMeasure (#PCDATA :v.measure)>
<!ELEMENT description (#PCDATA :v.descript)>
<!ELEMENT BillTo (#PCDATA :x.name) :: x:= SQL("SELECT * FROM company
WHERE coid=$w.billto")>
<!ELEMENT ShipTo (#PCDATA :x.name) :: x:= SQL("SELECT * FROM company
WHERE coid=$w.shipto")>
<!ELEMENT amount (#PCDATA :w.amount)>
]>
О чем я тебе и толкую - для явы есть средства, позволяющие делать многие
вещи, которых для перла нет в природе.
> >> 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 дерево, а просто текст. но это из-за того, что я
> подстраиваюсь под неродной метод. в реальности я бы все эти структуры в
> спискохэшах держал.
Т.е. модель данных сохраняется в виде переменных? И чем это лучше DOM
дерева? Чем лучше дерево - рассказать?
> SS> Чего пожалуйста? У тебя все в переменных, а не в XPath. А результаты
> SS> XPath ты сначала достаешь в переменные, а потом подставляешь в
> SS> документ. У тебя _два_ этапа.
> конечно. я ведь в данном случае пользуюсь адаптерами, а не родными методами. а
> адаптеры - это всегда лишний уровень.
Я вроде с самого начала предлагал - напиши семантический аналог, не надо
подстраиваться под cocoon.
> >> 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 он лежит. в переменной :-]
При чем тут переменная? Вот ты пишешь коды всякие, вложенные в XML.
XPath применяется к этому же документу, где это все написано, или к
другому?
> >> SS> А у тебя на самом деле все будет в перле и в его переменных,
> >> SS> которые тебе придется заводить для этой задачки.
> >> а у тебя на самом деле всё будет в java в куче(heap). и чего? чем
> >> тебя так пугают переменные?
> SS> Тем что это бред и галиматья.
> а, тоже бизон? значит я твой иксемел не могу обзывать, а ты процедурный подход
> можешь? :) учение маркса всесильно, потому что оно верно, да?
Видишь ли, правильность моего XML-документа я могу гарантировать на
любой стадии при помощи десятка-другого методов. Просто потому, что его
структура формализована. Если хватит - применю DTD, если нет - Schema,
или еще что-то. Правильность твоей модели в виде кучи переменных
гарантируется только в твоей голове. У меня модель - проще. Угу?
> 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у и нафиг он тебе?
> чего? один у меня контекст. перловые переменные. какие документы, если это всё
> в перловый код компилится?
Вот это - что? <header>...</header> У меня это обычный XML-документ, не
более того. И в _нем_ лежат все мои данные. И его я обрабатываю в
несколько последовательных, независимых друг от друга стадий, которые
друг другу _ничего_ кроме этого документа не передают. А ты - передаешь
кучу переменных, непонятным образом связанных друг с другом. И
неструктурированный текст.
> и у тебя один - дом дерево. или если применять твой
> подход - у тебя тоже два. всё равно эти <esql:> вызывают исполнение какого-то
> левого кода.
_Автономного_ кода. Который кроме _своего_ дерева ничего знать не знает.
Т.е. берет свои элементы, с префиксом esql, и перерабатывает в другие
элементы. Полностью черный ящик.
> >> SS> Может ты XML и знаешь, но пока ты предлагаешь
> >> SS> совершенно не-XML-ные решения, на мой взгляд совершенно кривые
> >> SS> и негибкие.
> >> ну да - вот то, что там сверху, оно действительно кривое. ибо хрен
> >> бы я в этой ситуации стал туда еще и xml вводить. лишний он там,
> >> лишний... ну раз уж ты просишь...
> SS> Он лишний, пока ты данные из одного источника достаешь. А как их
> SS> становится два и более - надо иметь один общий формат.
> perldoc perllol? xml - это не формат, это обёрточная бумага. ты всё равно
> каждый раз специфицируешь названия этих самых departament, user и т.д.
Я их специфицирую в виде DTD, схемы и так далее. Так что XML - это
именно формат, причем специально сделанный каждый раз под каждую задачу.
X - это eXtensible, да? А ты где свои переменные специфицируешь, в
голове?
> SS> Вот XML - это
> SS> он и есть. Hа месте esql мог бы быть кто угодно, причем без всяких
> SS> усилий. А esql мог бы например быть сгенерен на предыдущей стадии
> SS> обработки XML-я.
> да, eval у меня тоже есть.
При чем тут это?
--- ifmail v.2.15dev5
* Origin: home (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
