>> статьи на xmlhack.ru

Архив дискуссии «XML. С чего начать?» эхи fido7.ru.php

Автор: Олег Паращенко
Опубликовано на xmlhack.ru (05.08.2001, рус.): http://xmlhack.ru/texts/01/WithWhatToStart/wwts_fido7_ru_php.html
В закладки:    

Добрый день.

Есть желание заказчика переработать существующий сайт с использованием 
XML-технологий. Сейчас сайт сделан на php/MySQL.

Сайт небольшой, по сути это некий иерархический каталог изделий,
то есть структурно это по-моему очень хорошо ложится на концепцию
XML да и вообще распространенный тип сайтов. 
Да, каталог достаточно статичен, то есть возможны разные варианты
работы, как генерация на лету, так и просто генерация набора
HTML-ей при изменении каталога. Кроме того есть и явная динамика,
в основном касающаяся работы с юзерами (регистрация/логин/логаут/etc) и
поисков по каталогу.

Проблема в том, что у меня при попытке знакомства с XML разбежались
глаза :) Столько всего вокруг, что не знаешь за что браться.
Может кто подскажет ? Может есть примеры реализаций такого типа сайтов ?

Вот мои начальные вопросы:
1. Возможно ли и насколько оправдано применение XML для такого проекта ?
2. Hужно ли использовать СУБД для хранения каталога или хранить его в
   XML ? Если в СУБД, то как получать XML из базы ?
3. Hужен ли DTD, если XML будет делаться не руками, а генериться на
   основании информации из базы ?
4. Какие из XML-related технологий и соответственно продуктов рекомендуется
   использовать для такого проекта ?
5. Каким образом должна решаться динамика (аутентификация пользователей,
   пермишены для разных категорий пользователей и т.д.) ? Я имею ввиду,
   что для этого использовать ? Тот же php оставить или есть более
   "идеологически" правильные варианты ?
6. Какие средства лучше всего использовать для редактирования каталога,
   если он будет в XMLе ?
7. Как быть с хостингом такого проекта ? Если закладываться на некий
   софт, который должен быть у хостера, то не возникнет ли потом проблем ?

Заранее благодарен.

-- 
Best regards, Ed
 

Hi,

"Ed V. Bartosh" wrote:

> Есть желание заказчика переработать существующий сайт с использованием
> XML-технологий. Сейчас сайт сделан на php/MySQL.

Можно ответить только на один вопрос.

Что неудовлетворяет в существующей ситуации?

-- 
Alexei
 

У меня такое впечатление, что XML нужен там, где клиент может быть не только
HTLM броузер. Т.е. :
Есть некая информация. У твоём случае -  каталог. Если смотреть на этот
каталог лишь через IE/NN - то XML как бы и не нужен получается... Всё и так
делается без проблем, а xml+xslt лишь усложняют задачу. Но вот если для
работы с каталогом надо некий иной клиент - ну скажем, писаный на С++, то
встаёт вопрос о передаче данных из каталога в клиент этот. Т.е. вопрос
протокола передачи. XML + SOAP - очень в этом деле помогают...
Резюмирую - я пришел к выводу, что XML нужен в том случае, если необходима
передача данных заранее не известному клиенту. (SOAP/WAP/HTML etc.), а если
клиент заранее определён и это HTML-понимающий клиент - то лучше не стрелять
из пушки по юзерам :)


"Ed V. Bartosh" <ed@vitebsk.net> wrote in message
news:857kz1snuk.fsf@bartosh.org...
> Добрый день.
>
> Есть желание заказчика переработать существующий сайт с использованием
> XML-технологий. Сейчас сайт сделан на php/MySQL.
>
> Сайт небольшой, по сути это некий иерархический каталог изделий,
> то есть структурно это по-моему очень хорошо ложится на концепцию
> XML да и вообще распространенный тип сайтов.
> Да, каталог достаточно статичен, то есть возможны разные варианты
> работы, как генерация на лету, так и просто генерация набора
> HTML-ей при изменении каталога. Кроме того есть и яная динамика,
> в основном касающаяся работы с юзерами (регистрация/логин/логаут/etc) и
> поисков по каталогу.
>
> Проблема в том, что у меня при попытке знакомства с XML разбежались
> глаза :) Столько всего вокруг, что не знаешь за что браться.
> Может кто подскажет ? Может есть примеры реализаций такого типа сайтов ?
>
> Вот мои начальные вопросы:
> 1. Возможно ли и насколько оправдано применение XML для такого проекта ?
> 2. Hужно ли использовать СУБД для хранения каталога или хранить его в
>    XML ? Если в СУБД, то как получать XML из базы ?
> 3. Hужен ли DTD, если XML будет делаться не руками, а генериться на
>    основании информации из базы ?
> 4. Какие из XML-related технологий и соответственно продуктов рекомендуется
>    использовать для такого проекта ?
> 5. Каким образом должна решаться динамика (аутентификация пользователей,
>    пермишены для разных категорий пользователей и т.д.) ? Я имею ввиду,
>    что для этого использовать ? Тот же php оставить или есть более
>    "идеологически" правильные варианты ?
> 6. Какие средства лучше всего использовать для редактирования каталога,
>    если он будет в XMLе ?
> 7. Как быть с хостингом такого проекта ? Если закладываться на некий
>    софт, который должен быть у хостера, то не возникнет ли потом проблем ?
>
> Заранее благодарен.
>
> --
> Best regards, Ed


 

Hi,

Andy wrote:

> Резюмирую - я пришел к выводу, что XML нужен в том случае, если необходима
> передача данных заранее не известному клиенту. (SOAP/WAP/HTML etc.), а если
> клиент заранее определён и это HTML-понимающий клиент - то лучше не стрелять
> из пушки по юзерам :)

Вот только пушки я к сожалению и не увидел...

-- 
Alexei
 

Здравствуйте Уважаемые.

"Alexei Ivanov" <A.Ivanov@tu-bs.de> wrote in message
news:3B1284A6.2DEE9C86@tu-bs.de...
> Hi,
>
> Andy wrote:
>
> > Резюмирую - я пришел к выводу, что XML нужен в том случае, если необходима
> > передача данных заранее не известному клиенту. (SOAP/WAP/HTML etc.), а если
> > клиент заранее определён и это HTML-понимающий клиент - то лучше не стрелять
> > из пушки по юзерам :)
>
> Вот только пушки я к сожалению и не увидел...

а XML это не пушка, это - средство.
Тем паче, что утверждение "Серебряной пули нет" пока никто не опроверг.
А "сложности" связанные с XML, по большей части указывают на неграмотность
персонала (в т.ч. мененджеров и архитекторов)

Ну а если отвлечься от "конкретных" реализаций, то плюсов много больше, чем
минусов.
И особенно если использовать близлежашие(или выращенные "из") технологии -
XSL, XSLT, XLink, XPath & etc.

PS
  В PHP пока нет развитых(!) средств поддержки подобных технологий, но с
появлением таковых и PHP будет - XML-enabled, но не ранее.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Andy" <andy@goldentele.com> wrote in message
news:9eti3o$29us$1@news.kiev.sovam.com...
> У меня такое впечатление, что XML нужен там, где клиент может быть не только
> HTLM броузер. Т.е. :
> Есть некая информация. У твоём случае -  каталог. Если смотреть на этот
> каталог лишь через IE/NN - то XML как бы и не нужен получается... 
> Всё и так делается без проблем, а xml+xslt лишь усложняют задачу.

особенно при частых "коренных" изменениях дизайна сайта ;)))

> Но вот если для работы с каталогом надо некий иной клиент - ну скажем,
> писаный на С++, то встаёт вопрос о передаче данных из каталога в клиент
этот.

хм... и часто такое бывает ? ;)

> Т.е. вопрос протокола передачи.
> XML + SOAP - очень в этом деле помогают...

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

> Резюмирую - я пришел к выводу, что XML нужен в том случае, если необходима
> передача данных заранее не известному клиенту. (SOAP/WAP/HTML etc.), а если
> клиент заранее определён и это HTML-понимающий клиент - то лучше не стрелять
> из пушки по юзерам :)

так, по юзерам или по заказчикам ? это, вроде, совсем разные "вещи".

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

> > У меня такое впечатление, что XML нужен там, где клиент может быть не только
> > HTLM броузер. Т.е. :
> > Есть некая информация. У твоём случае -  каталог. Если смотреть на этот
> > каталог лишь через IE/NN - то XML как бы и не нужен получается... 
> > Всё и так делается без проблем, а xml+xslt лишь усложняют задачу.
>
> особенно при частых "коренных" изменениях дизайна сайта ;)))
>
> > Но вот если для работы с каталогом надо некий иной клиент - ну скажем,
> > писаный на С++, то встаёт вопрос о передаче данных из каталога в клиент
> этот.
>
> хм... и часто такое бывает ? ;)
Бывает, особенно если проекты для форинов делаешь - они типы продвинутые :)

> > Т.е. вопрос протокола передачи.
> > XML + SOAP - очень в этом деле помогают...
>
> каким боком?
> если верить твоему первому утверждению, то и здесь всё будет точно также.
Неа. Не надо изобретать велосипед - уже есть реализиации передачи объектов и
т.п. по протоколу. А так как XML - дело стандартное, то решается задача
единого представления данных.

> > Резюмирую - я пришел к выводу, что XML нужен в том случае, если необходима
> > передача данных заранее не известному клиенту. (SOAP/WAP/HTML etc.), а если
> > клиент заранее определён и это HTML-понимающий клиент - то лучше не стрелять
> > из пушки по юзерам :)
>
> так, по юзерам или по заказчикам ? это, вроде, совсем разные "вещи".

Заказчик - юзер нашего проекта, так или иначе :)
(ну а мы - юзера его денег :)

Андрей


 

> > Есть желание заказчика переработать существующий сайт с использованием
> > XML-технологий. Сейчас сайт сделан на php/MySQL.
> 
> Можно ответить только на один вопрос.
> 
> Что неудовлетворяет в существующей ситуации?

в аналогичных ситуациях меня лично неустраивает то, что представление сайта конечному зрителю сильно привязано к моим скриптам.
А программеру с дизайнерами всегда трудно.
Оторвать от скриптов в принципе удается только статические элементы результирующего гипертекста и на выходе их просто
подклеивать.
Те же данные , которые скрипт вытаскивает из БД приходится ему же и размечать в хтмл (что очень нудно и непринципиально).

Вот в этом свете я и нахожу полезным использование XML на стороне сервера.
Приняв соглашение о представлении скриптом данных (достатых из БД) в рамках XML,
я забываю о хтмл.
А дизайнеры учат язык шаблонов. Для обработки ХМЛ и сращивания его с остальными частями оформления.

Обращаюсь к Вам всем с просьбой поделиться своим опытом использования XML.
Как Вы используете XML?
Какие Вам известны "надевальщики" шаблонов? Технологии и языки шаблонов?
Какае из них Вы предпочитаете?

Очень прошу ответить. Я только слышу отовсюду вопли: "XML - уже стандарт!",
 "рулез" и прочее.
НО не видел еще ни одного работающего решения на основе серверсайд-XML.
вот и возникают сомнения разные... А может его никто и не использует по прямому назначению???
может имеет смысл занять "нишу" и написать свой надевальщик шаблонов с максимально упрощенным языком??
 

> в аналогичных ситуациях меня лично неустраивает то, что представление сайта конечному зрителю сильно привязано к моим скриптам.
> А программеру с дизайнерами всегда трудно.
> Оторвать от скриптов в принципе удается только статические элементы результирующего гипертекста и на выходе их просто
> подклеивать.
> Те же данные , которые скрипт вытаскивает из БД приходится ему же и размечать в хтмл (что очень нудно и непринципиально).
>
> Вот в этом свете я и нахожу полезным использование XML на стороне сервера.
> Приняв соглашение о представлении скриптом данных (достатых из БД) в рамках XML,
> я забываю о хтмл.
> А дизайнеры учат язык шаблонов. Для обработки ХМЛ и сращивания его с
остальными частями оформления.

Архиверно, имхо.

>
> Обращаюсь к Вам всем с просьбой поделиться своим опытом использования XML.
> Как Вы используете XML?
> Какие Вам известны "надевальщики" шаблонов? Технологии и языки шаблонов?
> Какае из них Вы предпочитаете?
С пхп растет только саблотрон, да можно, наверное, явские всякие прибамбасы
подкрутить...


> НО не видел еще ни одного работающего решения на основе серверсайд-XML.
> вот и возникают сомнения разные... А может его никто и не использует по
прямому назначению???
Есть решение и есть недавний положительный опыт использования того же движка
для поддержки сайта со структурой фронт-енда принципиально другой - фреймы
против простых страниц и т.п. Мне дико понравилось =)

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Hi,

sad wrote:

> > Что неудовлетворяет в существующей ситуации? 
> в аналогичных ситуациях меня лично неустраивает то, что представление сайта конечному зрителю сильно привязано к моим скриптам.
> А программеру с дизайнерами всегда трудно.

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

-- 
Alexei
 

Здравствуйте Уважаемые.

"Andy" <andy@goldentele.com> wrote in message
news:9evf2u$6dl$1@news.kiev.sovam.com...
> > > У меня такое впечатление, что XML нужен там, где клиент может быть не только
> > > HTLM броузер. Т.е. : ...
> > > Но вот если для работы с каталогом надо некий иной клиент - ну скажем,
> > > писаный на С++, то встаёт вопрос о передаче данных из каталога в клиент
> > этот.
> >
> > хм... и часто такое бывает ? ;)
> Бывает, особенно если проекты для форинов делаешь - они типы продвинутые
:)

чтож, тогда это не может не радовать.

> > > Т.е. вопрос протокола передачи.
> > > XML + SOAP - очень в этом деле помогают...
> > каким боком?
> > если верить твоему первому утверждению, то и здесь всё будет точно также.
> Неа. Не надо изобретать велосипед - уже есть реализиации передачи объектов и
> т.п. по протоколу. А так как XML - дело стандартное, то решается задача
> единого представления данных.

в таком случае, скорее всего к связке XML + SOAP, стоит добавить и XSLT,
т.к. базовое представление объектов может быть иным, нежели требует
SOAP-клиент

> > > Резюмирую - я пришел к выводу, что XML нужен в том случае, если необходима
> > > передача данных заранее не известному клиенту. (SOAP/WAP/HTML etc.), а если
> > > клиент заранее определён и это HTML-понимающий клиент - то лучше не стрелять
> > > из пушки по юзерам :)
> >
> > так, по юзерам или по заказчикам ? это, вроде, совсем разные "вещи".
>
> Заказчик - юзер нашего проекта, так или иначе :)
> (ну а мы - юзера его денег :)

Тафтолог из меня аховый, т.ч. соглашусь ;)

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Yuri Makassiouk" <racer@bfpg.ru> wrote in message
news:9evn9f$293i$1@ddt.demos.su...
> > в аналогичных ситуациях меня лично неустраивает то, что представление сайта конечному зрителю сильно привязано к моим скриптам.
> > А программеру с дизайнерами всегда трудно.
> > Оторвать от скриптов в принципе удается только статические элементы результирующего гипертекста и на выходе их просто
> > подклеивать.
> > Те же данные , которые скрипт вытаскивает из БД приходится ему же и размечать в хтмл (что очень нудно и непринципиально).
> >
> > Вот в этом свете я и нахожу полезным использование XML на стороне сервера.
> > Приняв соглашение о представлении скриптом данных (достатых из БД) в рамках XML,
> > я забываю о хтмл.
> > А дизайнеры учат язык шаблонов. Для обработки ХМЛ и сращивания его с
> остальными частями оформления.
>
> Архиверно, имхо.

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

> > Обращаюсь к Вам всем с просьбой поделиться своим опытом использования XML.
> > Как Вы используете XML?
> > Какие Вам известны "надевальщики" шаблонов? Технологии и языки шаблонов?
> > Какае из них Вы предпочитаете?
> С пхп растет только саблотрон, да можно, наверное, явские всякие прибамбасы
> подкрутить...

пока про яву можно забыть - производительность mod_java оставляет желать
много лучшего

> > НО не видел еще ни одного работающего решения на основе серверсайд-XML.

www.brainbench.com

> > вот и возникают сомнения разные... А может его никто и не использует по
> прямому назначению???
> Есть решение и есть недавний положительный опыт использования того же движка
> для поддержки сайта со структурой фронт-енда принципиально другой - фреймы
> против простых страниц и т.п. Мне дико понравилось =)

а УРЛ можно ?

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

> > > Что неудовлетворяет в существующей ситуации? 
> > в аналогичных ситуациях меня лично неустраивает то, что представление сайта конечному зрителю сильно привязано к моим скриптам.
> > А программеру с дизайнерами всегда трудно.
>
> Кто мешает дизайнеру генерить ряд статичных страниц, которые программист связывает в работающую систему.
> Иначе результаты работы дизайнера служат исходными данными для работы программиста.
> Который думает лишь о том что должно быть показано в таблице, а не как.
>
Абисьняю. Приходит к тебе дядька и говорит: "хороший сайт ты сделал. мне
надо так же, только с дизайном - моим - чтобы под фирменный стиль
подходило". И ты начинаешь "cut and paste". А xml-щики - нет =) Примитивно
объяснил, конечно =)).

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/



 

> > вот и возникают сомнения разные... А может его никто и не использует по
> > прямому назначению???
> > Есть решение и есть недавний положительный опыт использования того же движка
> > для поддержки сайта со структурой фронт-енда принципиально другой - фреймы
> > против простых страниц и т.п. Мне дико понравилось =)
>
> а УРЛ можно ?
http://developer.lynweb.net/xshop/
 - там надо пошоркать мышой под формой с логином - слова "proceed to
catalogue" - ссылка.
а второй сейчас собирается - показать могу, но работать оно везде правильно
не обязано =) -
http://developer.lynweb.net/karaoke/

Во втором фреймы, поэтому там особо не поиграешься. А в первом - если к урлу
приписать &xml=1, движок выдаст хмл до преобразования.

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Здравствуйте Уважаемые.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)

"Yuri Makassiouk" <racer@bfpg.ru> wrote in message
news:9f0u77$2n14$1@ddt.demos.su...
> > > вот и возникают сомнения разные... А может его никто и не использует по
> > > прямому назначению???
> > > Есть решение и есть недавний положительный опыт использования того же движка
> > > для поддержки сайта со структурой фронт-енда принципиально другой - фреймы
> > > против простых страниц и т.п. Мне дико понравилось =)
> >
> > а УРЛ можно ?
> http://developer.lynweb.net/xshop/
>  - там надо пошоркать мышой под формой с логином - слова "proceed to
> catalogue" - ссылка.

http://developer.lynweb.net/xshop/shop.php
-------------------------------------
Warning: Failed opening 'localOrderFormFile' for inclusion
(include_path='.:/home/sites/site36/users/eshop/cpanel:/home/sites/site36/us
ers/eshop/eshoplib') in /home/sites/site5/users/xShopLib/class_xShop.php on
line 17

Warning: Cannot add header information - headers already sent by (output
started at /home/sites/site5/users/xShopLib/class_xShop.php:17) in
/home/sites/site5/users/mmClasses/session/class_UserSession.php on line 88

Failed opening 'SELECT PRODUCT_NAME AS name, PRODUCT_PRICE AS price, STOCK
AS stock, DESCRIPTION AS description, MAN_NAME AS manufacturer, PRODUCT_ID
AS id, PICTURE_FILE AS thumbnail, PICTURE_FILE1 AS thumbnail1, PICTURE_FILE2
AS thumbnail2, PRODUCT_NAME2 AS name2, PRODUCT_NAME3 AS name3, OPTION1 as
option1, OPTION2 as option2, OPTION3 as option3, OPTION4 as option4, OPTION5
as option5 FROM (PRODUCT P LEFT OUTER JOIN MANUFACTURER M ON (M.MAN_ID =
P.MAN_ID)) WHERE P.DELETED = 0 AND P.CAT_ID=0 ORDER BY 1 ASC'...
-------------------------------------
;(

> а второй сейчас собирается - показать могу, но работать оно везде правильно
> не обязано =) -
> http://developer.lynweb.net/karaoke/
>
> Во втором фреймы, поэтому там особо не поиграешься. А в первом - если к урлу
> приписать &xml=1, движок выдаст хмл до преобразования.
>
> --
> Yuri Makassiouk
> <><
> racer@bfpg.ru
> http://www.missionandmedia.com/
>
> 
 

Hi, Yuri!

/Tue, 29 May 2001 08:41:31 +0000 (UTC)/ you wrote:

 >> НО не видел еще ни одного работающего решения на основе серверсайд-XML.
 >> вот и возникают сомнения разные... А может его никто и не использует по
YM> прямому назначению???
YM> Есть решение и есть недавний положительный опыт использования того же движка
YM> для поддержки сайта со структурой фронт-енда принципиально другой - фреймы
YM> против простых страниц и т.п. Мне дико понравилось =)

А можно об этом поподробнее ? Подход/инструментарий/etc.
Очень интересно. И не только мне, я полагаю. 
Тут в последнее время об этом спрашивают постоянно.

-- 
Best regards, Ed
 

 Хай, Ол !
 А вообще может кто-нить популярно объяснить чем кого не устраивает старый
добрый ХТМЛ и стоит ли переходить на XML, и когда это стоит делать.

"Ed V. Bartosh" <ed@vitebsk.net> сообщил/сообщила в новостях следующее:
news:857kz1snuk.fsf@bartosh.org...
> Добрый день.
>
> Есть желание заказчика переработать существующий сайт с использованием
> XML-технологий. Сейчас сайт сделан на php/MySQL.
>
> Сайт небольшой, по сути это некий иерархический каталог изделий,
> то есть структурно это по-моему очень хорошо ложится на концепцию
> XML да и вообще распространенный тип сайтов.
> Да, каталог достаточно статичен, то есть возможны разные варианты
> работы, как генерация на лету, так и просто генерация набора
> HTML-ей при изменении каталога. Кроме того есть и яная динамика,
> в основном касающаяся работы с юзерами (регистрация/логин/логаут/etc) и
> поисков по каталогу.
>
> Проблема в том, что у меня при попытке знакомства с XML разбежались
> глаза :) Столько всего вокруг, что не знаешь за что браться.
> Может кто подскажет ? Может есть примеры реализаций такого типа сайтов ?
>
> Вот мои начальные вопросы:
> 1. Возможно ли и насколько оправдано применение XML для такого проекта ?
> 2. Hужно ли использовать СУБД для хранения каталога или хранить его в
>    XML ? Если в СУБД, то как получать XML из базы ?
> 3. Hужен ли DTD, если XML будет делаться не руками, а генериться на
>    основании информации из базы ?
> 4. Какие из XML-related технологий и соответственно продуктов рекомендуется
>    использовать для такого проекта ?
> 5. Каким образом должна решаться динамика (аутентификация пользователей,
>    пермишены для разных категорий пользователей и т.д.) ? Я имею ввиду,
>    что для этого использовать ? Тот же php оставить или есть более
>    "идеологически" правильные варианты ?
> 6. Какие средства лучше всего использовать для редактирования каталога,
>    если он будет в XMLе ?
> 7. Как быть с хостингом такого проекта ? Если закладываться на некий
>    софт, который должен быть у хостера, то не возникнет ли потом проблем ?
>
> Заранее благодарен.
>
> --
> Best regards, Ed


 

> > > > Есть решение и есть недавний положительный опыт использования того же движка
> > > > для поддержки сайта со структурой фронт-енда принципиально другой - фреймы
> > > > против простых страниц и т.п. Мне дико понравилось =)
> > >
> > > а УРЛ можно ?
> > http://developer.lynweb.net/xshop/
> >  - там надо пошоркать мышой под формой с логином - слова "proceed to
> > catalogue" - ссылка.
>
> http://developer.lynweb.net/xshop/shop.php
> -------------------------------------
> Warning: Failed opening 'localOrderFormFile' for inclusion
> (include_path='.:/home/sites/site36/users/eshop/cpanel:/home/sites/site36/us
> ers/eshop/eshoplib') in /home/sites/site5/users/xShopLib/class_xShop.php on
> line 17

Ща поправим, не боись =))
Там коренным образом изменился механизм использования локальных классов, так
что надо все аккуратненько поапдейтить. Сейчас и займусь.

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/



 

> YM> Есть решение и есть недавний положительный опыт использования того же движка
> YM> для поддержки сайта со структурой фронт-енда принципиально другой - фреймы
> YM> против простых страниц и т.п. Мне дико понравилось =)
>
> А можно об этом поподробнее ? Подход/инструментарий/etc.
> Очень интересно. И не только мне, я полагаю.
> Тут в последнее время об этом спрашивают постоянно.

В двух словах пока - вообще, наверное, статью буду писать
1. Данные в реляционной базе (в виде данных, а не XML).
2. Есть движок, который формирует XML-документ. У меня - чисто динамически,
хотя возможны и варианты, наверное.
3. Далее, саблотрон трансформирует этот документ по шаблону. Хитрый момент -
как движок знает, какой шаблон использовать - тут есть варианты, как всегда,
и надо, видимо, смотреть по природе приложения. Жестко задавать структуру
набора шаблонов не советую - с тем же магазином - у одного три шаблона, у
другого уже больше, и еще будет больше. Они зависят только друг от друга,
потому что логическая структура хтмл-я в них тоже заложена.
4. Есть желание сделать на том же скрипте сервис для wap, тогда точно можно
сказать, что идея побеждает.

Инструментарий незатейлив - XMLSpy - самое специфическое средство. И то, я
его использую почти только для проверки на well-formedness шаблона.
Редактировать в нем невозможно.


--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

matriks neo wrote:
> 
>  Хай, Ол !
>  А вообще может кто-нить популярно объяснить чем кого не устраивает старый
> добрый ХТМЛ и стоит ли переходить на XML, и когда это стоит делать.
> 
Цитата из письма выше:
-
Абисьняю. Приходит к тебе дядька и говорит: "хороший сайт ты сделал. мне
надо так же, только с дизайном - моим - чтобы под фирменный стиль
подходило". И ты начинаешь "cut and paste". А xml-щики - нет =)
Примитивно
объяснил, конечно =)).
-
В хтмле у тебя обьединен _И_ дизайн _И_ информация (плюс еще некоторые к
этому фаршу еще и ПХП скриптинг добавляют..).
С XML-ем этого нет. А когда и на что переходить, это решает каждый для
себя..

-- 
<? require_once("regards.inc"); ?>

KVN
 

> В двух словах пока - вообще, наверное, статью буду писать
> 1. Данные в реляционной базе (в виде данных, а не XML).
> 2. Есть движок, который формирует XML-документ. У меня - чисто динамически,
> хотя возможны и варианты, наверное.
Вопрос - а почему не юзать тот же MS SQL XML ?? Оно само :) всё делает.

> 4. Есть желание сделать на том же скрипте сервис для wap, тогда точно можно
> сказать, что идея побеждает.
Тогда можно сказать, что XML был реально нужен :)

> Инструментарий незатейлив - XMLSpy - самое специфическое средство. И то, я
> его использую почти только для проверки на well-formedness шаблона.
> Редактировать в нем невозможно.
Ой да.. намана в нём редактировать :)
Есть приблуда от AS - komodo... тоже типа редактор :)
Хотя лучше FAR+Colorer ничего нет :)))

Andy


 

> (include_path='.:/home/sites/site36/users/eshop/cpanel:/home/sites/site36/us
> > ers/eshop/eshoplib') in /home/sites/site5/users/xShopLib/class_xShop.php on
> > line 17
>
> Ща поправим, не боись =))
> Там коренным образом изменился механизм использования локальных классов, так
> что надо все аккуратненько поапдейтить. Сейчас и займусь.

Должно сейчас работать. Не работает только logout - тут нужно небольшое
хирургическое вмешательство.

>
> --
> Yuri Makassiouk
> <><
> racer@bfpg.ru
> http://www.missionandmedia.com/
>
>
>


 

Hi, Yuri!

/Wed, 30 May 2001 09:14:47 +0000 (UTC)/ you wrote:

YM> В двух словах пока - вообще, наверное, статью буду писать
Hапишешь - дай знать, плз. Можно наверное прям сюда, OK ?

YM> 1. Данные в реляционной базе (в виде данных, а не XML).
В какой ?

YM> 2. Есть движок, который формирует XML-документ. У меня - чисто динамически,
YM> хотя возможны и варианты, наверное.
Hа чем движок ? PHP, ya ?

YM> 3. Далее, саблотрон трансформирует этот документ по шаблону. 
Схема в целом понятна. Спасибо.

А может кто использует XSQL/XPath/etc ? 
Интересно было бы услышать success stories :)

-- 
Best regards, Ed
 

"Vitaliy N. Kravchenko" wrote:

> >  А вообще может кто-нить популярно объяснить чем кого не устраивает старый
> > добрый ХТМЛ и стоит ли переходить на XML, и когда это стоит делать.
> >
> Цитата из письма выше:
> -
> Абисьняю. Приходит к тебе дядька и говорит: "хороший сайт ты сделал. мне
> надо так же, только с дизайном - моим - чтобы под фирменный стиль
> подходило". И ты начинаешь "cut and paste". А xml-щики - нет =)

В итоге ты деньги получаешь, а XML-щики - нет.

> Примитивно объяснил, конечно =)).
Еще бы.

-- 
Alexei

 

> YM> 1. Данные в реляционной базе (в виде данных, а не XML).
> В какой ?
То, что живет - в MySQL, хотя движок магазина использует доступ к данным
через слой абстрактных классов (самописный), так что - в любой, к которой
можно из ПХП обратиться.

> YM> 2. Есть движок, который формирует XML-документ. У меня - чисто динамически,
> YM> хотя возможны и варианты, наверное.
> Hа чем движок ? PHP, ya ?
На PHP.

>
> YM> 3. Далее, саблотрон трансформирует этот документ по шаблону.
> Схема в целом понятна. Спасибо.
=)


--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Здравствуйте Уважаемые.

"Yuri Makassiouk" <racer@bfpg.ru> wrote in message
news:9f2koe$2ii2$1@ddt.demos.su...
> >
> (include_path='.:/home/sites/site36/users/eshop/cpanel:/home/sites/site36/us
> > > ers/eshop/eshoplib') in /home/sites/site5/users/xShopLib/class_xShop.php on
> > > line 17
> >
> > Ща поправим, не боись =))
> > Там коренным образом изменился механизм использования локальных классов, так
> > что надо все аккуратненько поапдейтить. Сейчас и займусь.
>
> Должно сейчас работать. Не работает только logout - тут нужно небольшое
> хирургическое вмешательство.

и ещё один совет - использовать вместо следующих конструкций:
<urlCart>shop.php?xml=1&tmpl=cart</urlCart>
- XLink/XPointer и атрибуты

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Yuri Makassiouk" <racer@bfpg.ru> wrote in message
news:9f2koe$2ii2$1@ddt.demos.su...
> >
> (include_path='.:/home/sites/site36/users/eshop/cpanel:/home/sites/site36/us
> > > ers/eshop/eshoplib') in /home/sites/site5/users/xShopLib/class_xShop.php on
> > > line 17
> >
> > Ща поправим, не боись =))
> > Там коренным образом изменился механизм использования локальных классов, так
> > что надо все аккуратненько поапдейтить. Сейчас и займусь.
>
> Должно сейчас работать. Не работает только logout - тут нужно небольшое
> хирургическое вмешательство.

http://developer.lynweb.net/xshop/shop.php?xml=1

а ссылки на темплейты кто будет вставлять ? я ? ;)


С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

> > В двух словах пока - вообще, наверное, статью буду писать
> > 1. Данные в реляционной базе (в виде данных, а не XML).
> > 2. Есть движок, который формирует XML-документ. У меня - чисто динамически,
> > хотя возможны и варианты, наверное.
> Вопрос - а почему не юзать тот же MS SQL XML ?? Оно само :) всё делает.
И куда (в смысле, к какому провайдеру) ты с этим пойдешь? Для интранета,
например, наверное, самое оно =)

>
> > 4. Есть желание сделать на том же скрипте сервис для wap, тогда точно можно
> > сказать, что идея побеждает.
> Тогда можно сказать, что XML был реально нужен :)
Нет, уже сейчас можно сказать. Потому что при смене дизайна код не меняется
ни на байт. Изменения при этом такие, что с помощью традиционных шаблонов
так не сделать.


--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

>
> http://developer.lynweb.net/xshop/shop.php?xml=1
>
> а ссылки на темплейты кто будет вставлять ? я ? ;)
Там не нужно ссылки на темплейт. Убери xml=1, и движок подцепит дефолтовый
шаблон на сервере и сам по нему трансформирует. На сервере. А не на клиенте.
=)


--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

> и ещё один совет - использовать вместо следующих конструкций:
> <urlCart>shop.php?xml=1&tmpl=cart</urlCart>
> - XLink/XPointer и атрибуты
Эти конструкции, кстати, и правда - самое неэлегантное место. Что за
XLink-и - где почитать?

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

> > >  А вообще может кто-нить популярно объяснить чем кого не устраивает старый
> > > добрый ХТМЛ и стоит ли переходить на XML, и когда это стоит делать.
> > >
> > Цитата из письма выше:
> > -
> > Абисьняю. Приходит к тебе дядька и говорит: "хороший сайт ты сделал. мне
> > надо так же, только с дизайном - моим - чтобы под фирменный стиль
> > подходило". И ты начинаешь "cut and paste". А xml-щики - нет =)
>
> В итоге ты деньги получаешь, а XML-щики - нет.

Ну почему же, ХМЛ-щики получают - за поставку масштабируемых и универсальных
решений.

> > Примитивно объяснил, конечно =)).
> Еще бы.
Наезд?

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

> > > подходило". И ты начинаешь "cut and paste". А xml-щики - нет =)
> >
> > В итоге ты деньги получаешь, а XML-щики - нет.
И вообще, что это за подход?

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Здравствуйте Уважаемые.

"Yuri Makassiouk" <racer@bfpg.ru> wrote in message
news:9f366m$2qk5$1@ddt.demos.su...
> > и ещё один совет - использовать вместо следующих конструкций:
> > <urlCart>shop.php?xml=1&tmpl=cart</urlCart>
> > - XLink/XPointer и атрибуты
> Эти конструкции, кстати, и правда - самое неэлегантное место. Что за
> XLink-и - где почитать?

1) на www.w3.org/TR/XLink вроде (там это одна из первых ссылок в XML теме)
2) почти в любой книге по XML (а их сейчас и на русском хватает, хоть на
ОЗОНе, хоть на БОЛЕРО и т.д.)

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Yuri Makassiouk" <racer@bfpg.ru> wrote in message
news:9f36ca$2rrg$1@ddt.demos.su...
> > > > подходило". И ты начинаешь "cut and paste". А xml-щики - нет =)
> > >
> > > В итоге ты деньги получаешь, а XML-щики - нет.
> И вообще, что это за подход?

Юрий, постараюсь объяснить за тебя ;)
1) XMLщики делают 99% работы один раз
2) остальные от 1% до тех же 99, что в среднем - 50%

когда же появляется или новый заказчик, или старый просит что-либо
исправить, то -
1) XMLщики делают 1% работы
2) остальные - 50%
3) на стоимости же работ это почти не отражается
4) т.к. XMLщики делают это быстрее, то и заказчик к ним относится
благосклонее

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Hello Vitaliy!

30 May 01 12:58, Vitaliy N Kravchenko wrote to All:
 VK> В хтмле у тебя обьединен _И_ дизайн _И_ информация (плюс еще
 VK> некоторые к этому фаршу еще и ПХП скриптинг добавляют..). С XML-ем
 VK> этого нет.
Полный примеров можно? Т.е. полный в каком смысле - простенький
скрипт на PHP, фрагмент базы данных, генерируемый PHP'ой XML, то,
что отдается в браузер. Было бы очень интересно.

- Andrew

... Here I go, playing star again, there I go, turn the page...
 

Hello Alexei!

30 May 01 18:10, Alexei Ivanov wrote to All:
 >> И ты начинаешь "cut and paste". А xml-щики - нет =)
 AI> В итоге ты деньги получаешь, а XML-щики - нет.
Ха-ха-ха. О-чень сме-шно.

Судя по всему, sehr geehrter Herr Ivanov видел succesful команду
cut-n-paste'щиков, но не видел ни одной команды XML-щиков, succesful
в частности. Я прав? Если нет, живые примеры изложенной теории
"о неполучении денег XML-щикам", bitte.

- Andrew

... But it seems like it's going wrong again...
 

Ну здравствуй, Vitaliy!
На днях, 30 мая в 09:58 ты брякнул(а,о)  :

 VNK> мне надо так же, только с дизайном - моим - чтобы под фирменный стиль
 VNK> подходило". И ты начинаешь "cut and paste". А xml-щики - нет =)

А Templates ее пробовал юзать?

|
|Не пугайся открытого неба, не пугайся осенних растений,
|не пугайся зеленых медведей и вообще ничего не пугайся...
|  
 

Hi,

Vladlen Bulatov wrote:

> > > > В итоге ты деньги получаешь, а XML-щики - нет.
> > И вообще, что это за подход?
> 
> Юрий, постараюсь объяснить за тебя ;)
> 1) XMLщики делают 99% работы один раз
> 2) остальные от 1% до тех же 99, что в среднем - 50% 
> когда же появляется или новый заказчик, или старый просит что-либо
> исправить, то - 
> 1) XMLщики делают 1% работы
> 2) остальные - 50%
> 3) на стоимости же работ это почти не отражается
> 4) т.к. XMLщики делают это быстрее, то и заказчик к ним относится
> благосклонее

Я прошу прощения, но твоими бы словами да медку хапнуть....
Скажи ты сам веришь в то что написал?

Давай совсем просто смотреть.
Если ты что-то делаешь один раз, то время потраченное на это можно
не учитывать.
Теперь получается что всю остальную жизнь ты работаешь в 99 раз продуктивнее.
Для простоты возьмем 100.
Тогда вместо ста человек за определенное время работу может выполнить один.
Тогда 99 я должен уволить. Скажи куда делась безаработица среди программистов.
Или почему в 100 раз не возросло кол-во сайтов или ты просто не стал
в сто раз богаче?

В остальном мире, больше 5% годовых это уже очень хорошо.
В России до недавних пор, может и сейчас так, запросто можно было найти и 20 и 30
и 50 %%. Экономика правда разрушается, но прибыли то растут....
Может это тоже использование XML?

-- 
Alexei
 

Hi,

Andrew Aksyonoff wrote:

>  >> И ты начинаешь "cut and paste". А xml-щики - нет =) 
> Судя по всему, sehr geehrter Herr Ivanov видел succesful команду
чего видел?

> cut-n-paste'щиков, но не видел ни одной команды XML-щиков, succesful
> в частности. Я прав? Если нет, живые примеры изложенной теории
> "о неполучении денег XML-щикам", bitte.

Ну если они ничего не делают (1%), за что ж они деньги получают?

Можно статистически прикинуть вероятность нахождения работ
"мне тоже самое, только с перламутровыми пуговицами" которая не реализуется
теми же темплейтами, в общем объеме работ? Тогда и продолжим разговор.

> ... But it seems like it's going wrong again...
Das hast Du ja recht.

-- 
Alexei
 

Прошу прощения.

Alexei Ivanov wrote:
> > ... But it seems like it's going wrong again...
> Das hast Du ja recht.
Da hast Du ja recht.

-- 
Alexei
 

>  VNK> мне надо так же, только с дизайном - моим - чтобы под фирменный стиль
>  VNK> подходило". И ты начинаешь "cut and paste". А xml-щики - нет =)
>
> А Templates ее пробовал юзать?
Пробовал, поэтому и не рассматриваю этот вопрос =). Еще раз говорю - могут
быть отличия не только в цвете или шрифте буковок - может возникнуть
необходимость в принципе по-другому структурировать представление.
Например - перейти от плоской страницы ко фреймам или наоборот. Не тянут
таких применений темплейты и их "эффективность" не оправдывает накладных
расходов на использование.

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Hi,

Yuri Makassiouk wrote:

> Пробовал, поэтому и не рассматриваю этот вопрос =). Еще раз говорю - могут
> быть отличия не только в цвете или шрифте буковок - может возникнуть
> необходимость в принципе по-другому структурировать представление.
> Например - перейти от плоской страницы ко фреймам или наоборот. Не тянут
> таких применений темплейты и их "эффективность" не оправдывает накладных
> расходов на использование.

Давай хотя бы писать "я так думаю"...
Все же честнее будет.


-- 
Alexei
 

Hi, Yuri!

/Wed, 30 May 2001 16:01:22 +0000 (UTC)/ you wrote:

 >> > 4. Есть желание сделать на том же скрипте сервис для wap, тогда точно можно
 >> > сказать, что идея побеждает.
 >> Тогда можно сказать, что XML был реально нужен :)
YM> Нет, уже сейчас можно сказать. Потому что при смене дизайна код не меняется
YM> ни на байт. Изменения при этом такие, что с помощью традиционных шаблонов
YM> так не сделать.

Можно пример ? А то я уже изготовился возражать насчет "cut & paste".

Я, например дизайном не занимаюсь вообще, дизайнеры темплеты корректируют
как хотят. Пока нареканий не возникало. В смысле не было случая (почти),
чтобы для смены дизайна пришлось лезть в php-шный код. Хотя надо признать,
что и кардинальной смены дизайна тоже не было :)

-- 
Best regards, Ed
 

> > Пробовал, поэтому и не рассматриваю этот вопрос =). Еще раз говорю - могут
> > быть отличия не только в цвете или шрифте буковок - может возникнуть
> > необходимость в принципе по-другому структурировать представление.
> > Например - перейти от плоской страницы ко фреймам или наоборот. Не тянут
> > таких применений темплейты и их "эффективность" не оправдывает накладных
> > расходов на использование.
>
> Давай хотя бы писать "я так думаю"...
> Все же честнее будет.

Я пробовал и то, и другое. Темплейты сосут. Я так думаю.

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Yuri Makassiouk wrote:
> 
> > > Пробовал, поэтому и не рассматриваю этот вопрос =). Еще раз говорю - могут
> > > быть отличия не только в цвете или шрифте буковок - может возникнуть
> > > необходимость в принципе по-другому структурировать представление.
> > > Например - перейти от плоской страницы ко фреймам или наоборот. Не тянут
> > > таких применений темплейты и их "эффективность" не оправдывает накладных
> > > расходов на использование.
> >
> > Давай хотя бы писать "я так думаю"...
> > Все же честнее будет.
> 
> Я пробовал и то, и другое. Темплейты сосут. Я так думаю.
Ну сосут, это громко сказано, потому как, нужно рассматривать зачем
придумали темплейты, а зачем XML.
Потому как я думаю, что XML - для отделения данных, а темплейты - для
отделения дизайна, от программирования..
IMHO.

-- 
<? require_once("regards.inc"); ?>

KVN
 

>  >> > 4. Есть желание сделать на том же скрипте сервис для wap, тогда точно можно
>  >> > сказать, что идея побеждает.
>  >> Тогда можно сказать, что XML был реально нужен :)
> YM> Нет, уже сейчас можно сказать. Потому что при смене дизайна код не меняется
> YM> ни на байт. Изменения при этом такие, что с помощью традиционных шаблонов
> YM> так не сделать.
>
> Можно пример ? А то я уже изготовился возражать насчет "cut & paste".
Можно. Пятый раз рассказываю - в одном случае магазина - плоские страницы с
категориями, каталогом и ссылками на всякие корзины. В другом - фреймы с
категориями в одном, каталогом в другом фрейме. Плюс корзина может быть все
время на той же странице. Причем такая структура представления изначально не
предусматривалась, просто разработалась по ходу.
Я понимаю, что теоретически можно, наверное, и на темплейтах сделать всякое,
только сколько ж это всего делать-то?

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/



 

Yuri Makassiouk wrote:

> > Давай хотя бы писать "я так думаю"...
> > Все же честнее будет.
> Я пробовал и то, и другое. Темплейты сосут. Я так думаю.
Сосут но не они.

-- 
Alexei
 

Hi,

Yuri Makassiouk wrote:

> > Можно пример ? А то я уже изготовился возражать насчет "cut & paste". 
> Можно. Пятый раз рассказываю - в одном случае магазина - плоские страницы с
> категориями, каталогом и ссылками на всякие корзины. В другом - фреймы с
> категориями в одном, каталогом в другом фрейме. Плюс корзина может быть все
> время на той же странице. Причем такая структура представления изначально не
> предусматривалась, просто разработалась по ходу.
> Я понимаю, что теоретически можно, наверное, и на темплейтах сделать всякое,
> только сколько ж это всего делать-то?

1. Если делал паровоз, а оказался нужен автомобиль, то и XML не спасет.
2. Сделать можно не теоретически а практически, я делал. И совсем не сложно.
   Надо только представить, что базовый элемент построения сайта таблица.
   А фреймы тоже в какой-то степени таблица.


Последний раз возвращаясь к XML. В нем есть практический смысл, когда
структура данных не известна в принципе. Он позволяет эту структуру упорядочить
чтобы было легче разбирать.

-- 
Alexei
 

                          Привет, Andy !!!

 Как-то раз (а точнее 30 May 01 в 15:04) Andy писал(а) к All:
 >> 2. Есть движок, который формирует XML-документ. У меня - чисто A> динамически,
 >> хотя возможны и варианты, наверное.
 A> Вопрос - а почему не юзать тот же MS SQL XML ?? Оно само :) всё
 A> делает.
а как у него с переносимостью на другие платформы ? ;))) я б еще понял, если б
ты предложил процедуру на SQL/PL... хотя в любом случае - построение простого
XML с данными из рекордсета - задача не настолько сложная и критичная по
времени выполнения, чтоб ее перекладывать на sql-сервер. А вот в те же
DBConnect (PHPLib) или ADODB/PHP метод такой добавить - за милую душу.
Hапример с AxKit идет XSP-модуль SQL taglib, реализующий это для всех БД,
поддерживаемых Perl DBI.

 >> Инструментарий незатейлив - XMLSpy - самое специфическое средство. И
 >> то, я его использую почти только для проверки на well-formedness
 >> шаблона. Редактировать в нем невозможно.
 A> Ой да.. намана в нём редактировать :)
 A> Есть приблуда от AS - komodo... тоже типа редактор :)
гадость :(
 A> Хотя лучше FAR+Colorer ничего нет :)))
сказал бы ты это в ru.perl, тебя б фаны vi&emacs затоптали... тут, видать,
народ попроще ;)


--
mailto: random at info.net.ua                  //Александр

 

                          Привет, Yuri !!!

 Как-то раз (а точнее 30 May 01 в 13:14) Yuri Makassiouk писал(а) к All:
 YM> Инструментарий незатейлив - XMLSpy - самое специфическое средство. И
 YM> то, я его использую почти только для проверки на well-formedness
 YM> шаблона. Редактировать в нем невозможно.

посмотри в сторону CookTop. Это некая оболочка для редактирования
XML/XSL/XPathScript с темплейтами и виджетами для этих языков и возможностью
подключения около десятка XSLT-процессоров. Фриваре. Довольно удобное.


--
mailto: random at info.net.ua                  //Александр

 

                          Привет, Andy !!!

 Как-то раз (а точнее 28 May 01 в 16:59) Andy писал(а) к All:
 A> У меня такое впечатление, что XML нужен там, где клиент может быть не
 A> только HTLM броузер. Т.е. : Есть некая информация. У твоём случае -
 A> каталог. Если смотреть на этот каталог лишь через IE/NN - то XML как
 A> бы и не нужен получается... Всё и так делается без проблем, а xml+xslt
 A> лишь усложняют задачу. Hо вот если для работы с каталогом надо некий
ай, какая недалекоглядность... XML (или что угодно, позволяющее отделить данные
от кода) необходим в любом скрипте, который подразумевает прикручивание
минимального дизайна и/или хотя бы одно изменение формата вывода.

Мне, например, для подобных задач гораздо приятней юзать Template::Toolkit.
Он гораздо гибче и функциональней набора XML:XSLT/XPathScript/XSP.

 A> иной клиент - ну скажем, писаный на С++, то встаёт вопрос о передаче
 A> данных из каталога в клиент этот. Т.е. вопрос протокола передачи. XML
 A> + SOAP - очень в этом деле помогают... Резюмирую - я пришел к выводу,
юзать XML для передачи данных - весьма непрактично. Бинарная структура, да и
просто some_char-separated данные формируются, передаются и обрабатываются
гораздо быстрее, чем XML.

 A> что XML нужен в том случае, если необходима передача данных заранее не
 A> известному клиенту. (SOAP/WAP/HTML etc.), а если клиент заранее
заранее неизвестному клиенту вообще лучше пихать text/plain
 A> определён и это HTML-понимающий клиент - то лучше не стрелять
 A> из пушки по юзерам :)
из пушки по юзерам - это слать XML (с линками на XSL [MSXSL compat]) в
броузер... пользователей броузеров, отличных от MSIE5+, просто разрывает...

--
mailto: random at info.net.ua                  //Александр

 

                          Привет, sad !!!

 Как-то раз (а точнее 29 May 01 в 11:09) sad писал(а) к All:
 s> Обращаюсь к Вам всем с просьбой поделиться своим опытом использования
 s> XML. Как Вы используете XML? Какие Вам известны "надевальщики"
 s> шаблонов? Технологии и языки шаблонов? Какае из них Вы предпочитаете?
из комплексных систем - AxKit (on mod_perl) - www.axkit.org
из парсеров шаблонов - Template::Toolkit - www.template-toolkit.org

только Perl это, эхотагу до него ой как далеко... а в рамках эхотага по теме
тебе прийдется работать только с Sablotron (www.gingerall.com), максимум - с
MSXSLT через OLE (подключать java-овские парсеры через php_java - это совсем
запущенный случай, его рассматривать не будем). Если вдруг зачем-то понадобится
самому разбирать XML - функции для этого в эхотаге есть (там юзается expat, но
дополнительной документации, как в случае с Sablotron'ом, не требуется - все
описано в стандартной).

кстати, на axkit.org советую в любом случае зайти - там довольно много полезных
статей/документации по топику.

--
mailto: random at info.net.ua                  //Александр

 

Alexander Kostiuchenko wrote:
>  A> Хотя лучше FAR+Colorer ничего нет :)))
> сказал бы ты это в ru.perl, тебя б фаны vi&emacs затоптали... тут, видать,
> народ попроще ;)
Ну я допустим в JOE пишу, ну и что, я никому это не навязываю.
меряние пиписками - это детство.
Удачи!

-- 
<? require_once("regards.inc"); ?>

KVN
 

> Последний раз возвращаясь к XML. В нем есть практический смысл, когда
> структура данных не известна в принципе. Он позволяет эту структуру упорядочить
> чтобы было легче разбирать.
А зачем тогда DTD и схемы? Что это за высказывания, кстати - твое мнение?
Пример приложения, работающего с данными, структура которых неизвестна в
принципе, мне был бы любопытен тоже (с чисто исследовательской позиции =))

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

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/



 

>  A> Вопрос - а почему не юзать тот же MS SQL XML ?? Оно само :) всё
>  A> делает.
> а как у него с переносимостью на другие платформы ? ;))) я б еще понял, если б
> ты предложил процедуру на SQL/PL... хотя в любом случае - построение простого
> XML с данными из рекордсета - задача не настолько сложная и критичная по
> времени выполнения, чтоб ее перекладывать на sql-сервер. А вот в те же
> DBConnect (PHPLib) или ADODB/PHP метод такой добавить - за милую душу.
Дык, эта - у меня был класс DataSet, из него теперь пророс XmlDataSet. 15
минут примерно на написание и тестирование.

> сказал бы ты это в ru.perl, тебя б фаны vi&emacs затоптали... тут, видать,
> народ попроще ;)
просто устали =)

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Hi Alexei!

29 Май 01 14:52, Alexei Ivanov -> All:

 >> в аналогичных ситуациях меня лично неустраивает то, что представление сайта
 >> конечному зрителю сильно привязано к моим скриптам. А программеру с
 >> дизайнерами всегда трудно.

 AI> Кто мешает дизайнеру генерить ряд статичных страниц, которые программист
 AI> связывает в работающую систему. Иначе результаты работы дизайнера служат
 AI> исходными данными для работы программиста. Который думает лишь о том что
 AI> должно быть показано в таблице, а не как.
Это он сильно сказал. И верно.
Просто ты рассуждаешь от одного проекта - сваял, бабло забрал, ушел на рынок
торговать.

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

Так как логика в принципе везде одна и таже, а вот дезигн - разный.

Я вот например прочитал и задумался, а то до сих пор перловые генераторы
пхпшных классов юзал :) хотя это уже отдельный разговор :)


WBR Vitaly N. Akuloff,  Reply-To: mr_little@pisem.net

 

Здравствуйте Уважаемые.

"Alexei Ivanov" <A.Ivanov@tu-bs.de> wrote in message
news:3B155FE4.8C3F340C@tu-bs.de...
> > 1) XMLщики делают 1% работы
> > 2) остальные - 50%
> > 3) на стоимости же работ это почти не отражается
> > 4) т.к. XMLщики делают это быстрее, то и заказчик к ним относится
> > благосклонее
>
> Я прошу прощения, но твоими бы словами да медку хапнуть....
> Скажи ты сам веришь в то что написал?

да, и не только я один. хотя я расписал эо немного радужнее, но смысл
остаётся.

> Давай совсем просто смотреть.
> Если ты что-то делаешь один раз, то время потраченное на это можно
> не учитывать.
> Теперь получается что всю остальную жизнь ты работаешь в 99 раз продуктивнее.
> Для простоты возьмем 100.
> Тогда вместо ста человек за определенное время работу может выполнить один.
> Тогда 99 я должен уволить. Скажи куда делась безаработица среди программистов.
> Или почему в 100 раз не возросло кол-во сайтов или ты просто не стал
> в сто раз богаче?

нет, я имел в виду не это.
т.е. таблица умножения не сильно помогает при решении дифуров ;)
т.н. XMLщик может потратить своё "свободное" время на другие проекты.
Собственно что и происходит - чем меньше разработчик тратит времени и сил на
один сайт тем он больше их может сделать (или лучше).

> В остальном мире, больше 5% годовых это уже очень хорошо.
> В России до недавних пор, может и сейчас так, запросто можно было найти и 20 и 30
> и 50 %%. Экономика правда разрушается, но прибыли то растут....
> Может это тоже использование XML?

ну не надо путать баян с баянистом ;)
я указал цыфры только для дизайнера и девелопера, про продвижение сайта, его
информационное наполнение, администрирование и т.д. и т.п. я не говорил.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Ed V. Bartosh" <ed@vitebsk.net> wrote in message
news:85u221x6rv.fsf@bartosh.org...
> YM> Нет, уже сейчас можно сказать. Потому что при смене дизайна код не меняется
> YM> ни на байт. Изменения при этом такие, что с помощью традиционных шаблонов
> YM> так не сделать.
>
> Можно пример ? А то я уже изготовился возражать насчет "cut & paste".
>
> Я, например дизайном не занимаюсь вообще, дизайнеры темплеты корректируют
> как хотят. Пока нареканий не возникало. В смысле не было случая (почти),
> чтобы для смены дизайна пришлось лезть в php-шный код. Хотя надо признать,
> что и кардинальной смены дизайна тоже не было :)

XML и иже с ним - стандарт де-юре, а через год-два - де-факто
а прочие темплейты где ?
что будут делать дизайнеры если они и/или ты перейдут на другую работу ?
учить заново тамошиние темплейты или писать их заново ?

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Vitaliy N. Kravchenko" <kvn@phbme.ntu-kpi.kiev.ua> wrote in message
news:3B160A74.AAFA162D@phbme.ntu-kpi.kiev.ua...
> > Я пробовал и то, и другое. Темплейты сосут. Я так думаю.
> Ну сосут, это громко сказано, потому как, нужно рассматривать зачем
> придумали темплейты, а зачем XML.
> Потому как я думаю, что XML - для отделения данных, а темплейты - для
> отделения дизайна, от программирования..
> IMHO.

наверняка, имелись в виду не XML-related темплейты, т.е. не XSL/XSLT.
И я в своих письмах имел в виду именно это.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Hello Alexei!

31 May 01 00:24, Alexei Ivanov wrote to All:
 >> Судя по всему, sehr geehrter Herr Ivanov видел succesful команду
 AI> чего видел?
Успешную. Здесь: успешно выполняющую проекты и не менее успешно
получающую за это деньги.

 >> cut-n-paste'щиков, но не видел ни одной команды XML-щиков, succesful
 >> в частности. Я прав? Если нет, живые примеры изложенной теории
 >> "о неполучении денег XML-щикам", bitte.
 AI> Hу если они ничего не делают (1%), за что ж они деньги получают?
Таки я прав или нет?

А насчет ничего они делают и 1%, так это явная гипербола,
причем еще и высказанная не тем, кто начал рассказ про XML...

 AI> Можно статистически прикинуть вероятность нахождения работ
 AI> "мне тоже самое, только с перламутровыми пуговицами" которая не
 AI> реализуется теми же темплейтами, в общем объеме работ?
Hе о том речь. Можно и теми же темплейтами что-то делать.
Можно и XML'ем. Можно для нового клиента и на темплейтах пиджачок
оставить, и к нему юбку сшить, плюс фасончик поменять да пуговицы
приструнить, можно и поверх XML'я налепить описание того, как
должен выглядеть костюм. Очевидно, что XML не панацея, но если
что-то как-то можно с его помощью сделать красивее, проще или
удобнее, надо смотреть и делать, а не хаять, да еще и за глаза,
как я понимаю.

 >> ... But it seems like it's going wrong again...
 AI> Das hast Du ja recht.
Have you ever had a feeling that it's rather unwise to poke
at randomly selected quotes?

- Andrew

... This is a noise that keeps me awake, my head explodes and my body aches...
 

Hi, Vladlen!

/Thu, 31 May 2001 17:27:29 +0000 (UTC)/ you wrote:

 >> Я, например дизайном не занимаюсь вообще, дизайнеры темплеты корректируют
 >> как хотят. Пока нареканий не возникало. В смысле не было случая (почти),
 >> чтобы для смены дизайна пришлось лезть в php-шный код. Хотя надо признать,
 >> что и кардинальной смены дизайна тоже не было :)

VB> XML и иже с ним - стандарт де-юре, а через год-два - де-факто
VB> а прочие темплейты где ?
VB> что будут делать дизайнеры если они и/или ты перейдут на другую работу ?
VB> учить заново тамошиние темплейты или писать их заново ?

Hа всякий случай уточняю - речь идет об HTML-темплейтах. И учить там ничего
не надо, по крайней мере это не сравнимо по объему с изучением XSLT.
И стандарт тоже есть - HTML 4.0 specification :)

А насчет XML, так я как бы и не возражал, что нужно его изучать и
применять. Хотя почитав одноименный тред в ru.xml я понял, что совместно
с php его использовать - это не совсем правильно, там свои технологии,
так что получиться скорее всего вместо php, чем совместно.
К тому же проблемы с хостингом будут налицо, судя по всему.
Hарод его юзает для серьезных корпоративных решений, там подход совсем 
другой. И соответственно инструментарий.

-- 
Best regards, Ed
 

Hello Ed!

01 Jun 01 10:23, Ed V Bartosh wrote to "Vladlen Bulatov":
 EB> А насчет XML, так я как бы и не возражал, что нужно его изучать и
 EB> применять. Хотя почитав одноименный тред в ru.xml я понял, что
 EB> совместно с php его использовать - это не совсем правильно, там свои
 EB> технологии, так что получиться скорее всего вместо php, чем совместно.
XML _вместо_ PHP - это, видимо, круто, но представить очень уж сложно. ;)

- Andrew

... I've got devotion, construction is my aim...
 

"Alexei Ivanov" <A.Ivanov@tu-bs.de> wrote in message
news:3B1618DE.485D8E42@tu-bs.de...

> 1. Если делал паровоз, а оказался нужен автомобиль, то и XML не спасет.

Это универсальное явление, никак не зависящее от инструментария. Если ты
делаешь не то, что от тебя требуется, то поможет только большая увесистая
дубина. Что XML, что HTML, что даже plain text тут бессильны.

> Последний раз возвращаясь к XML. В нем есть практический смысл, когда
> структура данных не известна в принципе. Он позволяет эту структуру упорядочить
> чтобы было легче разбирать.

XML был придуман для того, чтобы _существующие_ средства просмотра данных,
могли отображать любые _существующие_ или еще _не_существующие_ структуры
данных на основе _стандартного_ и _понятного_ описания этих самых структур и
способа/формата их отображения. Классический пример - вывод химических
формул.

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


--
George Sudarkoff.com
Fremont, CA


 

    Hello, Yuri!

Четверг Май 31 2001, Yuri Makassiouk изволил/a написать All:

 >> Последний раз возвращаясь к XML. В нем есть практический смысл,
 >> когда структура данных не известна в принципе. Он позволяет эту
 >> структуру упорядочить чтобы было легче разбирать.
 YM> А зачем тогда DTD и схемы? Что это за высказывания, кстати - твое
 YM> мнение? Пример приложения, работающего с данными, структура которых
 YM> неизвестна в принципе, мне был бы любопытен тоже (с чисто
 YM> исследовательской позиции =))

Hу, например, стоит задача сделать ввод/вывод таблиц с данными. При этом
известно, что структура таблиц будет меняться, т.е. разное число колонок и
разные захваты колонок у шапки. Вот тебе и "неизвестная структура данных".

При этом можно было бы, конечно, сесть, подумать головой и составить десяток
шаблонов, охватывающих любой вариант структуры. Hо, светлые головы, под
названием "программисты", сказали: "Да нафига, если можно это загнать в XML?" И
сделали вводилку данных, козлы.:(

   Bye, Andrey Ostanovsky.                    aost@gbk.spb.ru

 

Здравствуйте Уважаемые.

"Ed V. Bartosh" <ed@vitebsk.net> wrote in message
news:85vgmh89g5.fsf@bartosh.org...
> VB> XML и иже с ним - стандарт де-юре, а через год-два - де-факто
> VB> а прочие темплейты где ?
> VB> что будут делать дизайнеры если они и/или ты перейдут на другую работу ?
> VB> учить заново тамошиние темплейты или писать их заново ?
> Hа всякий случай уточняю - речь идет об HTML-темплейтах. И учить там ничего
> не надо, по крайней мере это не сравнимо по объему с изучением XSLT.
> И стандарт тоже есть - HTML 4.0 specification :)

а вот с этого места подробнее, плз.
где это в HTML Spec есть что-то про темплейты ?

> А насчет XML, так я как бы и не возражал, что нужно его изучать и
> применять. Хотя почитав одноименный тред в ru.xml я понял, что совместно

не изучая ничего нового можно довольно быстро потерять в зарплате ;)

> с php его использовать - это не совсем правильно, там свои технологии,
> так что получиться скорее всего вместо php, чем совместно.

какие-такие "свои" ? чем ПХП так кардинально отличается от АСП и ДжиСП, что
и там и там использование XML считается оправданным, а в ПХП - нет ?

> К тому же проблемы с хостингом будут налицо, судя по всему.
> Hарод его юзает для серьезных корпоративных решений, там подход совсем
> другой. И соответственно инструментарий.

"проблемы" с хостингом бывают только или у мелких сайтиков или у
малоденежных сайтов, у всех же остальных это решается или colocation или
вообще своим сервером у себя же на канале.

очень простой расчёт - если за сайт платят более 5к грин,
то потратив на сервер около 1к грин и за colocation около 200 в месяц -
совсем не большая прибавка, за то руки ни чем не связаны.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Hi, Vladlen!

/Sat, 2 Jun 2001 10:21:44 +0000 (UTC)/ you wrote:

 >> Hа всякий случай уточняю - речь идет об HTML-темплейтах. И учить там VB> ничего
 >> не надо, по крайней мере это не сравнимо по объему с изучением XSLT.
 >> И стандарт тоже есть - HTML 4.0 specification :)

VB> а вот с этого места подробнее, плз.
VB> где это в HTML Spec есть что-то про темплейты ?
Hет там ничего. 
HTML темплейты - это по сути чистый HTML, только переменные
выделены, ну и динамические блоки, если они есть. Вот и все отличия.
В отличие от XSLT в HTML-темплейтах нет логики, просто подстановка,
поэтому учить там нечего. А XSL - это намного сложнее, попробуй пересади на
него дизайнера, он будет сопротивляться, это ж дополнительный напряг.

 >> А насчет XML, так я как бы и не возражал, что нужно его изучать и
 >> применять. Хотя почитав одноименный тред в ru.xml я понял, что совместно

VB> не изучая ничего нового можно довольно быстро потерять в зарплате ;)
:) Поддерживаю. 
 >> с php его использовать - это не совсем правильно, там свои технологии,
 >> так что получиться скорее всего вместо php, чем совместно.

VB> какие-такие "свои" ? чем ПХП так кардинально отличается от АСП и ДжиСП, что
VB> и там и там использование XML считается оправданным, а в ПХП - нет ?

А кто его знает, но читая ru.xml у меня создалось именно такое впечатление.
Hе жалуют его там.
И здается мне, что у PHP как-то скудновато развито направление XML.

А можно вопрос немного не в тему ?
Что мне нужно поставить для начала, чтобы поработать с XML технологиями ?
Hачиная с JVM. А то глаза разбегаются - много там всего как то.
Да, буду ставить на Linux. Если можно, то урлы или названия и порядок 
установки.
Я так понял, что многие пользуются решениями от apache group, у IBM/Oracle/
Microsoft/Sun и прочих гигантов свои прилады. Как в этом разобраться-то ?
Времени нет все смотреть, мне интересны скажем так принципы построения
Вэб-приложений на основе XML.
И еще вопрос. Почему это все в основном на Java реализовано ?
есть конечно и C/C++ софт, но у меня создалось впечатление, что комплексные
решения именно на Java. Это мода или для пущей переносимости сделано ?

-- 
Best regards, Ed
 

Здравствуйте Уважаемые.

"Ed V. Bartosh" <ed@vitebsk.net> wrote in message
news:85lmnbnj4r.fsf@bartosh.org...
> VB> а вот с этого места подробнее, плз.
> VB> где это в HTML Spec есть что-то про темплейты ?
> Hет там ничего.

полная(!) документация по XSLT занимает 30 с небольшим страниц.
а если учесть, что совсем всю её можно не читать, то получается вообще около
15-и, что может осилить даже самый "глюпый" дизайнер.
Только здесь надо учитывать, что на XSLT то же можно "программировать", но
этим должен заниматься уже программист. Т.е. как только возникают проблемы
связанные, например, с XPath - то этим должен по большей части заниматься
программист.

> HTML темплейты - это по сути чистый HTML, только переменные
> выделены, ну и динамические блоки, если они есть. Вот и все отличия.

Т.е. ПХП это и есть "HTML темплейты" ?
или я что-то недопонимаю ?

> В отличие от XSLT в HTML-темплейтах нет логики, просто подстановка,
> поэтому учить там нечего. А XSL - это намного сложнее, попробуй пересади на
> него дизайнера, он будет сопротивляться, это ж дополнительный напряг.

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

>  >> с php его использовать - это не совсем правильно, там свои технологии,
>  >> так что получиться скорее всего вместо php, чем совместно.
> VB> какие-такие "свои" ? чем ПХП так кардинально отличается от АСП и ДжиСП, что
> VB> и там и там использование XML считается оправданным, а в ПХП - нет ?
>
> А кто его знает, но читая ru.xml у меня создалось именно такое впечатление.
> Hе жалуют его там.

что поделать, ПХП предоставляет много меньше наращиваемых сервисов, поэтому
и нелюбят.
(блин, вяклун, сейчас опять волна флейма поднимется)

> И здается мне, что у PHP как-то скудновато развито направление XML.

именно, ПХП вообще как то странно стал развиваться в ширь, а не в глубь.
Т.е. добавляется куча библиотек, вносятся изменения в язык, но качественного
рывка нет ;(

> А можно вопрос немного не в тему ?


<offtopic>

> Что мне нужно поставить для начала, чтобы поработать с XML технологиями ?

совсем для начала сгодится и MSXML

> Hачиная с JVM. А то глаза разбегаются - много там всего как то.

на сколько я понял, ты про яву,
тогда ставь:
1) Sun JDK 1.3 (http://java.sun.com/j2se/1.3/)
если просто хочешь немного поиграться - тебе этого хватит

2) Apache Xerces и Xalan (http://xml.apache.org/)
этого тебе уже хватит, что бы более менее полноценно "пощупать"

3) JSP/Servlet Server
3.1) Apache Tomcat (http://jakarta.apache.org/)
как референс-платформа сгодится, но настраивать его несколько трудновато
3.2) Orion Server (http://www.orionserver.com/)
много проще ставится, но отнюдь не бесплатен
3.3) Resin Server (http://www.caucho.com/products/resin)
ставиться тоже легко, но для некоммерческих челей и девелопинга - бесплатен

> Да, буду ставить на Linux. Если можно, то урлы или названия и порядок
> установки.

лучше прочитать ридми, а если будут проьблемы - спрашивай

> Я так понял, что многие пользуются решениями от apache group, у IBM/Oracle/
> Microsoft/Sun и прочих гигантов свои прилады. Как в этом разобраться-то ?

а как ты выбираешь SQL-сервер ? ;)
так и здесь - разные АПИ, но суть одна и та же

> Времени нет все смотреть, мне интересны скажем так принципы построения
> Вэб-приложений на основе XML.

у Ресина на эту тему есть неплохой туториал

> И еще вопрос. Почему это все в основном на Java реализовано ?

переносимо, практически куда угодно

> есть конечно и C/C++ софт, но у меня создалось впечатление, что комплексные
> решения именно на Java. Это мода или для пущей переносимости сделано ?

по большей части - последнее, но и мода здесь тоже "играет" ;)

</offtopic>

PS
  Вот еслиб для ПХП также всё делалось - былоб много лучше

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Hi, Vladlen!

/Sat, 2 Jun 2001 17:59:50 +0000 (UTC)/ you wrote:

 >> VB> а вот с этого места подробнее, плз.
 >> VB> где это в HTML Spec есть что-то про темплейты ?
 >> Hет там ничего.

VB> полная(!) документация по XSLT занимает 30 с небольшим страниц.
VB> а если учесть, что совсем всю её можно не читать, то получается вообще около
VB> 15-и, что может осилить даже самый "глюпый" дизайнер.
VB> Только здесь надо учитывать, что на XSLT то же можно "программировать", но
VB> этим должен заниматься уже программист. Т.е. как только возникают проблемы
VB> связанные, например, с XPath - то этим должен по большей части заниматься
VB> программист.

 >> HTML темплейты - это по сути чистый HTML, только переменные
 >> выделены, ну и динамические блоки, если они есть. Вот и все отличия.

VB> Т.е. ПХП это и есть "HTML темплейты" ?
VB> или я что-то недопонимаю ?
Hе совсем. Ты имеешь ввиду использование PHP как HTML-embedded language,
а технология темплейтов - это использование отдельно php для логики
приложения и отдельно HTML-темплейтов для оформиловки.
При использовании этой технологии в общем случае в .php файлах нет HTML 
кода, а в темплейтах нет php-шного.
Это собственно позволяет программисту и дизайнеру не мешать друг другу
и делать каждому свою часть. Достаточно удобно. И крайне просто.

 >> В отличие от XSLT в HTML-темплейтах нет логики, просто подстановка,
 >> поэтому учить там нечего. А XSL - это намного сложнее, попробуй пересади VB> на
 >> него дизайнера, он будет сопротивляться, это ж дополнительный напряг.

VB> Просто, надо потратить некоторое время на обучение дизайнера. Народ "от
VB> кисти или карандаша" часто учится чему то новому если уж очень приспичит, да
VB> и то всякий раз пытается увильнуть, т.ч. это проблема немного из другой
VB> области.
Так я как-раз это и имею ввиду. При работе с HTML-темплейтами им особо 
напрягаться не приходится, там почти чистый HTML. И добровольно они на
XSL не пойдут, им и так хорошо :)

 >>  >> с php его использовать - это не совсем правильно, там свои технологии,
 >>  >> так что получиться скорее всего вместо php, чем совместно.
 >> VB> какие-такие "свои" ? чем ПХП так кардинально отличается от АСП и VB> ДжиСП, что
 >> VB> и там и там использование XML считается оправданным, а в ПХП - нет ?
 >>
 >> А кто его знает, но читая ru.xml у меня создалось именно такое VB> впечатление.
 >> Hе жалуют его там.

VB> что поделать, ПХП предоставляет много меньше наращиваемых сервисов, поэтому
VB> и нелюбят.
VB> (блин, вяклун, сейчас опять волна флейма поднимется)

Hе поднимется, до сюда многие не дочитают :)

 >> И здается мне, что у PHP как-то скудновато развито направление XML.

VB> именно, ПХП вообще как то странно стал развиваться в ширь, а не в глубь.
VB> Т.е. добавляется куча библиотек, вносятся изменения в язык, но качественного
VB> рывка нет ;(

В ширь он развивается кем попало, благо расширения к нему писать несложно,
а вглубь ... ну можно сказать, что переход на Zend engine год назад и
был таким рывком вглубь. Времени еще немного прошло, так что по мне не
все так плохо.
А ты что имел ввиду под "рывком" ? Hаправление ?

VB> <offtopic>
Hу так пошли в ru.xml, только там народ такой серьезный, страашно :)

 >> Что мне нужно поставить для начала, чтобы поработать с XML технологиями ?

VB> совсем для начала сгодится и MSXML
Это не мой путь. Hе люблю я этого. Этож клиент-сайд, я так разумею.

 >> Hачиная с JVM. А то глаза разбегаются - много там всего как то.

VB> на сколько я понял, ты про яву,
А что есть варианты ? В смысле есть полноценные переносимые решения на
других языках ?

VB> тогда ставь:
VB> 1) Sun JDK 1.3 (http://java.sun.com/j2se/1.3/)
VB> если просто хочешь немного поиграться - тебе этого хватит
Hет, не хватит, я хочу поиграться не с javой, а с XML,
причем не просто поиграться, а сделать небольшую работу и понять для себя
как оно все работает, по возможности детально.

VB> 2) Apache Xerces и Xalan (http://xml.apache.org/)
VB> этого тебе уже хватит, что бы более менее полноценно "пощупать"

VB> 3) JSP/Servlet Server
VB> 3.1) Apache Tomcat (http://jakarta.apache.org/)
VB> как референс-платформа сгодится, но настраивать его несколько трудновато
VB> 3.2) Orion Server (http://www.orionserver.com/)
VB> много проще ставится, но отнюдь не бесплатен
VB> 3.3) Resin Server (http://www.caucho.com/products/resin)
VB> ставиться тоже легко, но для некоммерческих челей и девелопинга - бесплатен

 >> Да, буду ставить на Linux. Если можно, то урлы или названия и порядок
 >> установки.

VB> лучше прочитать ридми, а если будут проьблемы - спрашивай

Ловлю на слове :)

 >> Я так понял, что многие пользуются решениями от apache group, у VB> IBM/Oracle/
 >> Microsoft/Sun и прочих гигантов свои прилады. Как в этом разобраться-то ?

VB> а как ты выбираешь SQL-сервер ? ;)
VB> так и здесь - разные АПИ, но суть одна и та же
Вот суть я пока и не понимаю :(

 >> Времени нет все смотреть, мне интересны скажем так принципы построения
 >> Вэб-приложений на основе XML.

VB> у Ресина на эту тему есть неплохой туториал
Урл ?

VB> </offtopic>

VB> PS
VB>   Вот еслиб для ПХП также всё делалось - былоб много лучше
Так же это как ? Как для XML ? Hереально. разные весовые категории.

-- 
Best regards, Ed
 

> VB> Т.е. ПХП это и есть "HTML темплейты" ?
> VB> или я что-то недопонимаю ?
> Hе совсем. Ты имеешь ввиду использование PHP как HTML-embedded language,
> а технология темплейтов - это использование отдельно php для логики
> приложения и отдельно HTML-темплейтов для оформиловки.
> При использовании этой технологии в общем случае в .php файлах нет HTML
> кода, а в темплейтах нет php-шного.
> Это собственно позволяет программисту и дизайнеру не мешать друг другу
> и делать каждому свою часть. Достаточно удобно. И крайне просто.
Только негибко. По крайней мере, по сравнению с XSLT. Сорри, сорри.. не
встреваю больше =)

> VB> совсем для начала сгодится и MSXML
> Это не мой путь. Hе люблю я этого. Этож клиент-сайд, я так разумею.
Имхо, необязательно. Создай объект из асп и пользуй на серверсайде.. Это,
правда, сведения непроверенные, но, имея общее представление о
мелкомягких... Но тогда сервер-сайд - майкрософтовский...


--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

темплейт - класс оболочка !

ПС.Иногда так не хватает структур и темплейтов в пхп ... когда уже введут
наконец !
С уважением Арсен Кириллов http://www.softm.vov.ru



 

Недопонимаешь ! Темплейт - ?та оболочка для кода - то есть запсывая так:

struct one {
 int rrr;
 int bbb;
}

vector <one> struct_new; file://Использование шаблона
Так ты как-бы создаешь свой класс переменную которого и объявляешь
, на пхп для этого пришлось бы написать \
class vector_one{
 var rrr=array();
 var bbb=array();
 function Init()
{
 // Работаем с двумя масивами !
}
}

а в с++ одной строкой ! без выдумывания своего (еще одного) класса !
(не знаю как там в хмл-е наверное недалеко ушли ...)


 

Здравствуйте Уважаемые.

"Ed V. Bartosh" <ed@vitebsk.net> wrote in message
news:85lmnafsny.fsf@bartosh.org...
>  >> HTML темплейты - это по сути чистый HTML, только переменные
>  >> выделены, ну и динамические блоки, если они есть. Вот и все отличия.
> VB> Т.е. ПХП это и есть "HTML темплейты" ?
> VB> или я что-то недопонимаю ?
> Hе совсем. Ты имеешь ввиду использование PHP как HTML-embedded language,
> а технология темплейтов - это использование отдельно php для логики
> приложения и отдельно HTML-темплейтов для оформиловки.

Или я что-то не понимаю, или не так спрашиваю ;)
т.е. "HTML темплейты" тогда сродни SSI ? ;)

> При использовании этой технологии в общем случае в .php файлах нет HTML
> кода, а в темплейтах нет php-шного.

в темплейтах "псевдо-код" так и так будет, а какой он именно ПХП или ещё
что - без разницы, т.ч. ...

> Это собственно позволяет программисту и дизайнеру не мешать друг другу
> и делать каждому свою часть. Достаточно удобно. И крайне просто.

Это то понятно, но и гибкости в таком подходе как у кирпича.

> VB> Просто, надо потратить некоторое время на обучение дизайнера. Народ "от
> VB> кисти или карандаша" часто учится чему то новому если уж очень приспичит, да
> VB> и то всякий раз пытается увильнуть, т.ч. это проблема немного из другой
> VB> области.
> Так я как-раз это и имею ввиду. При работе с HTML-темплейтами им особо
> напрягаться не приходится, там почти чистый HTML. И добровольно они на
> XSL не пойдут, им и так хорошо :)

"Вкусивший один раз амброзии, будет помнить о ней всю жизнь" - это я про
декларативные темплейты, и XSL/XSLT из их числа.

>  >> А кто его знает, но читая ru.xml у меня создалось именно такое
>  >> впечатление. Hе жалуют его там.
> VB> что поделать, ПХП предоставляет много меньше наращиваемых сервисов, поэтому
> VB> и нелюбят.
> VB> (блин, вяклун, сейчас опять волна флейма поднимется)
> Hе поднимется, до сюда многие не дочитают :)

и это радует ;)

> VB> именно, ПХП вообще как то странно стал развиваться в ширь, а не в глубь.
> VB> Т.е. добавляется куча библиотек, вносятся изменения в язык, но качественного
> VB> рывка нет ;(
>
> В ширь он развивается кем попало, благо расширения к нему писать несложно,
> а вглубь ... ну можно сказать, что переход на Zend engine год назад и
> был таким рывком вглубь. Времени еще немного прошло, так что по мне не
> все так плохо.
> А ты что имел ввиду под "рывком" ? Hаправление ?

хотя бы общий интерфейс к разным СУБД, или возможность создания долгоживущих
объектов и возможность их локации, и т.д. и т.п.. Т.е. то что сделало бы ПХП
на самом деле мощным инструментом, а сейчас ... средство для дешёвого
хостинга.

> VB> <offtopic>
> Hу так пошли в ru.xml, только там народ такой серьезный, страашно :)

это правильная мысль

>  >> Что мне нужно поставить для начала, чтобы поработать с XML технологиями ?
> VB> совсем для начала сгодится и MSXML
> Это не мой путь. Hе люблю я этого. Этож клиент-сайд, я так разумею.

не обязательно. Потом, я же сказал, что "для начала", т.е. пописать
простенькие темплейты и т.п., а потом уже можно выбирать в зависимости от
используемой платформы.

>  >> Hачиная с JVM. А то глаза разбегаются - много там всего как то.
>
> VB> на сколько я понял, ты про яву,
> А что есть варианты ? В смысле есть полноценные переносимые решения на
> других языках ?

MSXML - Write once, run on 80% workstations :)

> VB> тогда ставь:
> VB> 1) Sun JDK 1.3 (http://java.sun.com/j2se/1.3/)
> VB> если просто хочешь немного поиграться - тебе этого хватит
> Hет, не хватит, я хочу поиграться не с javой, а с XML,
> причем не просто поиграться, а сделать небольшую работу и понять для себя
> как оно все работает, по возможности детально.

тогда Resin в руки и вперёд ;)

> VB> лучше прочитать ридми, а если будут проьблемы - спрашивай
> Ловлю на слове :)

при чём тогда уж лучше писать в ru.java

> VB> а как ты выбираешь SQL-сервер ? ;)
> VB> так и здесь - разные АПИ, но суть одна и та же
> Вот суть я пока и не понимаю :(

где должно работать и как, каковы требования к стоимости, переносимости и
так далее.

>  >> Времени нет все смотреть, мне интересны скажем так принципы построения
>  >> Вэб-приложений на основе XML.
>
> VB> у Ресина на эту тему есть неплохой туториал
> Урл ?

http://www.caucho.com, но он уже пару дней в "дауне", т.ч. можешь
воспользоваться "моей" копией - http://starcraft.org.ru/doc/index.xtp

> VB> </offtopic>
>
> VB> PS
> VB>   Вот еслиб для ПХП также всё делалось - былоб много лучше
> Так же это как ? Как для XML ? Hереально. разные весовые категории.

Всё зависит от усердия сообщества.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Yuri Makassiouk" <racer@bfpg.ru> wrote in message
news:9fbqjk$ufk$1@ddt.demos.su...
> > VB> совсем для начала сгодится и MSXML
> > Это не мой путь. Hе люблю я этого. Этож клиент-сайд, я так разумею.
> Имхо, необязательно. Создай объект из асп и пользуй на серверсайде.. Это,
> правда, сведения непроверенные, но, имея общее представление о
> мелкомягких... Но тогда сервер-сайд - майкрософтовский...

При этом стоит заметить, что MSXML это COM-component, то под Win32 можно и
из PHP использовать.
Кстати, у MS тоже есть очень не плохая документация -
http://msdn.microsoft.com/xml

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"ArsenKirillov" <softm@ipm.lviv.ua> wrote in message
news:9fdbba$ja7$2@news.uar.net...
> Недопонимаешь ! Темплейт - ?та оболочка для кода - то есть запсывая так:

как это выглядит и "работает" в С++ или Java 2 Merlin я знаю.
Но я спрашивал, как это выглядит в HTML ?
меня вроде убедили, что это и не ПХП, и не SSI и не XSL, но на вопрос не
ответили.

> struct one {
>  int rrr;
>  int bbb;
> }
>
> vector <one> struct_new; file://Использование шаблона

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

> > VB> Т.е. ПХП это и есть "HTML темплейты" ?
> > VB> или я что-то недопонимаю ?
> > Hе совсем. Ты имеешь ввиду использование PHP как HTML-embedded language,
> > а технология темплейтов - это использование отдельно php для логики
> > приложения и отдельно HTML-темплейтов для оформиловки.
>
> Или я что-то не понимаю, или не так спрашиваю ;)
> т.е. "HTML темплейты" тогда сродни SSI ? ;)

На всякий случай. А то разговор уже дошел до темплейт-классов. Темплейт -
про который тут начали говорить - HTML-мишень с дырками типа
"<title>{PageTitle}</title>". Скрипт делает
$myTemplate->SetVariable('PageTitle', 'My cool page');
$myTemplate->Flush();

или что-то похожее.

> > Это собственно позволяет программисту и дизайнеру не мешать друг другу
> > и делать каждому свою часть. Достаточно удобно. И крайне просто.
>
> Это то понятно, но и гибкости в таком подходе как у кирпича.

Именно =)

> > VB> Просто, надо потратить некоторое время на обучение дизайнера. Народ "от
> > VB> кисти или карандаша" часто учится чему то новому если уж очень приспичит, да
> > VB> и то всякий раз пытается увильнуть, т.ч. это проблема немного из другой
> > VB> области.
> > Так я как-раз это и имею ввиду. При работе с HTML-темплейтами им особо
> > напрягаться не приходится, там почти чистый HTML. И добровольно они на
> > XSL не пойдут, им и так хорошо :)

А их очень много =))

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Hi, Yuri!

/Sat, 2 Jun 2001 22:52:15 +0000 (UTC)/ you wrote:

 >> VB> Т.е. ПХП это и есть "HTML темплейты" ?
 >> VB> или я что-то недопонимаю ?
 >> Hе совсем. Ты имеешь ввиду использование PHP как HTML-embedded language,
 >> а технология темплейтов - это использование отдельно php для логики
 >> приложения и отдельно HTML-темплейтов для оформиловки.
 >> При использовании этой технологии в общем случае в .php файлах нет HTML
 >> кода, а в темплейтах нет php-шного.
 >> Это собственно позволяет программисту и дизайнеру не мешать друг другу
 >> и делать каждому свою часть. Достаточно удобно. И крайне просто.
YM> Только негибко. По крайней мере, по сравнению с XSLT. Сорри, сорри.. не
YM> встреваю больше =)
Hу почему же.Это ж вроде не приватная беседа.
А насчет негибко - наверное ты прав, но лучше, чем php вместе с
HTML.

 >> VB> совсем для начала сгодится и MSXML
 >> Это не мой путь. Hе люблю я этого. Этож клиент-сайд, я так разумею.
YM> Имхо, необязательно. Создай объект из асп и пользуй на серверсайде.. Это,
YM> правда, сведения непроверенные, но, имея общее представление о
YM> мелкомягких... Но тогда сервер-сайд - майкрософтовский...

Плохо то, что он только майкрософтовский. Хочется переносимости хоть
на 2 платформы.

-- 
Best regards, Ed
 

"ArsenKirillov" <softm@ipm.lviv.ua> wrote in message
news:9fdbb9$ja7$1@news.uar.net...
> темплейт - класс оболочка !
>

И чего только не узнаешь в крютых программерских эхах. =)


--
George Sudarkoff.com
Fremont, CA


 

  dra til helvete, Vladlen.

 * quoting a message from Vladlen Bulatov to All:

 >> Hедопонимаешь ! Темплейт - ?та оболочка для кода - то есть запсывая так:
 VB> как это выглядит и "работает" в С++ или Java 2 Merlin я знаю.
 VB> Hо я спрашивал, как это выглядит в HTML ?
 VB> меня вроде убедили, что это и не ПХП, и не SSI и не XSL, но на вопрос не
 VB> ответили.

 если я правильно понял обсуждаемый предмет, то это выглядит так: имеется
файл-шаблон, в котором содержится неизменная часть страницы в том виде, как она
есть, а динамические части страницы заменяются специальными подстановками.
скрипт читает шаблон, заменяет подстановки их реальными значениями и выводит
уже готовую станицу в конце своей работы. это удобно тем, что код максимально
отделяется от дизайна.
 
 пример:
-- [on] --
<html>
<body>
This is a template
Today is: @TODAY@
</body>
</html>
-- [off] --

 здесь @TODAY@ -- это подстановка, которая скриптом заменится на сегодняшнюю
дату.

 http://www.thewebmasters.net -- тут лежит FastTemplates -- готовый модуль для
работы с шаблонами. ко всему прочему умеет динамические блоки -- удобно для
генерации разного рода табличек.

  t.w.a.s.k.

 

> > темплейт - класс оболочка !
> >
>
> И чего только не узнаешь в крютых программерских эхах. =)
> --
> George Sudarkoff.com
> Fremont, CA

Пальцы гнуть не надо, человек хоть и не по теме выступил, но
темплейт-классы - вещь вполне известная. C++ - слыхали в Калифорнии о таком?

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

А нахера ему в его калифорнии знать что такое с++ или пхп
они там поголовно на ява пишут или на вижуал бейсике !
Знаем бывалис...

> Пальцы гнуть не надо, человек хоть и не по теме выступил, но
> темплейт-классы - вещь вполне известная. C++ - слыхали в Калифорнии о
таком?



 

Hi, Andrew!

/Fri, 01 Jun 01 16:43:50 +0300/ you wrote to me:

AA> Hello Ed!

 EB>> А насчет XML, так я как бы и не возражал, что нужно его изучать и
 EB>> применять. Хотя почитав одноименный тред в ru.xml я понял, что
 EB>> совместно с php его использовать - это не совсем правильно, там свои
 EB>> технологии, так что получиться скорее всего вместо php, чем совместно.

AA> XML _вместо_ PHP - это, видимо, круто, но представить очень уж сложно. ;)

Я имел ввиду технологию в целом, а не XML как Markup language.
Hасчет крутости пока не знаю, посмотрим.

А ты что не мыслишь одно без другого или в чем напряг-то ?

-- 
Best regards, Ed
 

Hi, Vladlen!

/Sun, 3 Jun 2001 12:49:36 +0000 (UTC)/ you wrote:

 >>  >> HTML темплейты - это по сути чистый HTML, только переменные
 >>  >> выделены, ну и динамические блоки, если они есть. Вот и все отличия.
 >> VB> Т.е. ПХП это и есть "HTML темплейты" ?
 >> VB> или я что-то недопонимаю ?
 >> Hе совсем. Ты имеешь ввиду использование PHP как HTML-embedded language,
 >> а технология темплейтов - это использование отдельно php для логики
 >> приложения и отдельно HTML-темплейтов для оформиловки.

VB> Или я что-то не понимаю, или не так спрашиваю ;)
VB> т.е. "HTML темплейты" тогда сродни SSI ? ;)

Да нет же. Тут уже приводили пример, просто HTML с вставками
типа {VAR} в простейшем случае. А самв эта {VAR} устанавливается
в php в зависимости от логики приложения. Там еще как правило
есть динамика, ну это когда например таблицу надо сформировать,
тогда в темплейте делается блок на строку, а установка значений
для каждой строки делается в php.
Можно конечно пример привести, если хочешь, но большого смысла не вижу.
Короче, это нечто совершенно простое, но с другой стороны дающее
гораздо больше возможностей, чем стандартное (HTML-embedded) применение
php.

 >> При использовании этой технологии в общем случае в .php файлах нет HTML
 >> кода, а в темплейтах нет php-шного.

VB> в темплейтах "псевдо-код" так и так будет, а какой он именно ПХП или ещё
VB> что - без разницы, т.ч. ...

Hе знаю что ты имеешь ввиду, но там почти никакой нет, просто
подстановка значений.

 >> Это собственно позволяет программисту и дизайнеру не мешать друг другу
 >> и делать каждому свою часть. Достаточно удобно. И крайне просто.

VB> Это то понятно, но и гибкости в таком подходе как у кирпича.
Для простых вэб-приложений, а это как раз ниша php, вполне достаточно.

 >> А ты что имел ввиду под "рывком" ? Hаправление ?

VB> хотя бы общий интерфейс к разным СУБД, или возможность создания долгоживущих
VB> объектов и возможность их локации, и т.д. и т.п.. Т.е. то что сделало бы ПХП
VB> на самом деле мощным инструментом, а сейчас ... средство для дешёвого
VB> хостинга.

Hасчет общего интерфейса к DB - такая попытка сейчас делается, PEAR
называется. там кроме этого предлагается еще и общий подход к 
обработке ошибок и множество других юзабельных классов, например
Cache,Payment,Mail, etc. Hазвания сами за себя говорят. 
сейчас это на php пока пишется, но основа уже на C переписывается,
по-моему. Hо еще сыровато это, конечно.
А насчет долгоживущих объектов - в той схеме, в которой работает php
это невозможно. Вот тебе цитата на эту тему:

-----------------
> ADO/ADO+ has a built-in database engine so you don't have to cal
> database server (mysql or oracle etc) to do the sort! Similarly,
> ADO+ has filtering capabilities so we don't have to requery the 
> Searches also.

That's just because ADO+ is not just a database wrapper but also a
middle-ware. This means that it has server processes independent W
servers or from wherever the client applications are running that 
all sorts of things like connection pooling or query caching. This
be done right just with PHP because unlike other scripting languag
like Java, Perl or Python, PHP does not have multi-threading
capabilities.

With multi-threading capabilities you could write a middle-ware th
would manage a pool of connections and cache any pertinent queries
would be done on the middle-ware side. It would not make sense to 
queries on the client side because that is made just of short-live
page scripts.

I was about to write a connection pooling middleware server for Me
but I gave up because of the lack of multi-threading. It would not
able to handle concurrent queries properly, so it is preferrable t
persistant connections started by n web servers.

So, you can hardly blame this apparent limitation of PHP database
wrappers on them, but rather on the PHP limitation of not having proper
multi-threading support.
-----------------

Вот когда будет он middle-ware, тогда можно и говорить, а пока
имеем что имеем. С другой стороны "мамы всякие нужны" :)


 >> VB> на сколько я понял, ты про яву,
 >> А что есть варианты ? В смысле есть полноценные переносимые решения на
 >> других языках ?

VB> MSXML - Write once, run on 80% workstations :)

:) Я хочу "everywhere" или как там в оригинале. 
 >> VB> тогда ставь:
 >> VB> 1) Sun JDK 1.3 (http://java.sun.com/j2se/1.3/)
 >> VB> если просто хочешь немного поиграться - тебе этого хватит
 >> Hет, не хватит, я хочу поиграться не с javой, а с XML,
 >> причем не просто поиграться, а сделать небольшую работу и понять для себя
 >> как оно все работает, по возможности детально.

VB> тогда Resin в руки и вперёд ;)
Уже качаю все упомянутое. Большое оно все какое-то. 
А Резин это хорошо на посмотреть, а дальше ?
Hет ли чего-нить этого же класса, но забесплатно ?

 >> VB> у Ресина на эту тему есть неплохой туториал
 >> Урл ?

VB> http://www.caucho.com, но он уже пару дней в "дауне", т.ч. можешь
VB> воспользоваться "моей" копией - http://starcraft.org.ru/doc/index.xtp
Спасибо. Родной сайт, кстати, поднялся.

-- 
Best regards, Ed
 

Здравствуйте Уважаемые.

"alexey kolesnichenko" <alexey.kolesnichenko@p55.f25.n4651.z2.fidonet.org>
wrote in message news:991628841@p55.f25.n4651.z2.ftn...
>  VB> меня вроде убедили, что это и не ПХП, и не SSI и не XSL, но на вопрос не
>  VB> ответили.
>  если я правильно понял обсуждаемый предмет, то это выглядит так: имеется
> файл-шаблон, в котором содержится неизменная часть страницы в том виде, как она
> есть, а динамические части страницы заменяются специальными подстановками.
> скрипт читает шаблон, заменяет подстановки их реальными значениями и выводит
> уже готовую станицу в конце своей работы. это удобно тем, что код максимально
> отделяется от дизайна.

от дизайна - да, но для каждой страницы - дизайн (в общем виде) - разный

>  пример:
> -- [on] --
> <html>
> <body>
> This is a template
> Today is: @TODAY@
>
>  здесь @TODAY@ -- это подстановка, которая скриптом заменится на сегодняшнюю
> дату.

так это и есть немного(!) модернизированыый SSI

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Ed V. Bartosh" <ed@vitebsk.net> wrote in message
news:85y9r9mipl.fsf@bartosh.org...
> VB> Или я что-то не понимаю, или не так спрашиваю ;)
> VB> т.е. "HTML темплейты" тогда сродни SSI ? ;)
> Да нет же. Тут уже приводили пример, просто HTML с вставками
> типа {VAR} в простейшем случае. А самв эта {VAR} устанавливается
> в php в зависимости от логики приложения. Там еще как правило
> есть динамика, ну это когда например таблицу надо сформировать,
> тогда в темплейте делается блок на строку, а установка значений
> для каждой строки делается в php.

а чем тогда "это" лучше, чем следующее ?
<? include("init.php") ?>
<html>
<head>
  <title><?=title?></title>
</head>
<body>
  <div align="center"><?=some_body?></div>
</body>
</html>
т.е. подразумевается, что было -
<html>
<head>
  <title>{TITLE}</title>
</head>
<body>
  <div align="center">{SOME_BODY}</div>
</body>
</html>

> Можно конечно пример привести, если хочешь, но большого смысла не вижу.
> Короче, это нечто совершенно простое, но с другой стороны дающее
> гораздо больше возможностей, чем стандартное (HTML-embedded) применение
> php.

пока я большИх возможностей не вижу

>  >> При использовании этой технологии в общем случае в .php файлах нет HTML
>  >> кода, а в темплейтах нет php-шного.
>
> VB> в темплейтах "псевдо-код" так и так будет, а какой он именно ПХП или ещё
> VB> что - без разницы, т.ч. ...
>
> Hе знаю что ты имеешь ввиду, но там почти никакой нет, просто
> подстановка значений.

см. пример выше

> VB> Это то понятно, но и гибкости в таком подходе как у кирпича.
> Для простых вэб-приложений, а это как раз ниша php, вполне достаточно.

Хм, дело в том, что практика показывает - на ПХП делают не только простые
вёб-приложения.

>  >> А ты что имел ввиду под "рывком" ? Hаправление ?
>
> VB> хотя бы общий интерфейс к разным СУБД, или возможность создания долгоживущих
> VB> объектов и возможность их локации, и т.д. и т.п.. Т.е. то что сделало бы ПХП
> VB> на самом деле мощным инструментом, а сейчас ... средство для дешёвого
> VB> хостинга.
>
> Hасчет общего интерфейса к DB - такая попытка сейчас делается, PEAR
> называется. там кроме этого предлагается еще и общий подход к

http://www.php.net/manual/en/pear.php, это оно ?

> обработке ошибок и множество других юзабельных классов, например
> Cache,Payment,Mail, etc. Hазвания сами за себя говорят.
> сейчас это на php пока пишется, но основа уже на C переписывается,
> по-моему. Hо еще сыровато это, конечно.

"сырость" применимо к вёбу - стала уже привычной ;)

> А насчет долгоживущих объектов - в той схеме, в которой работает php
> это невозможно. Вот тебе цитата на эту тему:

так, всего то - поменять схему ;)

> -----------------
> > ADO/ADO+ has a built-in database engine so you don't have to cal
> > ...
> So, you can hardly blame this apparent limitation of PHP database
> wrappers on them, but rather on the PHP limitation of not having proper
> multi-threading support.
> -----------------

опять камень в тот же огород

> Вот когда будет он middle-ware, тогда можно и говорить, а пока
> имеем что имеем. С другой стороны "мамы всякие нужны" :)

что и прискорбно

>  >> VB> на сколько я понял, ты про яву, VB> MSXML - Write once, run on 80% workstations :)
> :) Я хочу "everywhere" или как там в оригинале.

;)

> VB> тогда Resin в руки и вперёд ;)
> Уже качаю все упомянутое. Большое оно все какое-то.
> А Резин это хорошо на посмотреть, а дальше ?

а после "посмотреть" можно и сразу в бой на нём же ;)

> Hет ли чего-нить этого же класса, но забесплатно ?

почитай лицензию, там написано когда он бесплатен, вполне может быть, что
тебе это подойдёт. Да и цена у ресина "не кусачая" - всего 500 грин с
базовым саппортом.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Hi, Vladlen!

/Mon, 4 Jun 2001 14:13:01 +0000 (UTC)/ you wrote:

 >> VB> Или я что-то не понимаю, или не так спрашиваю ;)
 >> VB> т.е. "HTML темплейты" тогда сродни SSI ? ;)
 >> Да нет же. Тут уже приводили пример, просто HTML с вставками
 >> типа {VAR} в простейшем случае. А самв эта {VAR} устанавливается
 >> в php в зависимости от логики приложения. Там еще как правило
 >> есть динамика, ну это когда например таблицу надо сформировать,
 >> тогда в темплейте делается блок на строку, а установка значений
 >> для каждой строки делается в php.

VB> а чем тогда "это" лучше, чем следующее ?
VB> <? include("init.php") ?>
VB> <html>
VB> <head>
VB>   <title><?=title?></title>
VB> </head>
VB> <body>
VB>   <div align="center"><?=some_body?></div>
VB> </body>
VB> </html>
VB> т.е. подразумевается, что было -
VB> <html>
VB> <head>
VB>   <title>{TITLE}</title>
VB> </head>
VB> <body>
VB>   <div align="center">{SOME_BODY}</div>
VB> </body>
VB> </html>

Тем, что <?=title?> (jsp, ya ?) подразумевает некий код здесь же,
который эту переменную определяет и присваивает ей некое значение. 
То есть налицо смешивание логики и представления.
А в случае с {TITLE} этого не происходит. Это переменная темплейта,
и как она вычисляется и где тому, кто работает с темплейтом до лампады,
точно также до лампады программеру что с этим {TITLE} в темплейте сделает
дизайнер.

 >> Можно конечно пример привести, если хочешь, но большого смысла не вижу.
 >> Короче, это нечто совершенно простое, но с другой стороны дающее
 >> гораздо больше возможностей, чем стандартное (HTML-embedded) применение
 >> php.

VB> пока я большИх возможностей не вижу

Принципиально данная технология позволяет отделить логику приложения от 
представления, что на самом деле очень большой шаг по сравнению с
embedded технологией, где логика идет вперемешку с дизайном. Причем это
не зависит от языка - PHP/ASP/JSP при применении их в embedded варианте
ведут к такому смешиванию.

Вот, почитай статейку про JSP, я только сегодня прочитал и порадовался
за себя - я это все на PHP проходил, а мужик тоже самое про JSP пишет.
-------------------
Brett McLaughlin
Enhydra Strategist, Lutris Technologies
October 2000
Автор - опытный разработчик java и приверженец технологии Enhydra, убеждает
разработчиков рассматривать альтернативы JavaServer Pages (JSP) servlets
при выборе средства разработки веб приложений. Технология JSP это часть
платформы J2EE компании Sun призвана решить проблему визуального
отображения данных. Реально, JSP не совсем отвечает всем чаяниям
разработчиков. На данный момент существует несколько различных подходов к
решению проблемы презентации данных и вы можете выбирать. Эта статья
проводит анализ программирования на JSP и рассматривает возможные
альтернативы.
------------------
Он, кстати и предлагает темплейты для jsp, как одно из решений:
"* Если вы не желаете расстоваться с java, вам могут помочь template
engines! Два наиболее популярные это WebMacro и FreeMarker."

Вот урл, крайне рекомендую: 
http://www.javable.com/columns/serv_side/opinions/01/


 >> Hе знаю что ты имеешь ввиду, но там почти никакой нет, просто
 >> подстановка значений.

VB> см. пример выше
В твоем примере не видно, где переменная получает значение.
Я также на php могу написать: <? echo $title?>, но это не значит,
что выше я не наверну кусок кода, который скажем берет нечто из базы
данных, а потом на основании этого нечто присваивает $title значение.
Полагаю, что и в jsp так же. Или я не прав ?

 >> Hасчет общего интерфейса к DB - такая попытка сейчас делается, PEAR
 >> называется. там кроме этого предлагается еще и общий подход к

VB> http://www.php.net/manual/en/pear.php, это оно ?
Hу, это только пару строк о нем, его надо смотреть в сорцах,
сейчас оно идет вместе с php, начиная с 4.0.3 или 4.0.4
Можно прям с CVSа - cvs.php.net /php4/pear

 >> А насчет долгоживущих объектов - в той схеме, в которой работает php
 >> это невозможно. Вот тебе цитата на эту тему:

VB> так, всего то - поменять схему ;)
:)
Лучше добавить. Пусть и эта остается. Дешево и сердито :)

 >> Вот когда будет он middle-ware, тогда можно и говорить, а пока
 >> имеем что имеем. С другой стороны "мамы всякие нужны" :)

VB> что и прискорбно
А меня это как раз таки и радует :)

-- 
Best regards, Ed
 

Hello Ed!

02 Jun 01 10:36, Ed V Bartosh wrote to Andrew Aksyonoff:
 AA>> XML _вместо_ PHP - это, видимо, круто, но представить очень уж
 AA>> сложно. ;)
 EB> Я имел ввиду технологию в целом, а не XML как Markup language.
Опять те же проблемы с семантикой - технология XML в целом это что
такое? ;) Впрочем, теперь понятно, что ты, видимо, подразумевал другие
технологии, которые поддерживают XML. Так бы сразу и сказал. ;)

- Andrew

... It's a beautiful day - it's rainy and it's cold.
 

Hello Vladlen!

03 Jun 01 15:49, Vladlen Bulatov wrote to All:
 VB> хотя бы общий интерфейс к разным СУБД,
Собственно, это уже не расширение самого языка - аналог
DBI для PHP потенциально можно создать уже сейчас. Hо кто
этим будет бесплатно заниматься? :-)

- Andrew

... Gimme fuel, gimme fire, gimme that wich I desire...
 

Hi,

Yuri Makassiouk wrote:

> > > темплейт - класс оболочка !
> > И чего только не узнаешь в крютых программерских эхах. =)
> Пальцы гнуть не надо, человек хоть и не по теме выступил, но
> темплейт-классы - вещь вполне известная. C++ - слыхали в Калифорнии о таком?

Ты поосторожнее...
А там там обидятся и уже ты больше о С++ не услышишь....

P.S. Историю стоит знать...

-- 
Alexei
 

Hi,

George Sudarkoff wrote:

> > 1. Если делал паровоз, а оказался нужен автомобиль, то и XML не спасет. 
> Это универсальное явление, никак не зависящее от инструментария. Если ты
> делаешь не то, что от тебя требуется, то поможет только большая увесистая
> дубина. Что XML, что HTML, что даже plain text тут бессильны.

Я не понял только, зачем было меня повторять???

> XML был придуман для того, чтобы _существующие_ средства просмотра данных,
> могли отображать любые _существующие_ или еще _не_существующие_ структуры
> данных на основе _стандартного_ и _понятного_ описания этих самых структур и
> способа/формата их отображения. Классический пример - вывод химических
> формул.
> 
> То же, что представление отделено от собственно данных - является лишь
> очевидным отличием XML от HTML, с которым его, по-недоразумению, чаще всего
> сравнивают.

...Именно поэтому он и не имеет никакого отношения к Web.

-- 
Alexei

 

  dra til helvete, Vladlen.

 * quoting a message from Vladlen Bulatov to All:

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

 VB> от дизайна - да, но для каждой страницы - дизайн (в общем виде) - разный
 
 правильно. для каждой страницы -- свой шаблон.

 >> -- [on] --
 >> <html>
 >> <body>
 >> This is a template
 >> Today is: @TODAY@
 >>  здесь @TODAY@ -- это подстановка, которая скриптом заменится на
 VB> сегодняшнюю дату.

 VB> так это и есть немного(!) модернизированыый SSI

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

  t.w.a.s.k.

 

Здравствуйте Уважаемые.

"alexey kolesnichenko" <alexey.kolesnichenko@p55.f25.n4651.z2.fidonet.org>
wrote in message news:991744209@p55.f25.n4651.z2.ftn...
>  >> -- [on] --
>  >> <html>
>  >> <body>
>  >> This is a template
>  >> Today is: @TODAY@
>  >>  здесь @TODAY@ -- это подстановка, которая скриптом заменится на
>  VB> сегодняшнюю дату.
>
>  VB> так это и есть немного(!) модернизированыый SSI
>
>  это был элементарный пример. более сложные шаблоны используют всякого рода
> динамические блоки. я сегодня, например, ваял шаблоны, в которых были
> динамические блоки в динамических блоках. увлекательное занятие, надо сказать.
> ;)

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

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Hello Vladlen!

05 Jun 01 21:52, Vladlen Bulatov wrote to All:
 >>  >> Today is: @TODAY@
 VB> а SSI опять не угодил ?
А не черезжопенно ли на каждый чих вместо {TITLE} или @TITLE@
или даже (упаси господь так оголодать) <?=$title=?> вставлять
SSI-ную строчку, которая вызовет скрипт, который посчитает один
параметр? ;)

Или я чего-то слишком диагонально прочитал, и с помощью SSI
очень красиво и аккуратно можно _одним_ скриптом посчитать кучу
параметров и всунуть их в нужные места в шаблон? причем некоторые
куски шаблона повторит {N} раз с разными данными? причем {N}
рассчитывается самим скриптом? А ведь тривиальная задачка и
очень частая - плюнуть кусок базы в браузер.

 VB> сколько уже велосипедов придумано ...
До фига. Какие предложишь решения лучше? Hеужели SSI? Тогда
пример в студию. Да и собственно, если не SSI, тоже пример хочется. ;)

- Andrew

... I was me but now he's gone...
 

Здравствуйте Уважаемые.

"Andrew Aksyonoff" <Andrew.Aksyonoff@p2.f29.n5036.z2.fidonet.org> wrote in
message news:991790411@p2.f29.n5036.z2.ftn...
> Hello Vladlen!
>
> 05 Jun 01 21:52, Vladlen Bulatov wrote to All:
>  >>  >> Today is: @TODAY@
>  VB> а SSI опять не угодил ?
> А не черезжопенно ли на каждый чих вместо {TITLE} или @TITLE@
> или даже (упаси господь так оголодать) <?=$title=?> вставлять
> SSI-ную строчку, которая вызовет скрипт, который посчитает один
> параметр? ;)

я имел в виду, что подобные шаблоны ничем от SSI коренным образом не
отличаются.
а если SSI-процессор на каждый "чих" что-то там вызывает - так это проблемы
конкретного процессора, а не SSI в общем виде.

> Или я чего-то слишком диагонально прочитал, и с помощью SSI
> очень красиво и аккуратно можно _одним_ скриптом посчитать кучу
> параметров и всунуть их в нужные места в шаблон? причем некоторые
> куски шаблона повторит {N} раз с разными данными? причем {N}
> рассчитывается самим скриптом? А ведь тривиальная задачка и
> очень частая - плюнуть кусок базы в браузер.

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

>  VB> сколько уже велосипедов придумано ...
> До фига. Какие предложишь решения лучше? Hеужели SSI? Тогда
> пример в студию. Да и собственно, если не SSI, тоже пример хочется. ;)

XSLT спасёт отца русской демократии, а если "одолеть" XPath с XLink и
XPointer, то вообще много покажется совсем простым.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Hello Vladlen!

06 Jun 01 12:59, Vladlen Bulatov wrote to All:
 VB> я имел в виду, что подобные шаблоны ничем от SSI коренным образом не
 VB> отличаются. а если SSI-процессор на каждый "чих" что-то там вызывает
 VB> - так это проблемы конкретного процессора, а не SSI в общем виде.
[skip]
 VB> SSI-процессор может иметь и большее кол-во инструкций, чем требуется
 VB> стандартом, т.ч. всякие там циклы и "прочая" вполне реализуемы.
Я задам только один вопрос. Что это за SSI-процессор такой,
который умеет 1) один раз вызвать внешний скрипт 2) каким-то
образом определить, что ему вернули вот это и вот это 3) имеет
все нужные нестандартные инструкции? А еще лучше URL. Сразу же
поставлю, не глядя...

 >> До фига. Какие предложишь решения лучше? Hеужели SSI? Тогда пример в
 >> студию. Да и собственно, если не SSI, тоже пример хочется. ;)
 VB> XSLT спасёт отца русской демократии, а если "одолеть" XPath с XLink и
 VB> XPointer, то вообще много покажется совсем простым.
1) простенький пример (хотя бы из моего предыдущего письма) - можно?
2) в результате в браузере что имеем, HTML или XHTML?

- Andrew

... Here I go, playing star again, there I go, turn the page...
 

>  >> До фига. Какие предложишь решения лучше? Hеужели SSI? Тогда пример в
>  >> студию. Да и собственно, если не SSI, тоже пример хочется. ;)
>  VB> XSLT спасёт отца русской демократии, а если "одолеть" XPath с XLink и
>  VB> XPointer, то вообще много покажется совсем простым.
> 1) простенький пример (хотя бы из моего предыдущего письма) - можно? Напиши - чего пример хочешь, конкретно.
> 2) в результате в браузере что имеем, HTML или XHTML?
Чего хочешь, то и генерируй, хоть голый текст...
А что за разница для браузера между HTML и XHTML?

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Здравствуйте Уважаемые.

"Andrew Aksyonoff" <Andrew.Aksyonoff@p2.f29.n5036.z2.fidonet.org> wrote in
message news:991870362@p2.f29.n5036.z2.ftn...
> Hello Vladlen!
>
> 06 Jun 01 12:59, Vladlen Bulatov wrote to All:
>  VB> я имел в виду, что подобные шаблоны ничем от SSI коренным образом не
>  VB> отличаются. а если SSI-процессор на каждый "чих" что-то там вызывает
>  VB> - так это проблемы конкретного процессора, а не SSI в общем виде.
> [skip]
>  VB> SSI-процессор может иметь и большее кол-во инструкций, чем требуется
>  VB> стандартом, т.ч. всякие там циклы и "прочая" вполне реализуемы.
> Я задам только один вопрос. Что это за SSI-процессор такой,
> который умеет 1) один раз вызвать внешний скрипт 2) каким-то
> образом определить, что ему вернули вот это и вот это 3) имеет
> все нужные нестандартные инструкции? А еще лучше URL. Сразу же
> поставлю, не глядя...

у тебя уже стоит ;)
все сервер-сайд-скриптин решения (PHP, ASP, JSP & etc), это и есть замена
SSI на что-то более "продвинутое". Хотя обычно, с изменением синтаксиса (в
сторону упрощения).

>  >> До фига. Какие предложишь решения лучше? Hеужели SSI? Тогда пример в
>  >> студию. Да и собственно, если не SSI, тоже пример хочется. ;)
>  VB> XSLT спасёт отца русской демократии, а если "одолеть" XPath с XLink и
>  VB> XPointer, то вообще много покажется совсем простым.
> 1) простенький пример (хотя бы из моего предыдущего письма) - можно?

пример на чём ? на XSL ?

> 2) в результате в браузере что имеем, HTML или XHTML?

а чем хуже XHTML, чем "неправильный"(т.е. не XHTML) HTML ?

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

*Hello Vitaliy!*
30.05.2001 13:58:18, Vitaliy N. Kravchenko wrote to All:

VNK> В хтмле у тебя обьединен _И_ дизайн _И_ инфоpмация (плюс еще некотоpые к
VNK> этому фаpшу еще и ПХП скpиптинг добавляют..).
VNK> С XML-ем этого нет. А когда и на что пеpеходить, это pешает каждый для
VNK> себя..

А pазве пpи использовании php/mySQL невозможно целиком отделить дизайн от
инфоpмации? По-моему, вполне возможно, и без особых усилий. В чем же тогда
получается выгода xml? Чуть более подpобно, пожалуйста.

*Your Sergio.*  [Team =Мексиканские негодяи=]
 

Sergio Starush wrote:

> VNK> В хтмле у тебя обьединен _И_ дизайн _И_ инфоpмация (плюс еще некотоpые к
> VNK> этому фаpшу еще и ПХП скpиптинг добавляют..).
> VNK> С XML-ем этого нет. А когда и на что пеpеходить, это pешает каждый для
> VNK> себя..
> А pазве пpи использовании php/mySQL невозможно целиком отделить дизайн от
> инфоpмации? По-моему, вполне возможно, и без особых усилий. В чем же тогда
> получается выгода xml? Чуть более подpобно, пожалуйста.

Сэр, Вы ничего не смыслите в новых технологиях!
Эти технологии выгодны не потому, что хороши, а потому что НО-ВЫЕ! -ВЫЯ -ВЫЁ.
И применять их ВЕЗДЕ наша задача. Так что уйдите и не мешайте прогрессу.

P.S. Я сказал в согласии с центральной линией партии?
     Может меня даже наградят... посмертно... :~~-)

-- 
Alexei
 

Hello, Sergio!

Thursday June 07 2001 17:09, Sergio Starush wrote to Vitaliy N. Kravchenko:

 SS> А pазве пpи использовании php/mySQL невозможно целиком отделить дизайн
 SS> от инфоpмации? По-моему, вполне возможно, и без особых усилий. В чем
 SS> же тогда получается выгода xml? Чуть более подpобно, пожалуйста.
     а) xml изначально создан для этой цели.
     б) php, просто, не смог стать стандартом. xml понимают не только браузеры
и парсеры, но и много чего еще.
     вобщем, а) вытекает из б).

Вебмастеринг для желающих разобраться: http://exper.ural.ru/
Andrew Golovin exper@inbox.ru

 

Hi,

Andrew Golovin wrote:

>  SS> А pазве пpи использовании php/mySQL невозможно целиком отделить дизайн
>  SS> от инфоpмации? По-моему, вполне возможно, и без особых усилий. В чем
>  SS> же тогда получается выгода xml? Чуть более подpобно, пожалуйста.
>      а) xml изначально создан для этой цели.
Серьезно?

>      б) php, просто, не смог стать стандартом. xml понимают не только браузеры
> и парсеры, но и много чего еще.

То есть их можно сравнивать? - Сильно!
Не подскажешь, тогда, что лучше MSSQL или С++?

>      вобщем, а) вытекает из б).
Уууу....

P.S. Да, похоже меня не наградят...

-- 
Alexei
 

Hello Yuri!

07 Jun 01 01:56, Yuri Makassiouk wrote to All:
 >> 1) простенький пример (хотя бы из моего предыдущего письма) - можно?
 YM> Hапиши - чего пример хочешь, конкретно.
Пример: нужно вывести несколько переменных и фрагмент базы на экран
(скажем, список товаров каких-нибудь). Задание параметров выборки не
интересует, только вывод. Хочу увидеть текст шаблона (и сопутствующих
файлов, if any), плюс указания на то, как это нужно парсить (ссылки
на нужные функции и/или extensions).

То есть хочу увидеть аналог

<title>{TITLE}</title>
<body><table>
<tmpl_loop DATAARRAY>
<tr><td>{DATAARRAY.title}</td><td>{DATAARRAY.price}</td></tr>
</tmpl_loop>
</table></body>

 >> 2) в результате в браузере что имеем, HTML или XHTML?
 YM> Чего хочешь, то и генерируй, хоть голый текст...
 YM> А что за разница для браузера между HTML и XHTML?
Я не уверен, что тот же Netscape сжует <br/>, а совместимость
с ним может потребоваться.

- Andrew

... Whatever I've done, I've been staring down the barrel of a gun...
 

Hello Vladlen!

07 Jun 01 17:18, Vladlen Bulatov wrote to All:
 >>  VB> я имел в виду, что подобные шаблоны ничем от SSI коренным
 VB> все сервер-сайд-скриптин решения (PHP, ASP, JSP & etc), это и есть
 VB> замена SSI на что-то более "продвинутое".
Таким образом, согласно твоим слова, подобные шаблоны ничем не
отличаются от смеси HTML+PHP. Так? А вот таки отличаются. Именно
тем, что дизайнеру надо реже дергать программиста, когда в голову
взбредет чего-то поменять, и наоборот. Какая-никакая, а изоляция
model и controller от view, которой ни в SSI, ни в твоем видении
PHP как замены SSI нету.

 >>  VB> XSLT спасёт отца русской демократии, а если "одолеть" XPath с
 >>  VB> XLink и XPointer, то вообще много покажется совсем простым.
 >> 1) простенький пример (хотя бы из моего предыдущего письма) - можно?
 VB> пример на чём ? на XSL ?
XSLT. Который спасет. ;)

 >> 2) в результате в браузере что имеем, HTML или XHTML?
 VB> а чем хуже XHTML, чем "неправильный"(т.е. не XHTML) HTML ?
Netscape его жрет нормально? Opera? WebTV?

- Andrew

... Into the mercy seat I climb, my head is shaved, my head is wired...
 

> > VNK> В хтмле у тебя обьединен _И_ дизайн _И_ инфоpмация (плюс еще некотоpые к
> > VNK> этому фаpшу еще и ПХП скpиптинг добавляют..).
> > VNK> С XML-ем этого нет. А когда и на что пеpеходить, это pешает каждый для
> > VNK> себя..
> > А pазве пpи использовании php/mySQL невозможно целиком отделить дизайн от
> > инфоpмации? По-моему, вполне возможно, и без особых усилий. В чем же тогда
> > получается выгода xml? Чуть более подpобно, пожалуйста.
>
> Сэр, Вы ничего не смыслите в новых технологиях!
> Эти технологии выгодны не потому, что хороши, а потому что НО-ВЫЕ! -ВЫЯ -ВЫЁ.
> И применять их ВЕЗДЕ наша задача. Так что уйдите и не мешайте прогрессу.
Флеймить прекращай...

2all:
Без усилий отделять с помощью только пхп == изобретать велосипед, который,
вдобавок, не под каждую задницу подойдет. XML/XSLT дает элегантное решение,
которое, вдобавок, содержит в себе больше потенциальных возможностей, чем
то, о чем ты думаешь, пока пишешь движок.

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/



 

>  >> 1) простенький пример (хотя бы из моего предыдущего письма) - можно?
>  YM> Hапиши - чего пример хочешь, конкретно.
> Пример: нужно вывести несколько переменных и фрагмент базы на экран
> (скажем, список товаров каких-нибудь). Задание параметров выборки не
> интересует, только вывод. Хочу увидеть текст шаблона (и сопутствующих

Почему-то не спрашиваешь про структуру XML-документа, DTD я писать не буду,
а выглядит он, пусть, как:
<?xml version="1.0"?>
<page>
  <title>My suppa-duppa page</title>
  <dataArray>
    <dataElement>
      <title>Agfa SnapScan 1236u</title>
      <price>799.99</price>
    </dataElement>
    <dataElement>
      <title>Lexmark Z52</title>
      <price>1499.99</price>
    </dataElement>
  </dataArray>
</page>

Твой шаблон:
<?xml version="1.0"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
      <title><xsl:value-of select="/page/title" /></title>
      <body>
        <table>
          <xsl:apply-templates select="page/dataArray/dataElement" />
        </table>
      </body>
  </xsl:template>

  <xsl:template match="dataElement">
    <tr>
      <td><xsl:value-of select="title" /></td>
      <td><xsl:value-of select="price" /></td>
    </tr>
  </xsl:template>
</xsl:stylesheet>

> файлов, if any), плюс указания на то, как это нужно парсить (ссылки
> на нужные функции и/или extensions).
В моем классе используется xslt_process:

        if (@xslt_process($this->xslText, $this->input, $result))
          $this->output = $result;

- это к вышеприведенным кускам никак не привязано, ессно. Кроме того, можешь
парсить любым другим парсером, какой найдешь.
Написал тебе этот пример и аж скучно стало самому - на демонстрацию
возможностей оно никак не тянет... Так - тривиальщина.
Обрати внимание - в результате будет html (не XHTML), потому как тег <html>
тебе писать было, видимо, влом. Вот и я не написал.

>  >> 2) в результате в браузере что имеем, HTML или XHTML?
>  YM> Чего хочешь, то и генерируй, хоть голый текст...
>  YM> А что за разница для браузера между HTML и XHTML?
> Я не уверен, что тот же Netscape сжует <br/>, а совместимость
> с ним может потребоваться.
Нет, не сжует. А <br /> сжует.


--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

>  >> 2) в результате в браузере что имеем, HTML или XHTML?
>  VB> а чем хуже XHTML, чем "неправильный"(т.е. не XHTML) HTML ?
> Netscape его жрет нормально? Opera? WebTV?
За webTv не отвечу, а остальные проверены =)))
Кроме того, как уже здесь говорилось, генери хоть WML, хоть rtf, хоть что
хочешь. Хоть ничего не генери =)). На что фантазии достанет. У меня в одном
проекте текст мейлов клиентам получается в результате преобразования.

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

                          Привет, Sergio !!!

 Как-то раз (а точнее 07 Jun 01 в 17:09) Sergio Starush писал(а) к Vitaliy N.
Kravchenko:
 VNK>> В хтмле у тебя обьединен _И_ дизайн _И_ инфоpмация (плюс еще
 VNK>> некотоpые к этому фаpшу еще и ПХП скpиптинг добавляют..). С
 VNK>> XML-ем этого нет. А когда и на что пеpеходить, это pешает каждый
 VNK>> для себя..

 SS> А pазве пpи использовании php/mySQL невозможно целиком отделить дизайн
 SS> от инфоpмации? По-моему, вполне возможно, и без особых усилий. В чем
 SS> же тогда получается выгода xml? Чуть более подpобно, пожалуйста.
Hи то, ни другое напрямую с дизайном никак не связано.
mysql - хранилище данных, XML - промежуточный формат перед передачей куда либо.
Учитывая тот факт, что XSLT (даже в не лучшей его реализации Sablotron/PHP) в
качестве парсера шаблонов гораздо мощнее большинства аналогов, да еще и
стандарт де-факто - приходится юзать все тот же XML.

Если найдешь более мощный/удобный аналог, не требующий XML в качестве входного
формата (а это вполне реально), да еще и верстальщик не против будет его
синтаксис изучить (а куда он денется ;) - флаг в руки.

--
mailto: random at info.net.ua                  //Александр

 

Hello Yuri!

08 Jun 01 01:48, Yuri Makassiouk wrote to All:
 YM> Твой шаблон:
[skip]
 YM>   <xsl:template match="dataElement">
 YM>     <tr>
 YM>       <td><xsl:value-of select="title" /></td>
 YM>       <td><xsl:value-of select="price" /></td>
 YM>     </tr>
 YM>   </xsl:template>
Спасибо за пример. Есть уточняющий вопрос (я у себя пока не
заставил PHP нормально работать с Sablotron'ом, так что взять
и просто попробовать пока не могу): должен ли XSLT-шаблон
являться в свою очередь well-formed XML?

То есть например вот такое:

<xsl:template match="dataElement">
    <p class=title><xsl:value-of select="title" /><br>
    <p class=price><xsl:value-of select="price" /><br>
</xsl:template>

покатит, или надо будет написать таки <p class="title" /> и <br />?

 YM> Hаписал тебе этот пример и аж скучно стало самому - на демонстрацию
 YM> возможностей оно никак не тянет... Так - тривиальщина.
Так поделись небольшой демонстрацией возможностей. ;)

 >> Я не уверен, что тот же Netscape сжует <br/>, а совместимость
 >> с ним может потребоваться.
 YM> Hет, не сжует. А <br /> сжует.
Это радует. ;) Что же, теперь надо попробовать скормить эту идею
нашим дизайнерам и посмотреть на реакцию... ;)

- Andrew

... Sampled and soulless, worldwide and real world webbed...
 

Здравствуйте Уважаемые.

"Andrew Aksyonoff" <Andrew.Aksyonoff@p2.f29.n5036.z2.fidonet.org> wrote in
message news:991960052@p2.f29.n5036.z2.ftn...
> Hello Yuri!
>
> 07 Jun 01 01:56, Yuri Makassiouk wrote to All:
>  >> 1) простенький пример (хотя бы из моего предыдущего письма) - можно?
>  YM> Hапиши - чего пример хочешь, конкретно.
> Пример: нужно вывести несколько переменных и фрагмент базы на экран
> (скажем, список товаров каких-нибудь). Задание параметров выборки не
> интересует, только вывод. Хочу увидеть текст шаблона (и сопутствующих
> файлов, if any), плюс указания на то, как это нужно парсить (ссылки
> на нужные функции и/или extensions).
>
> То есть хочу увидеть аналог
>
> <title>{TITLE}</title>
> <body><table>
> <tmpl_loop DATAARRAY>
> <tr><td>{DATAARRAY.title}</td><td>{DATAARRAY.price}</td></tr>
> </tmpl_loop>
> </table></body>

самый понятный пример (для вас - ПХПешников :) -
-------------------------------------
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
  <xsl:template match="/">
    <HTML>
      <HEAD>
        <TITLE><xsl:value-of select="title"/></TITLE>
      </HEAD>
      <BODY>
        <TABLE>
          <TR>
            <TD>Title</TD>
            <TD>Price</TD>
          </TR>
          <xsl:for-each select="data/item" order-by="title">
            <TR>
              <TD>с</TD>
              <TD><xsl:value-of select="price"/></TD>
            </TR>
          </xsl:for-each>
        </TABLE>
      </BODY>
    </HTML>
  </xsl:template>
</xsl:stylesheet>
-------------------------------------
а вот пример, который ближе душе XMLщика ;) -
<?xml version='1.0'?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output encoding="windows-1251"/>
<xsl:output indent="yes"/>
  <xsl:template match="/">
    <HTML>
      <xsl:call-template name="doHead">
        <xsl:with-param name="title" select="/title"/>
      </xsl:call-template>
      <xsl:call-template name="doBody"/>
    </HTML>
  </xsl:template>

  <xsl:template name="doHead">
    <xsl:param name="title"/>
    <HEAD>
      <TITLE><xsl:value-of select="$title"/></TITLE>
    </HEAD>
  </xsl:template>

  <xsl:template name="doBody">
    <BODY>
      <xsl:apply-templates select="//data"/>
    </BODY>
  </xsl:template>

  <xsl:template match="data">
    <TABLE>
      <TR>
        <TD>Title</TD>
        <TD>Price</TD>
      </TR>
      <xsl:apply-templates select="//item"/>
    </TABLE>
  </xsl:template>

  <xsl:template match="item">
      <TR>
        <TD><xsl:value-of select="title"/></TD>
        <TD><xsl:value-of select="price"/></TD>
      </TR>
  </xsl:template>

</xsl:stylesheet>
-------------------------------
а вот и исходный XML-файл -
<?xml version='1.0'?>
<pricelist>
  <title>Price List</title>
  <data>
    <item>
      <title>Prod B</title>
      <price>$200</price>
    </item>
    <item>
      <title>Prod A</title>
      <price>$100</price>
    </item>
  </data>
</pricelist>
-------------------------------
а вот XHML-результат
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=windows-1251">
<TITLE></TITLE>
</HEAD>
<BODY>
<TABLE>
<TR>
<TD>Title</TD>
<TD>Price</TD>
</TR>
<TR>
<TD>Prod A</TD>
<TD>$100</TD>
</TR>
<TR>
<TD>Prod B</TD>
<TD>$200</TD>
</TR>
</TABLE>
</BODY>
</HTML>

-------------------------------
>  >> 2) в результате в браузере что имеем, HTML или XHTML?
>  YM> Чего хочешь, то и генерируй, хоть голый текст...
>  YM> А что за разница для браузера между HTML и XHTML?
> Я не уверен, что тот же Netscape сжует <br/>, а совместимость
> с ним может потребоваться.

сжуёт, и не только он ;)

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Andrew Aksyonoff" <Andrew.Aksyonoff@p2.f29.n5036.z2.fidonet.org> wrote in
message news:991978613@p2.f29.n5036.z2.ftn...
> Hello Yuri!
>
> 08 Jun 01 01:48, Yuri Makassiouk wrote to All:
>  YM> Твой шаблон:
> [skip]
>  YM>   <xsl:template match="dataElement">
>  YM>     <tr>
>  YM>       <td><xsl:value-of select="title" /></td>
>  YM>       <td><xsl:value-of select="price" /></td>
>  YM>     </tr>
>  YM>   </xsl:template>
> Спасибо за пример. Есть уточняющий вопрос (я у себя пока не
> заставил PHP нормально работать с Sablotron'ом, так что взять
> и просто попробовать пока не могу): должен ли XSLT-шаблон
> являться в свою очередь well-formed XML?

да, т.к. XSL - есть XML-документ, то он должен быть и отвечать требованиям
XML.

> То есть например вот такое:
>
> <xsl:template match="dataElement">
>     <p class=title><xsl:value-of select="title" /><br>
>     <p class=price><xsl:value-of select="price" /><br>
> </xsl:template>
>
> покатит, или надо будет написать таки <p class="title" /> и <br />?

обязательно, при этом "охватывающие" теги лучше и оформлять соответственно,
т.е.
<p class=price>
  <xsl:value-of select="price" />
</p>
<br/>

>  YM> Hаписал тебе этот пример и аж скучно стало самому - на демонстрацию
>  YM> возможностей оно никак не тянет... Так - тривиальщина.
> Так поделись небольшой демонстрацией возможностей. ;)

проще ссылки дать ;)
http://www.w3.org/TR/xsl/
http://www.bim.f2s.com
http://msdn.microsoft.com/xml

>  >> Я не уверен, что тот же Netscape сжует <br/>, а совместимость
>  >> с ним может потребоваться.
>  YM> Hет, не сжует. А <br /> сжует.
> Это радует. ;) Что же, теперь надо попробовать скормить эту идею
> нашим дизайнерам и посмотреть на реакцию... ;)

Сначала они точно будут брыкаться - проверено ;)

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

> > покатит, или надо будет написать таки <p class="title" /> и <br />?
<p class="title" /> даст пустой параграф. Надо <p class="title">my title</p>

> > Это радует. ;) Что же, теперь надо попробовать скормить эту идею
> > нашим дизайнерам и посмотреть на реакцию... ;)
>
> Сначала они точно будут брыкаться - проверено ;)
Тогда их можно уволить и набрать новых, которые уже знают и готовы =))
Я говорю, конечно, не о дизайнерах, а о верстальщиках

--
Yuri Makassiouk
<><
racer@bfpg.ru
http://www.missionandmedia.com/


 

Здравствуйте Уважаемые.

"Yuri Makassiouk" <racer@bfpg.ru> wrote in message
news:9fqstl$lg4$1@ddt.demos.su...
> > > покатит, или надо будет написать таки <p class="title" /> и <br />?
> <p class="title" /> даст пустой параграф. Надо <p class="title">my title</p>
>
> > > Это радует. ;) Что же, теперь надо попробовать скормить эту идею
> > > нашим дизайнерам и посмотреть на реакцию... ;)
> >
> > Сначала они точно будут брыкаться - проверено ;)
> Тогда их можно уволить и набрать новых, которые уже знают и готовы =))
> Я говорю, конечно, не о дизайнерах, а о верстальщиках

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

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

    Приветствую Вас Ed!

Было это не иначе как Втоpник Июнь 05 2001
Ed Bartosh -> "Vladlen Bulatov":

Хочется сделать пару уточнений.
VB>> а чем тогда "это" лучше, чем следующее ?
Да ничем не лучше, но и не хуже...
просто...
когда ты делаешь Template в HomeSite (в моему случае)...
то Preview для дизайнера, будет выдавать то, что нада...

2Vladlen. Hаиболее удобна другая схема ;)
<?
 //любой код на php который формирует к.л. переменные
...
 if ($cmd == 'чтонить1') {
  include('./templates/чтонить1.phtml');
 }
...
?>

EB> Тем, что <?=title?> (jsp, ya ?)
неа... PHP4 ;>>>
EB> подразумевает некий код здесь же, который эту переменную
неа... PHP4 ;>>>
определяет и
EB> присваивает ей некое значение.
Hеобязательно... Савсем.

Однако выше я уже объяснил... что исходя из чисто меркантильных соображений...
когда верстальщик _не пользует_ Апач\PHP... но делает Темплейты... в
notepad\homesite\Far etc. на основании...
заранее проработанных в ТЗ _ТИПОВ_СТРАHИЦ_
(страница заказа, страница корзины, каталог, подписка, поиск etc.)
использование {TITLE} ему гораздо удобнее ;) IMHO...

EB> То есть налицо смешивание логики и представления.
EB> А в случае с {TITLE} этого не происходит. Это переменная темплейта,
EB> и как она вычисляется и где тому, кто работает с темплейтом до
EB> лампады, точно также до лампады программеру что с этим {TITLE} в
EB> темплейте сделает дизайнер.
Истинну говоришь.

VB>> пока я большИх возможностей не вижу
;))) А ты попробуй, договориться с дизайнером, о том, чтобы он все тестил на
удаленном серваке (даже если пользовать HS URL Mapping)...
и при этом ... обзывал к.л. образом переменные так как тебе нада...
;) я с таким столкнулся... не очень то удобно...
Либо ты делаешь "примитивную верстку сам"...
(случай <?=$var;?>) а потом уже дизайнер, дорабатывает это...

Либо дизайнер, делает Templates отдельно...
(с практической возможностью полноценного PreView)
и ты параллельно делаешь логику... а уже потом подключаешь templates...
причем внутренние твои переменные, не обязательно должны совпадать с именами
{template} макросов

EB> Принципиально данная технология позволяет отделить логику приложения
EB> от представления, что на самом деле очень большой шаг по сравнению
EB> с embedded технологией, где логика идет вперемешку с дизайном. Причем
EB> это не зависит от языка - PHP/ASP/JSP при применении их в embedded
EB> варианте ведут к такому смешиванию.
Угу =)) и CodeCharge тому прямой пример.

VB>> см. пример выше
EB> В твоем примере не видно, где переменная получает значение.
EB> Я также на php могу написать: <? echo $title?>, но это не значит,
;)) с учетом того, что человек привел пример на PHP ;) это ты Эдуард
промахнулся малость.

EB> что выше я не наверну кусок кода, который скажем берет нечто из базы
EB> данных, а потом на основании этого нечто присваивает $title значение.
EB> Полагаю, что и в jsp так же. Или я не прав ?
Прав, но не савсем.

>>> Hасчет общего интерфейса к DB - такая попытка сейчас делается,
>>> PEAR называется. там кроме этого предлагается еще и общий подход к
VB>> http://www.php.net/manual/en/pear.php, это оно ?
EB> Hу, это только пару строк о нем, его надо смотреть в сорцах,
необязательно
http://pear.php.net

<SKiP про middle-ware>

                    Всего хорошего .....
                                        Slach.
 

Hello Vladlen!

08 Jun 01 14:20, Vladlen Bulatov wrote to All:
 >> Это радует. ;) Что же, теперь надо попробовать скормить эту идею
 >> нашим дизайнерам и посмотреть на реакцию... ;)
 VB> Сначала они точно будут брыкаться - проверено ;)
А потом? И как они у вас делают XSL'ки, руками, редактором
каким-то или чем-то еще?

- Andrew

... What do you get if you multiply six by nine?
 

Hello Vladlen!

08 Jun 01 13:31, Vladlen Bulatov wrote to All:
 VB> самый понятный пример (для вас - ПХПешников :) -
Спасибо. Только мы не PHP'шники, мы на всем, что исполняется... ;)))

- Andrew

... It's time to start playing your part...
 

Здравствуйте Уважаемые.

"Andrew Aksyonoff" <Andrew.Aksyonoff@p2.f29.n5036.z2.fidonet.org> wrote in
message news:992033557@p2.f29.n5036.z2.ftn...
> Hello Vladlen!
>
> 08 Jun 01 14:20, Vladlen Bulatov wrote to All:
>  >> Это радует. ;) Что же, теперь надо попробовать скормить эту идею
>  >> нашим дизайнерам и посмотреть на реакцию... ;)
>  VB> Сначала они точно будут брыкаться - проверено ;)
> А потом? И как они у вас делают XSL'ки, руками, редактором
> каким-то или чем-то еще?

сейчас наибольшим успехом пользуется XSL Tester от www.vbxml.com,
но некоторые используют и IBM XML Editor
(http://www.alphaworks.ibm.com/tech/xsleditor).
у каждого из них есть и плюсы и минусы, XSL Tester умеет показывать превью,
но не умеет отлаживать, а IBM XML Editor - наоборот.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Vladlen Bulatov" <vlad@econ.msu.ru> wrote in message
news:9fqcbh$v7f$1@ddt.demos.su...
> > Спасибо за пример. Есть уточняющий вопрос (я у себя пока не
> > заставил PHP нормально работать с Sablotron'ом, так что взять
> > и просто попробовать пока не могу): должен ли XSLT-шаблон
> > являться в свою очередь well-formed XML?
> да, т.к. XSL - есть XML-документ, то он должен быть и отвечать требованиям
> XML.

Хех ;)
MSXML при указании <xsl:output method="html"/> требует well-formed XSLT, но
...
При этом в пустых тегах типа <IMG src="tra-ta-ta"/> удаляет "признак"
пустого тега (читай - слеш), т.е. на выходе получаем - <IMG
src="tra-ta-ta">.
Надо проверить и на других парсерах...

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

    Приветствую Вас Alexei!

Было это не иначе как Четвеpг Июнь 07 2001
Alexei Ivanov -> All:

>> А pазве пpи использовании php/mySQL невозможно целиком отделить
>> дизайн от инфоpмации?
AI> Сэр, Вы ничего не смыслите в новых технологиях!
;) Вы тоже, и я тоже, мы вообще практически используем то, что на западе
считается пережитком и устаревшим ширпатребом ;))))

AI> Эти технологии выгодны не потому, что хороши, а потому что HО-ВЫЕ!
AI> -ВЫЯ -ВЫЁ. И применять их ВЕЗДЕ наша задача. Так что уйдите и не
AI> мешайте прогрессу.
AI> P.S. Я сказал в согласии с центральной линией партии?
AI>      Может меня даже наградят... посмертно... :~~-)
Алексей, не надо ерничать.
Да, я около года успешно использую PHP+MySQL+Шаблоны(Smarty и\или
чуток переписанный FastTemplate)...
ДА, мне этого до последнего времени (и даже сейчас в 90% случаев) хватало.

HО, появляются новые заказчики, которым нужен не толко MySQL но и
Interbase, MSSQL, Oracle и причем сразу вместе... да еще с какой нить
1C:Бухгалтерией проинтегрировано...
HО, заказчикам нужно несколько вариантов дизайна (как тут упоминалось, фреймы и
без фреймов)...
HО, заказчикам нада WAP\WML (и только так, ибо мобильной связью у нас уже
обладают и пенсионеры и студенты, не все, но ведь УЖЕ :)
HО, и этот список можно продолжить ...

Поэтому теперь я намереваюсь пользовать все тот же PHP
но уже +SQLrelay+XSLT+XPath и вообще, был бы рад перейти на XML ориентированную
e-DMBS (Tamino или Cache) коли бы приделали к ней интерфейс на PHP...

                    Всего хорошего .....
                                        Slach.
 

Hi, Eugeny!

/Fri, 08 Jun 2001 00:17:47 +0400/ Eugeny Klimov wrote to ed@vitebsk.net:

 EB>> Тем, что <?=title?> (jsp, ya ?)
EK> неа... PHP4 ;>>>
Шутишь ?
 EB>> подразумевает некий код здесь же, который эту переменную
EK> неа... PHP4 ;>>>
EK> определяет и
 EB>> присваивает ей некое значение.
EK> Hеобязательно... Савсем.
Да какая разница в этом оно файле или включено сюда через
"include" (ты это имеешь ввиду ?). Все равно неудобно работать. И поскольку
"include" не есть HTML, то опять смешивание имеет место быть, о чем и базар
был.

EK> Однако выше я уже объяснил... что исходя из чисто меркантильных соображений...
EK> когда верстальщик _не пользует_ Апач\PHP... но делает Темплейты... в
EK> notepad\homesite\Far etc. на основании...
EK> заранее проработанных в ТЗ _ТИПОВ_СТРАHИЦ_
EK> (страница заказа, страница корзины, каталог, подписка, поиск etc.)
EK> использование {TITLE} ему гораздо удобнее ;) IMHO...
О ! Вот я сейчас вплотную занялся XML/XSLT/Java, но несмотря на
повсеместные увещевания о разделении 3-х составляющих Web-приложения
я этого разделения не вижу. Пока, может быть.
А вообще круто, конечно. Hо дизайнеру неудобнее :(

 VB>>> пока я большИх возможностей не вижу
EK> ;))) А ты попробуй, договориться с дизайнером, о том, чтобы он все тестил на
EK> удаленном серваке (даже если пользовать HS URL Mapping)...
EK> и при этом ... обзывал к.л. образом переменные так как тебе нада...
EK> ;) я с таким столкнулся... не очень то удобно...
EK> Либо ты делаешь "примитивную верстку сам"...
EK> (случай <?=$var;?>) а потом уже дизайнер, дорабатывает это...
Поддерживаю, Правильные твои слова :) !

 EB>> Принципиально данная технология позволяет отделить логику приложения
 EB>> от представления, что на самом деле очень большой шаг по сравнению
 EB>> с embedded технологией, где логика идет вперемешку с дизайном. Причем
 EB>> это не зависит от языка - PHP/ASP/JSP при применении их в embedded
 EB>> варианте ведут к такому смешиванию.
EK> Угу =)) и CodeCharge тому прямой пример.
А кто это ? Можешь хоть в 2-х словах. Или дай урл, где почитать.

 VB>>> см. пример выше
 EB>> В твоем примере не видно, где переменная получает значение.
 EB>> Я также на php могу написать: <? echo $title?>, но это не значит,
EK> ;)) с учетом того, что человек привел пример на PHP ;) это ты Эдуард
EK> промахнулся малость.
См. выше. Роли не играет. Да и в JSP можно таглибы юзая все это убрать,
ну и что ? Все равно такого удобства и разделения работы между
программистом и дизайнером, которые дает использование темплейтов я пока
не наблюдаю :(
А как их заставить XSL юзать я вообще не знаю, там же блин масса логики
налицо !

 EB>> что выше я не наверну кусок кода, который скажем берет нечто из базы
 EB>> данных, а потом на основании этого нечто присваивает $title значение.
 EB>> Полагаю, что и в jsp так же. Или я не прав ?
EK> Прав, но не савсем.
Согласен. Hе совсем. Hо прав :)

 >>>> Hасчет общего интерфейса к DB - такая попытка сейчас делается,
 >>>> PEAR называется. там кроме этого предлагается еще и общий подход к
 VB>>> http://www.php.net/manual/en/pear.php, это оно ?
 EB>> Hу, это только пару строк о нем, его надо смотреть в сорцах,
EK> необязательно
EK> http://pear.php.net
Да там почти тоже самое. Тормозят конкретно. Уже в других местах
полно туториалов по PEAR, а на сайте у них както пустовато.

-- 
Best regards, Ed

Отправлено через сервер Talk.Ru - http://www.talk.ru
 

    Приветствую Вас Ed!

Было это не иначе как Втоpник Июнь 12 2001
Ed Bartosh -> Eugeny Klimov:
EB>>> Тем, что <?=title?> (jsp, ya ?)
EK>> неа... PHP4 ;>>>
EB> Шутишь ?
вот тебе крест на пузе... ;)
я сейчас так сам делаю ;) <?=$out;?>

на самом деле, все упирается вот во что...
когда ты делаешь <?=$out;?> ты просто вызываешь встроенную функцию написанную
на Си...

а когда ты делаешь $template->Parse($filename);
вызывается метод класса, который обычно в цикле работает... и делает всяческие
str_replace etc.

что тут быстрее ?? ;) честно говоря... пока не знаю... нада будет с
FastTemplate поиграться ;))

EK>> Однако выше я уже объяснил...
EK>> что исходя из чисто меркантильных соображений... когда верстальщик
EK>> _не пользует_ Апач\PHP... но делает Темплейты...
EK>> использование {TITLE} ему гораздо удобнее ;) IMHO...
EB> О ! Вот я сейчас вплотную занялся XML/XSLT/Java, но несмотря на
EB> повсеместные увещевания о разделении 3-х составляющих Web-приложения
EB> я этого разделения не вижу. Пока, может быть.
EB> А вообще круто, конечно. Hо дизайнеру неудобнее :(
;) а дизайнер тут и непричем... это Верстальщик должен заниматься...
есть хорошие дизайнеры... и плохие верстальщики...  и наоборот...

на самом деле... применение XML как средства хранения Template's является может
быть самым очевидным, но далеко не однозначно ЛУЧШИМ (хотя и мощным, гибким)
решением...

как мне кажется, наибольший эффект, XML будет иметь если использовать для
ВЕБА ... XML ориентированные базы данных, в которых пользуется не SQL а XQL ;)
или XPath

К такому выводу, можно прийти, если представить сайт, ЛЮБОЙ сайт, в виде дерева
(чем он собтсвенно и является... поскольку, изначально, его структура,
основана на структуре файлов и каталогов, которые ничем иным кроме дерева не
являются)

EB>>> Принципиально данная технология позволяет отделить логику
EB>>> приложения от представления, что на самом деле очень большой шаг
EB>>> по сравнению с embedded технологией
EK>> Угу =)) и CodeCharge тому прямой пример.
EB> А кто это ? Можешь хоть в 2-х словах. Или дай урл, где почитать.
www.codecharge.com
в двух словах - Визуальное средство разработки WEB интерфейсов к базам
данных... я когда его поставил, думал что все =)) Теперь даже программировать
не придется ;))
эта штучка позволяет генерить Server Side Скрипты.. на PHP\JSP\ColdFusion\Perl
активно использует Темплейты...
(и вот она кстати, очень мощно внутри себя пользует всяческий XML)

EK>> ;)) с учетом того, что человек привел пример на PHP ;) это ты
EK>> Эдуард промахнулся малость.
EB> См. выше. Роли не играет. Да и в JSP можно таглибы юзая все это
EB> убрать, ну и что ? Все равно такого удобства и разделения работы между
EB> программистом и дизайнером, которые дает использование темплейтов я
EB> пока не наблюдаю :( А как их заставить XSL юзать я вообще не знаю, там
EB> же блин масса логики налицо !
;)
Hа самом деле, там не так уж много логики...
в XSL ты декларируешь, как ты будешь отображать тот или иной XML тег...
вот и все...

XML+XSLT удобнее тем, что бывают случаи, когда ты просто не знаешь...
какие данные будешь выводить в template...

скажем постраничная навигация вперед\назад...
она может быть а может и нет...

в XSL ты можешь точно определить, есть она или нет... и соответсвенно если нет,
то ничего не выводить вообще...
а в template's тебе придется либо вводить логику (и уж тогда точно будут
тормоза)... либо организовывать верстку таким образом, что появятся какие
нибудь пустые <td> (80% сайтов на табличной верстке сделаны)...
что не есть хорошо, ибо лишний HTML код в браузер..

но все эти рассуждения, с моей стороны, пока что голая теория, подкрепленная
некоторым опытом "ковыряния"...

                    Всего хорошего .....
                                        Slach.
 

Здравствуйте Уважаемые.

"Eugeny Klimov" <Eugeny.Klimov@p8.f201.n5010.z2.fidonet.org> wrote in
message news:992476558@p8.f201.n5010.z2.ftn...
> EB>>> Тем, что <?=title?> (jsp, ya ?)
> EK>> неа... PHP4 ;>>>
> EB> Шутишь ?
> вот тебе крест на пузе... ;)
> я сейчас так сам делаю ;) <?=$out;?>

в настройках ПХП для этого надо включить asp_tags, но вроде 4-ка уже и без
этого такое понимает.

> на самом деле, все упирается вот во что...
> когда ты делаешь <?=$out;?> ты просто вызываешь встроенную функцию написанную
> на Си...

а при чем здесь Си ?

> а когда ты делаешь $template->Parse($filename);
> вызывается метод класса, который обычно в цикле работает... и делает всяческие
> str_replace etc.

именно.

> что тут быстрее ?? ;) честно говоря... пока не знаю... нада будет с
> FastTemplate поиграться ;))

я уже "потыкался" как-то по разным темплейт-енжинам, и в результате пришёл к
XSLT.

> EK>> Однако выше я уже объяснил...
> EK>> что исходя из чисто меркантильных соображений... когда верстальщик
> EK>> _не пользует_ Апач\PHP... но делает Темплейты...
> EK>> использование {TITLE} ему гораздо удобнее ;) IMHO...

именно - твоё IMHO, но обычно нормальный верстальщик желает потратить
минимум времени на вёрстку, при этом не уделяя внимания дизайну.

> EB> О ! Вот я сейчас вплотную занялся XML/XSLT/Java, но несмотря на
> EB> повсеместные увещевания о разделении 3-х составляющих Web-приложения
> EB> я этого разделения не вижу. Пока, может быть.
> EB> А вообще круто, конечно. Hо дизайнеру неудобнее :(
> ;) а дизайнер тут и непричем... это Верстальщик должен заниматься...
> есть хорошие дизайнеры... и плохие верстальщики...  и наоборот...

Хм, я всегда думал, что верстальщик создаёт XML, а дизайнер - XSLT/CSS.
т.ч. здесь как раз выходит корректное разделение труда.
... ну а программист тут на подхвате у обоих.

> на самом деле... применение XML как средства хранения Template's является может
> быть самым очевидным, но далеко не однозначно ЛУЧШИМ (хотя и мощным, гибким)
> решением...

имелся в виду XML или всё же - XSLT ?

> как мне кажется, наибольший эффект, XML будет иметь если использовать для
ВЕБА ...

бррр, я наверное что то упустил ;)
конференция вроде о ПХП, это с НЕ-Вебом вроде почти и не связано ;)

> XML ориентированные базы данных, в которых пользуется не SQL а XQL ;) или
XPath

XQuery, к сожалению, пока только на стадии выработки требований ;(
XQL же - один из претендентов на реализацию XQuery
XPath - конечно подходит для выборки элементов и их наборов, но сравнивать
его с SQL - совсем неправильно, у них назначение разное.

> К такому выводу, можно прийти, если представить сайт, ЛЮБОЙ сайт, в виде дерева
> (чем он собтсвенно и является... поскольку, изначально, его структура,
> основана на структуре файлов и каталогов, которые ничем иным кроме дерева не
> являются)

и запихнуть весь сайт в один XML файл ? увольте ;)
ну а если класть всё в базу, а затем по запросам формировать XML, а затем
обрабатывать XSLT - вполне ничего решение. Скажем даже так - на данный
момент наиболее часто используемое.

> EB>>> Принципиально данная технология позволяет отделить логику
> EB>>> приложения от представления, что на самом деле очень большой шаг
> EB>>> по сравнению с embedded технологией
> EK>> Угу =)) и CodeCharge тому прямой пример.
> EB> А кто это ? Можешь хоть в 2-х словах. Или дай урл, где почитать.
> www.codecharge.com
> в двух словах - Визуальное средство разработки WEB интерфейсов к базам
> данных... я когда его поставил, думал что все =)) Теперь даже программировать
> не придется ;))
> эта штучка позволяет генерить Server Side Скрипты.. на PHP\JSP\ColdFusion\Perl
> активно использует Темплейты...
> (и вот она кстати, очень мощно внутри себя пользует всяческий XML)

А чем оно существенно отличается от FrontPage/InterDev ?

> EK>> ;)) с учетом того, что человек привел пример на PHP ;) это ты
> EK>> Эдуард промахнулся малость.
> EB> См. выше. Роли не играет. Да и в JSP можно таглибы юзая все это
> EB> убрать, ну и что ? Все равно такого удобства и разделения работы между
> EB> программистом и дизайнером, которые дает использование темплейтов я
> EB> пока не наблюдаю :( А как их заставить XSL юзать я вообще не знаю, там
> EB> же блин масса логики налицо !
> ;) 
:) именно ;)
кнутом и пряником ;)

> Hа самом деле, там не так уж много логики...
> в XSL ты декларируешь, как ты будешь отображать тот или иной XML тег...
> вот и все...

что, кстати, значительно сокращает общий текст темплейтов. Т.е. рост кол-ва
страниц - практически не отражается на росте объёма темплейтов (за
исключением, когда или вводятся новые сущьности-теги или когда для некоего
набора страниц нужно немного поменять дизайн)

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Hi, Eugeny!

/Wed, 13 Jun 2001 22:32:08 +0400/ Eugeny Klimov wrote to ed@vitebsk.net:

 EB>>>> Тем, что <?=title?> (jsp, ya ?)
 EK>>> неа... PHP4 ;>>>
 EB>> Шутишь ?
EK> вот тебе крест на пузе... ;)
EK> я сейчас так сам делаю ;) <?=$out;?>
Ха ! Ты разницу почувствуй между <?=title?> и <?=$out;?>
Пусть автор сам скажет, что это было.
Впрочем это не принципиально, хотя по-моему jsp.

EK> на самом деле, все упирается вот во что...
EK> когда ты делаешь <?=$out;?> ты просто вызываешь встроенную функцию написанную
EK> на Си...

EK> а когда ты делаешь $template->Parse($filename);
EK> вызывается метод класса, который обычно в цикле работает... и делает всяческие
EK> str_replace etc.

EK> что тут быстрее ?? ;) честно говоря... пока не знаю... нада будет с
EK> FastTemplate поиграться ;))
Лучше уже тогда с CachedFastTemplate :)

И вообще пусть проц работает, он на то и нужен, а логика должна быть
отдельно от дизайна, а не торчать посреди HTMLя всякими <?=title?>
А если я захочу разгрузить проц, я попользую скажем кэш какой или
просто другую технологию ( я глянул тут Cocoon - знатная вещь, там
за каждым чихом ничего не парсится, а реюзается откомпилированный
код, а компиляция происходит только один раз - при первом обращении ).

 EK>>> Однако выше я уже объяснил...
 EK>>> что исходя из чисто меркантильных соображений... когда верстальщик
 EK>>> _не пользует_ Апач\PHP... но делает Темплейты...
 EK>>> использование {TITLE} ему гораздо удобнее ;) IMHO...
 EB>> О ! Вот я сейчас вплотную занялся XML/XSLT/Java, но несмотря на
 EB>> повсеместные увещевания о разделении 3-х составляющих Web-приложения
 EB>> я этого разделения не вижу. Пока, может быть.
 EB>> А вообще круто, конечно. Hо дизайнеру неудобнее :(
EK> ;) а дизайнер тут и непричем... это Верстальщик должен заниматься...
EK> есть хорошие дизайнеры... и плохие верстальщики...  и наоборот...
Верстальщик - это пережиток, атавизм, он на хрен не нужен по хорошему.
Дизайнер создает представление, программист логику, автор - контент,
а что должен делать верстальщик ? Он просто умеет представить в
HTML-е результат работы дизайнера и вставить туда код программиста.
Так вот при нормальной схеме вроде как дизайн целиком делается дизайнером,
логика программером ... Только никак не могу я ее понять, эту схему.
Где берут дизайнеров, знающих XSLT :) ?

EK> на самом деле... применение XML как средства хранения Template's является может
EK> быть самым очевидным, но далеко не однозначно ЛУЧШИМ (хотя и мощным, гибким)
EK> решением...
Для меня это не очень очевидно. Это какая-то уж больно многоуровневая схема
получается. Масло масляное.

EK> как мне кажется, наибольший эффект, XML будет иметь если использовать для
EK> ВЕБА ... XML ориентированные базы данных, в которых пользуется не SQL а XQL ;)
EK> или XPath
Hеа, уже сейчас есть масса решений, где промежуточный слой между субд и
приложением есть XML, да хотя бы тот же оракл предлагает, да и не только он.

EK> К такому выводу, можно прийти, если представить сайт, ЛЮБОЙ сайт, в виде дерева
EK> (чем он собтсвенно и является... поскольку, изначально, его структура,
EK> основана на структуре файлов и каталогов, которые ничем иным кроме дерева не
EK> являются)
Такое представление по сути ничего не дает. В виде дерева нужно
представлять контент сайта, а не способ хранения этого контента в виде
файлов и каталогов.

 EB>>>> Принципиально данная технология позволяет отделить логику
 EB>>>> приложения от представления, что на самом деле очень большой шаг
 EB>>>> по сравнению с embedded технологией
 EK>>> Угу =)) и CodeCharge тому прямой пример.
 EB>> А кто это ? Можешь хоть в 2-х словах. Или дай урл, где почитать.
EK> www.codecharge.com
EK> в двух словах - Визуальное средство разработки WEB интерфейсов к базам
EK> данных... я когда его поставил, думал что все =)) Теперь даже программировать
EK> не придется ;))
EK> эта штучка позволяет генерить Server Side Скрипты.. на PHP\JSP\ColdFusion\Perl
EK> активно использует Темплейты...
EK> (и вот она кстати, очень мощно внутри себя пользует всяческий XML)
Спасибо. Очень интересно, обязательно буду смотреть.

 EK>>> ;)) с учетом того, что человек привел пример на PHP ;) это ты
 EK>>> Эдуард промахнулся малость.
 EB>> См. выше. Роли не играет. Да и в JSP можно таглибы юзая все это
 EB>> убрать, ну и что ? Все равно такого удобства и разделения работы между
 EB>> программистом и дизайнером, которые дает использование темплейтов я
 EB>> пока не наблюдаю :( А как их заставить XSL юзать я вообще не знаю, там
 EB>> же блин масса логики налицо !
EK> ;)
EK> Hа самом деле, там не так уж много логики...
:) Hю-ню. По моему там есть и if и for и case, весь тебе штатный
набор. То есть если юзать его по полной программе, то это не для
дизайнера. Или я чего не понимаю ?
Ты это, w3c recomendation для XSLT читал ли ?
Вот навскидку тебе названия некоторых пунктов:
8.  Repetition
9.  Conditional processing
10. Sorting
11. Variables and parameters
12. Additional functions
ну и дальше в том же духе. 
Hичего не навевает ?

EK> в XSL ты декларируешь, как ты будешь отображать тот или иной XML тег...
EK> вот и все...
Если бы.

EK> XML+XSLT удобнее тем, что бывают случаи, когда ты просто не знаешь...
EK> какие данные будешь выводить в template...

EK> скажем постраничная навигация вперед\назад...
EK> она может быть а может и нет...
Дык у меня например это просто решается - убиением блока с
навигацией. Только делается это в php, то есть программистом.

EK> в XSL ты можешь точно определить, есть она или нет... и соответсвенно если нет,
EK> то ничего не выводить вообще...
EK> а в template's тебе придется либо вводить логику (и уж тогда точно будут
EK> тормоза)... либо организовывать верстку таким образом, что появятся какие
EK> нибудь пустые <td> (80% сайтов на табличной верстке сделаны)...
EK> что не есть хорошо, ибо лишний HTML код в браузер..
Hеа, я делаю так, как описал выше. пока хватает.
Hо я не хочу спорить о функциональности - естественно у XSLT она не в
пример выше, чем у темплейтов.
Я об удобстве для дизайнера и о разделении логики и представления.
В XSLT я не вижу этого разделения, здесь логика присутствует постоянно,
это почти язык программирования. С таким же успехом я могу их
и PHP начать учить. За что боролись :) ?!

-- 
Best regards, Ed

Отправлено через сервер Talk.Ru - http://www.talk.ru
 

                          Привет, Vladlen !!!

 Как-то раз (а точнее 13 Jun 01 в 23:55) Vladlen Bulatov писал(а) к All:
 VB> Хм, я всегда думал, что верстальщик создаёт XML, а дизайнер -
 VB> XSLT/CSS. т.ч. здесь как раз выходит корректное разделение труда.
XML генерится скриптом, так что за него отвечает программер, дизайнер - делает
макет (графика), верстальщик - режет макет и клепает XSL/CSS/whatever.


--
mailto: random at info.net.ua                  //Александр

 

    Приветствую Вас Vladlen!

Было это не иначе как Сpеда Июнь 13 2001
Vladlen Bulatov -> All:

>> когда ты делаешь <?=$out;?> ты просто вызываешь встроенную функцию
>> написанную на Си...
VB> а при чем здесь Си ?
а на чем писан Zend Engine ???
парсинг вышепреведенного текста приводит вызову функции ядра Zend
интерпретатора (для PHP4)

>> что тут быстрее ?? ;) честно говоря... пока не знаю... нада будет с
>> FastTemplate поиграться ;))
VB> я уже "потыкался" как-то по разным темплейт-енжинам, и в результате
VB> пришёл к XSLT.
;)
ну, твою точку зрения, я в чем то поддерживаю... но вот например
некто Alexey Ivanov тут активно "язвил" на эту тему ;)

>> EK>> Однако выше я уже объяснил...
>> EK>> что исходя из чисто меркантильных соображений... когда
>> EK>> верстальщик _не пользует_ Апач\PHP... но делает
>> EK>> Темплейты... использование {TITLE} ему гораздо удобнее ;)
>> EK>> IMHO...
VB> именно - твоё IMHO, но обычно нормальный верстальщик желает потратить
VB> минимум времени на вёрстку, при этом не уделяя внимания дизайну.
богато живете...
т.е. у вас есть отдельно человеки, которые рисуют в Фотошопе, а есть
отдельно человеки, которые из фотошопа делают HTML\XSLT ???

по собственному опыту, мне наоброт пришлось сталкиваться с тем, что если
человек досконально не представляет, как именно данный дизайн будет выглядеть в
виде уже законченного HTML, то ему делать дизайн сайтов противопоказано...
(ну отдельные элементы - логотипы, коллажи ... можно :)
Как бы крут он не был в графике...

>> ;) а дизайнер тут и непричем... это Верстальщик должен заниматься...
>> есть хорошие дизайнеры... и плохие верстальщики...  и наоборот...
VB> Хм, я всегда думал, что верстальщик создаёт XML
эээ... хмм.. .в каком это месте его верстальщик, создает XML ?? XML у тебя
скриптом генериться, обычно по выборке из базы...

VB> а дизайнер - XSLT/CSS. т.ч. здесь как раз выходит корректное
VB> разделение труда.
хмм =))) а картинки кто тогда делает ?? Стилист чтоли ???
VB> ... ну а программист тут на подхвате у обоих.
да, затирают нашего брата :) А мне вот честна говоря не хочется быть у них на
подхвате... ибо, без меня, у них там вообще ничего крутиться не будет...

>> на самом деле... применение XML как средства хранения Template's
>> является может быть самым очевидным, но далеко не однозначно ЛУЧШИМ
>> (хотя и мощным, гибким) решением...
VB> имелся в виду XML или всё же - XSLT ?
имеется ввиду применение XML-related технологии XSLT в качетсве заменителей
Templates ;)

>> как мне кажется, наибольший эффект, XML будет иметь если
>> использовать для ВЕБА ...
VB> бррр, я наверное что то упустил ;)
VB> конференция вроде о ПХП, это с HЕ-Вебом вроде почти и не связано ;)
gtk.php.net ;) попробуй, вдруг понравится также как и мне ?? ;)

>> XML ориентированные базы данных, в которых пользуется не SQL а XQL
>> ;) или XPath
VB> XQuery, к сожалению, пока только на стадии выработки требований ;(
ну да... хых... не спорю...
Hо ведь сделают...

VB> XPath - конечно подходит для выборки элементов и их наборов, но
VB> сравнивать его с SQL - совсем неправильно, у них назначение разное.
хмм... тогда для чего нужен XPath ??

просто, я сейчас читаю усиленно все что касается XSLT, а XPath, просто пробежав
глазами туториал на zvon.org ... воспринял именно как "SQL для XML" ;)

>> К такому выводу, можно прийти, если представить сайт, ЛЮБОЙ сайт, в
>> виде дерева (чем он собтсвенно и является... поскольку, изначально, его
>> структура, основана на структуре файлов и каталогов, которые ничем
>> иным кроме дерева не являются)
VB> и запихнуть весь сайт в один XML файл ? увольте ;)
не в файл !!
А в XML дерево, которое хранится уже в XML ориентированной базе данных...

>> EK>> Угу =)) и CodeCharge тому прямой пример.
>> EB> А кто это ? Можешь хоть в 2-х словах. Или дай урл, где почитать.
>> www.codecharge.com
>> в двух словах - Визуальное средство разработки WEB интерфейсов к
>> базам данных...
VB> А чем оно существенно отличается от FrontPage/InterDev ?
поскольку я указанную тобой связку не использовал...
совет один, скачай... посмотри !
по моему отличается... СУЩЕСТВЕHHО...

>> EB> А как их заставить XSL юзать я вообще не знаю, там же блин масса
>> EB> логики налицо !
>> Hа самом деле, там не так уж много логики... в XSL ты декларируешь, как
>> ты будешь отображать тот или иной XML тег... вот и все...
VB> что, кстати, значительно сокращает общий текст темплейтов. Т.е. рост
VB> кол-ва страниц - практически не отражается на росте объёма темплейтов
VB> (за исключением, когда или вводятся новые сущьности-теги или когда для
VB> некоего набора страниц нужно немного поменять дизайн)
хых... вот тут честно говоря не уверен...
но и оспаривать не буду, нада делать... пробовать... а потом уж говорить что то
;)

                    Всего хорошего .....
                                        Slach.
 

Hi,

Eugeny Klimov wrote:

> VB> я уже "потыкался" как-то по разным темплейт-енжинам, и в результате
> VB> пришёл к XSLT.
> ;)
> ну, твою точку зрения, я в чем то поддерживаю... но вот например
> некто Alexey Ivanov тут активно "язвил" на эту тему ;)

Этот некто AI не использует template engines, весь его template engine

if() include;

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

> VB> и запихнуть весь сайт в один XML файл ? увольте ;)
> не в файл !!
> А в XML дерево, которое хранится уже в XML ориентированной базе данных...
Поясните термин пожалуйста...

-- 
Alexei
 

Здравствуйте Уважаемые.

"Alexander Kostiuchenko"
<Alexander.Kostiuchenko@p5.f468.n463.z2.fidonet.org> wrote in message
news:992578046@p5.f468.n463.z2.ftn...
>                           Привет, Vladlen !!!
>
>  Как-то раз (а точнее 13 Jun 01 в 23:55) Vladlen Bulatov писал(а) к All:
>  VB> Хм, я всегда думал, что верстальщик создаёт XML, а дизайнер -
>  VB> XSLT/CSS. т.ч. здесь как раз выходит корректное разделение труда.
> XML генерится скриптом, так что за него отвечает программер, дизайнер - делает
> макет (графика), верстальщик - режет макет и клепает XSL/CSS/whatever.

1) вы забыли ещё художника - рисует то, как раз, обычно он ;)
хотя все 4-е категории довольно расплывчаты, и часто часть той или иной
работы выполняется смежными профессиями.
2) не понятно зачем программисту давать статические текстовые куски ?
нехай, этим занимается верстальщик.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Eugeny Klimov" <Eugeny.Klimov@p8.f201.n5010.z2.fidonet.org> wrote in
message news:992565198@p8.f201.n5010.z2.ftn...
> >> когда ты делаешь <?=$out;?> ты просто вызываешь встроенную функцию
> >> написанную на Си...
> VB> а при чем здесь Си ?
> а на чем писан Zend Engine ???
> парсинг вышепреведенного текста приводит вызову функции ядра Zend
> интерпретатора (для PHP4)

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

> >> что тут быстрее ?? ;) честно говоря... пока не знаю... нада будет с
> >> FastTemplate поиграться ;))
> VB> я уже "потыкался" как-то по разным темплейт-енжинам, и в результате
> VB> пришёл к XSLT.
> ;)
> ну, твою точку зрения, я в чем то поддерживаю... но вот например
> некто Alexey Ivanov тут активно "язвил" на эту тему ;)

во первых не язвил, а отстаивал свою точку зрения ;)
а во вторых - поддержка технологий XML в ПХП пока довольно слаба, т.ч. и
распространение из-за этого довольно слабое.
(даже наверное не только в ПХП, а в Апаче, вот когда выйдет стейбл 2.0 тогда
и посмотрим)

> >> EK>> Однако выше я уже объяснил...
> >> EK>> что исходя из чисто меркантильных соображений... когда
> >> EK>> верстальщик _не пользует_ Апач\PHP... но делает
> >> EK>> Темплейты... использование {TITLE} ему гораздо удобнее ;)
> >> EK>> IMHO...
> VB> именно - твоё IMHO, но обычно нормальный верстальщик желает потратить
> VB> минимум времени на вёрстку, при этом не уделяя внимания дизайну.
> богато живете...
> т.е. у вас есть отдельно человеки, которые рисуют в Фотошопе, а есть
> отдельно человеки, которые из фотошопа делают HTML\XSLT ???

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

> по собственному опыту, мне наоброт пришлось сталкиваться с тем, что если
> человек досконально не представляет, как именно данный дизайн будет выглядеть в
> виде уже законченного HTML, то ему делать дизайн сайтов противопоказано...
> (ну отдельные элементы - логотипы, коллажи ... можно :)
> Как бы крут он не был в графике...

если он не "крут" в HTML, то и работать должен не один, а в паре (лучше в
группе)

> >> ;) а дизайнер тут и непричем... это Верстальщик должен заниматься...
> >> есть хорошие дизайнеры... и плохие верстальщики...  и наоборот...
> VB> Хм, я всегда думал, что верстальщик создаёт XML
> эээ... хмм.. .в каком это месте его верстальщик, создает XML ?? XML у тебя
> скриптом генериться, обычно по выборке из базы...

см. предыдущие сообщение ;)

> VB> а дизайнер - XSLT/CSS. т.ч. здесь как раз выходит корректное
> VB> разделение труда.
> хмм =))) а картинки кто тогда делает ?? Стилист чтоли ???

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

> VB> ... ну а программист тут на подхвате у обоих.
> да, затирают нашего брата :) А мне вот честна говоря не хочется быть у них на
> подхвате... ибо, без меня, у них там вообще ничего крутиться не будет...

как и у тебя без них ;)
но ты то, как раз, вполне можешь облегчить себе работу. А у них - такое
бывает довольно редко, обычно только когда им предлагают удобные решения и
ещё в придачу обучают таковым.

> >> на самом деле... применение XML как средства хранения Template's
> >> является может быть самым очевидным, но далеко не однозначно ЛУЧШИМ
> >> (хотя и мощным, гибким) решением...
> VB> имелся в виду XML или всё же - XSLT ?
> имеется ввиду применение XML-related технологии XSLT в качетсве заменителей
> Templates ;)

ранее я уже писал, что XSLT вполне развитое решение, когда свёрстан
прототип. Т.к. править XSL проще чем набор темплейтов старого образца. И
объясняется это довольно просто, XSLT в основе - декларативен, а обычные
шаблоны - больше смахивают на процедурный подход, которые не программисту
часто слишком сложен (я сравниваю большие объёмы, а не 4-6 страниц-шаблонов)

> >> как мне кажется, наибольший эффект, XML будет иметь если
> >> использовать для ВЕБА ...
> VB> бррр, я наверное что то упустил ;)
> VB> конференция вроде о ПХП, это с HЕ-Вебом вроде почти и не связано ;)
> gtk.php.net ;) попробуй, вдруг понравится также как и мне ?? ;)

врядли ;)
я не люблю использовать какой-либо язык, только из-за того, что других не
знаю ;)

> >> XML ориентированные базы данных, в которых пользуется не SQL а XQL
> >> ;) или XPath
> VB> XQuery, к сожалению, пока только на стадии выработки требований ;(
> ну да... хых... не спорю...
> Hо ведь сделают...

когда сделают - тогда и посмотрим ...

> VB> XPath - конечно подходит для выборки элементов и их наборов, но
> VB> сравнивать его с SQL - совсем неправильно, у них назначение разное.
> хмм... тогда для чего нужен XPath ??
>
> просто, я сейчас читаю усиленно все что касается XSLT, а XPath, просто пробежав
> глазами туториал на zvon.org ... воспринял именно как "SQL для XML" ;)

Совсем не так, к сожалению ;(
довольно простой пример - XPath не может делать выборки из нескольких
деревьев. А если их объединять в одно, то это дыольно дорогая операция (на
примере SQL - декартово произведение)

> >> К такому выводу, можно прийти, если представить сайт, ЛЮБОЙ сайт, в
> >> виде дерева (чем он собтсвенно и является... поскольку, изначально, его
> >> структура, основана на структуре файлов и каталогов, которые ничем
> >> иным кроме дерева не являются)
> VB> и запихнуть весь сайт в один XML файл ? увольте ;)
> не в файл !!
> А в XML дерево, которое хранится уже в XML ориентированной базе данных...

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

> >> EK>> Угу =)) и CodeCharge тому прямой пример.
> >> EB> А кто это ? Можешь хоть в 2-х словах. Или дай урл, где почитать.
> >> www.codecharge.com
> >> в двух словах - Визуальное средство разработки WEB интерфейсов к
> >> базам данных...
> VB> А чем оно существенно отличается от FrontPage/InterDev ?
> поскольку я указанную тобой связку не использовал...
> совет один, скачай... посмотри !
> по моему отличается... СУЩЕСТВЕHHО...

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

> >> EB> А как их заставить XSL юзать я вообще не знаю, там же блин масса
> >> EB> логики налицо !
> >> Hа самом деле, там не так уж много логики... в XSL ты декларируешь, как
> >> ты будешь отображать тот или иной XML тег... вот и все...
> VB> что, кстати, значительно сокращает общий текст темплейтов. Т.е. рост
> VB> кол-ва страниц - практически не отражается на росте объёма темплейтов
> VB> (за исключением, когда или вводятся новые сущьности-теги или когда для
> VB> некоего набора страниц нужно немного поменять дизайн)
> хых... вот тут честно говоря не уверен...
> но и оспаривать не буду, нада делать... пробовать... а потом уж говорить что то
> ;)

надеюсь, что такое brainbench.com знаешь ;) так он уже с пол-года на
XML/XSLT :)
IBM, Microsoft, Oracle - готовятся к полному переходу, Sun вроде туда же.
а людям, которые зарабатывают деньги, я склонен верить. Во всяком случае
пока не обманывался.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

Здравствуйте Уважаемые.

"Alexei Ivanov" <A.Ivanov@tu-bs.de> wrote in message
news:3B2B4314.A1C40B07@tu-bs.de...
> Hi,
>
> Eugeny Klimov wrote:
>
> > VB> я уже "потыкался" как-то по разным темплейт-енжинам, и в результате
> > VB> пришёл к XSLT.
> > ;)
> > ну, твою точку зрения, я в чем то поддерживаю... но вот например
> > некто Alexey Ivanov тут активно "язвил" на эту тему ;)
>
> Этот некто AI не использует template engines, весь его template engine
> if() include;

хозяин - барин ;)

> и одно это такое позволяет.., что никаких классов не надо.
> и время обрабоки уменьшается и интрфейс от информации отделяется
> и модульность получается и читаемость возрастает и даже настроение
> улучшается... :-)))
>
> > VB> и запихнуть весь сайт в один XML файл ? увольте ;)
> > не в файл !!
> > А в XML дерево, которое хранится уже в XML ориентированной базе данных...
> Поясните термин пожалуйста...

скорее всего имелось в виду DOM-дерево, во всяком случае я понял это именно
так.

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)


 

                          Привет, Ed !!!

 Как-то раз (а точнее 14 Jun 01 в 19:47) Ed Bartosh писал(а) к Eugeny Klimov:
 EB> Hо я не хочу спорить о функциональности - естественно у XSLT она не в
 EB> пример выше, чем у темплейтов.
темплейтовые движки тоже разные бывают, тот же XSLT по полной программе сосет у
Template::Tookit (www.tt2.org), а для PHP что-то подобное уже делают (основная
идея - компиляция шаблона в отдельный скрипт)


--
mailto: random at info.net.ua                  //Александр

 

                          Привет, Vladlen !!!

 Как-то раз (а точнее 16 Jun 01 в 19:53) Vladlen Bulatov писал(а) к All:
 >> дизайнер - делает макет (графика), верстальщик - режет макет и клепает

 VB> 1) вы забыли ещё художника - рисует то, как раз, обычно он ;)
а чем отличается дизайнер от художника, если на сайте отсутствует 'custom
graphics' (по крайней мере у нас в студии, да и не только у нас, художник -
человек, который рисует эту самую 'custom graphics' [уж не знаю, как это на
русский перевести без потери содержания] , как правило БЕЗ использования компа
[в крайнем случае - планшет]) - а большинство сайтов и практически все логотипы
делаются именно так.


--
mailto: random at info.net.ua                  //Александр

 

    Приветствую Вас Alexei!

Было это не иначе как Суббота Июнь 16 2001

>> VB> я уже "потыкался" как-то по разным темплейт-енжинам, и в
>> VB> результате пришёл к XSLT. ;)
>> ну, твою точку зрения, я в чем то поддерживаю... но вот например
>> некто Alexey Ivanov тут активно "язвил" на эту тему ;)
AI> Этот некто AI не использует template engines, весь его template engine
AI> if() include;
ууу... как все запущено...
*.de ;) в клуджах...

AI> и одно это такое позволяет.., что никаких классов не надо.
AI> и время обрабоки уменьшается и интрфейс от информации отделяется
AI> и модульность получается и читаемость возрастает и даже настроение
AI> улучшается... :-)))
вот такой вот я сам себе... веселый буратинка :)
HTML embened ;) круто конечно...

слушай, ты случаем не на PHP3 пишешь ? я так писал год, полтора назад...

>> VB> и запихнуть весь сайт в один XML файл ? увольте ;)
>> не в файл !!
>> А в XML дерево, которое хранится уже в XML ориентированной базе
>> данных...
AI> Поясните термин пожалуйста...
поясняю.
XML дерево - модель данных.
имеем следующие "сущности".
узел, родитель, атрибут, содержимое узла.
простейшие логические операции, помимо DELETE и SELECT еще получаются
NEW_NODE, MOVE_TO, SET_PARENT, SET_VALUE, SET_ATTR и т.п.

ну вот так... если в кратце...
а подробнее в yandex'e где то находил неплохую (хотя местами рекламную) статью
на эту тему.

                    Всего хорошего .....
                                        Slach.
 

Hi,

Eugeny Klimov wrote:

> AI> Этот некто AI не использует template engines, весь его template engine
> AI> if() include;
> ууу... как все запущено...
возможно.

> слушай, ты случаем не на PHP3 пишешь ? я так писал год, полтора назад...
объясни лучше чем это так плохо.

> >> А в XML дерево, которое хранится уже в XML ориентированной базе
> >> данных...
> AI> Поясните термин пожалуйста...
> поясняю.
> XML дерево - модель данных.
> имеем следующие "сущности".
> узел, родитель, атрибут, содержимое узла.
> простейшие логические операции, помимо DELETE и SELECT еще получаются
> NEW_NODE, MOVE_TO, SET_PARENT, SET_VALUE, SET_ATTR и т.п.
Это замечательно а теперь на какой коэффициент больше 10e3 мне стоит
домножить производительность такой базы чтобы сравнитвать с нормальной?

-- 
Alexei
 

Hi,

Кстати в дополнение:

Eugeny Klimov wrote:

> AI> Этот некто AI не использует template engines, весь его template engine
> AI> if() include;
> ууу... как все запущено...
> *.de ;) в клуджах...

Может сэр вообще if then else не пользует, потому как устарело и вообще...
Я бы только хотел узнать, что из новомодного заменило эту конструкцию?

-- 
Alexei
 

   Приветствую тебя, Ed...

 Как-то в Четверг Июнь 14 2001 года, примерно в 18:47 Ed Bartosh писал к Eugeny
Klimov следущие строки:

Почитал я тут почитал пpо ваше pазделение тpуда:) и сам уже запутался...вpоде
как по канонам сайтостpоительства: дизайнеp, котоpый pисует, да-да, пpосто
pисует в фотошопе макет стpаницы(полный, как всё он видит), для сайта чуток
потяжелей, он же pежет макет на отдельные куски( в помощь веpстальщику:) значит
веpстальщик должен собpать хтмл pазметку стpаницы без всякого пpогpаммиpования,
а потом пpогpаммёp уже должен всё это дело довести до ума:)со всякими БД.
дальше
моё ИМХО Коpоче в ходе моих pазмышлений я понял, что веpстальщик в вебе - есть
звено котоpое вымpет очень скоpо:) В настоящее вpемя ф-ции веpстальщика будет
выполнять пpогpаммист.

  Счастливо, Ed!

 

Linux login: Alexander
password: :-P

 AP> должен всё это дело довести до ума:)со всякими БД. дальше моё ИМХО
 AP> Коpоче в ходе моих pазмышлений я понял, что веpстальщик в вебе - есть
 AP> звено котоpое вымpет очень скоpо:) В настоящее вpемя ф-ции
 AP> веpстальщика будет выполнять пpогpаммист.
Верстальщик много дешевле программиста. Если программисту надо платить
$10/hour, то верстальщику можно и $3/hour. Поэтому никуда верстальщики не
денутся.

With best wishes Igor.

    Key fingerprint = 31C3 0B0B 5FF2 FE45 8D64  718D 5BA2 80CC 7B77 88DD
 

    Приветствую Вас Alexei!

Было это не иначе как Втоpник Июнь 19 2001
Alexei Ivanov -> All:
>> AI> Этот некто AI не использует template engines, весь его template
>> AI> engine if() include;
>> ууу... как все запущено...
AI> возможно.
;) извини смайлик забыл...
вообще то, я покопался выяснилось, что сам так сейчас пишу =)
по крайней мере те части, что касаются BackOffice выглядят именно так...

>> слушай, ты случаем не на PHP3 пишешь ? я так писал год, полтора
>> назад...
AI> объясни лучше чем это так плохо.
да нет, на самом деле это вполне нормально...
так что извини, погорячился я наверное
если у тебя  PHP логика отделена от собственно вывода HTML'я
примерно так

if ($cmd=='list') {
 $q = $db->Execute('SELECT ... ');
 while ($q && !$q->EOF) {
  $list.='<tr><td>...';
  $q->MoveNext();
 }
 ...
 include('../templates/list.phtml')
}

а в list.phtml соответсвенно идет
<?=$list;?>

то ничего плохого нет... как мне кажется...
>> поясняю.
>> XML дерево - модель данных. имеем следующие "сущности".
>> узел, родитель, атрибут, содержимое узла.
>> простейшие логические операции, помимо DELETE и SELECT еще
>> получаются NEW_NODE, MOVE_TO, SET_PARENT, SET_VALUE, SET_ATTR и т.п.
AI> Это замечательно а теперь на какой коэффициент больше 10e3 мне стоит
AI> домножить производительность такой базы чтобы сравнитвать с
AI> нормальной?
дык я же не говорил, что я сравнивал...
я Инсталяху Cache выкачать не могу =)) она ~70 метров и линков прямых на файл
нету =))
но IMHO савсем не факт, что оно будет так сильно менее производительно...
самому хочется пощупать =))) и либо сказать свое ФИ... либо сказать что оно
действительно РУЛЕЗ ;)

                    Всего хорошего .....
                                        Slach.
 

Hi Alexander!

19 Jun 01 23:10, Alexander Pletneuv wrote to Ed Bartosh:

 AP> Коpоче в ходе моих pазмышлений я понял, что веpстальщик в вебе - есть
 AP> звено котоpое вымpет очень скоpо:) В настоящее вpемя ф-ции
 AP> веpстальщика будет выполнять пpогpаммист.
    Режет все верстальщик. И скрипты в нужные места вставляет тоже
    верстальщик. Программисту нафиг не нужно знать как картинки
    оптимизировать и как таблицы накручивать.

    Я два дня потратил на реализацию вот такой таблицы
    +-------+-----------------------------------+
    |       |            B                      |
    |   A   +-----------------------+-----------+
    |       |       C               |    D      | +-------+-----------------------+           |
    |             E                 |           |
    +-------------------------------+-----------+

    Вроде ничего сложного, правда?
    но мне нужно было что бы А и D имели постоянную ширину,
    а B C E растягивались пропорционально ширине окна,
    Как же я задолбался... В Е находится банер, 468х60 ,
    пока его нет, все замечательно, как только он появляется
    (я просто стал увеличивать его длину) так же резво
    начинает B и D уезжать за пределы окна, хотя реально
    все должно умещаться без скроллинга.
    В результате мучений, таблица получилась такая:
    +-------+--------------------------------------+
    |       |                                      |
    +-------+--------------------------------------+
    +--------------------------------+-------------+
    |+------+-----------------------+|             |
    ||      |                       ||             |
    |+------+-----------------------+|             | +--------------------------------+             |
    |                                |             |
    +--------------------------------+-------------+

    Вот таким макаром все растягивается как мне надо. :)

    вот верстальщик, а не программер, и должен из макета нарезать
    эту таблицу. И в нужных местах вставить <? func(); ?>
    или <!--#exec ... -->

    ps. Это я уже упростил начальную таблицу, там еще и в C и в D и в E
    свои таблички получились.

                                                   Slav.
 

Здравствуйте Уважаемые.

"Eugeny Klimov" <Eugeny.Klimov@p8.f201.n5010.z2.fidonet.org> wrote in
message news:993000735@p8.f201.n5010.z2.ftn...
>     Приветствую Вас Alexei!
>
> Было это не иначе как Втоpник Июнь 19 2001
> Alexei Ivanov -> All:
> ...
> >> слушай, ты случаем не на PHP3 пишешь ? я так писал год, полтора
> >> назад...
> AI> объясни лучше чем это так плохо.

не то чтобы плохо, просто немного более громоздско - теже самые сессии,
псевдо-ООП и т.д.

> да нет, на самом деле это вполне нормально...
> так что извини, погорячился я наверное
> если у тебя  PHP логика отделена от собственно вывода HTML'я
> примерно так
>
> if ($cmd=='list') {
>  $q = $db->Execute('SELECT ... ');
>  while ($q && !$q->EOF) {
>   $list.='<tr><td>...';
>   $q->MoveNext();
>  }
>  ...
>  include('../templates/list.phtml')
> }

плохо тем самым - $list.='<tr><td>...'

> а в list.phtml соответсвенно идет
> <?=$list;?>

т.е. явный процедурный стиль
а такое даже "продвинутые" верстальщики/дизайнеры понимают не до конца, и в
чём-то они правы - им то под данным кодом (<?=$list;?>) представляется некий
чёрный ящик, а XML с XSLT при правильной разработке шаблонов, большую часть
делает "белыми ящиками"

> то ничего плохого нет... как мне кажется...
> >> поясняю.
> >> XML дерево - модель данных. имеем следующие "сущности".
> >> узел, родитель, атрибут, содержимое узла.
> >> простейшие логические операции, помимо DELETE и SELECT еще
> >> получаются NEW_NODE, MOVE_TO, SET_PARENT, SET_VALUE, SET_ATTR и т.п.

на сегодня - да, прямое (или псевдо-прямое) преобразование ДБ<->XML довольно
ресурсо-ёмко, но решения за последние месяцы растут почти как грибы, т.ч.
очень большая вероятность, что скоро подобное будет сравнимо с обычными БД

> AI> Это замечательно а теперь на какой коэффициент больше 10e3 мне стоит
> AI> домножить производительность такой базы чтобы сравнитвать с
> AI> нормальной?

а зачем использовать именно такой вариант ?
пока можно обойтись и более простыми - например, преобразованием
DB->XML->HTML
где DB->XML выполняется на "чистом" PHP, а XML->HTML - уже использует XSLT

> дык я же не говорил, что я сравнивал...
> я Инсталяху Cache выкачать не могу =)) она ~70 метров и линков прямых на файл
> нету =)) 
:) 
> но IMHO савсем не факт, что оно будет так сильно менее производительно...

смотря на каких операциях. На выборках - Cache выигрывает даже у майсикула,
а вот на апдейтах ...

> самому хочется пощупать =))) и либо сказать свое ФИ... либо сказать что оно
> действительно РУЛЕЗ ;)

если на самом деле ОПРОБУЕШЬ - будем рады услышать отзыв ;)
но я ПОКА несколько скептичем в отношении XML-баз-данных

С Уважением, Влад (vlad@econ.msu.ru, 2:5020/169.14)