Преобразование XML данных в HTML с помощью XSL,JS,CSS не вызывает никаких вопросов.
Тут всё относительно просто. Интереснее момент построения того же портала, где на
смену HTML приходит SVG или FLASH. Задачка такая:
— имея один и тот же набор исходных данных в виде XML получить возможность
генерировать что-то не только в виде HTML-страниц, но и в тот же FLASH.

Одна из проблем такой генерации — вычисление размеров отрисовываемых объектов.
И неважно, хотим мы получить FLASH или SVG, объектам нужно указывать вполне
определенные координаты {x, y, width, height, ...}. Напомню, что с HTML всё
просто, потому как те же таблицы умеют растягиваться, чтобы вместить текст/имидж/...
в ячейке.

Есть ли у кого какие задумки, зацепки и просто предложения/мысли как это дело организовать?

Буду очень благодарен за ответы. И просьба — воздержаться от пустых замечаний не по теме.
Жду только конструктивного разговора

Мне кажется, это практически нереально — подсчитывать координаты для SVG объектов прямо в XSL. То есть это конечно реально — мы тут работали над представлением научной графики — но получить нечто качественное и динамически подстраивающееся не получится. Все-таки XSL служит для преобразования XML представлений, а не для их создания. Вот у нас, например, есть графики с _заранее_ заданными координатами. Поэтому их вполне можно отобразить. Однако это все делается через заднее место, взять хотя бы вычисление мин., макс. для отображаемого пространства — для этого приходится сортировать значения, выбирать первое и последнее, в общем сплошная неэффективность.

Хотя, если создать свой taglib, может быть можно и попробовать...

G>Мне кажется, это практически нереально — подсчитывать координаты для SVG объектов прямо в XSL. То есть это конечно реально — мы тут работали над представлением научной графики — но получить нечто качественное и динамически подстраивающееся не получится. Все-таки XSL служит для преобразования XML представлений, а не для их создания.

вот тут хотелось бы не согласиться. Взять то же получение FO с помощью
XSL-преобразований, когда XML data -[XSL]-> XML:FO -[...]-> PDF | ...
Узкое место это мат.аппарат для вычислений. И они довольно-таки непросты.
Хотя возможно, что это лишь на первый взгляд нереализуемо.
Да, это сложно, но что это нереализуемо — не факт.

G>Хотя, если создать свой taglib, может быть можно и попробовать...
об этом собственно и речь

ну так что, есть тут народ, сильный
в математике и алгоритмах? отзовитесь

Посмотрите www.tt2.org. К этому продукту есть plug-in, работающий с XPath. Сам продукт написан на Perl, т.е. Perl можно использовать для анализа XML-ей. Я не знаю технологию производства флешей, но если там присутствует в каком-то виде исходный код, то этот код можно генерить точно также, как и HTML.

D>Посмотрите www.tt2.org. К этому продукту есть plug-in, работающий с XPath. Сам продукт написан на Perl, т.е. Perl можно использовать для анализа XML-ей.
за ссылку спасибо
но разговор о другом. Не о темплейтах, хотя возможно есть в их использовании рациональное зерно. о, да это идея использовать темплейты как вспомогательную площадку.

D>Я не знаю технологию производства флешей, но если там присутствует в каком-то виде исходный код, то этот код можно генерить точно также, как и HTML.
я малость погорячился, сказав про флэш. Гараздо было бы лучше сузить рассмотрение проблемы использованием только SVG. Напомню, что SVG — это XML-based язык. И текст svg-файла получить из исходных xml-данных — труда не составляет с помощью тех же xsl-темплейтов. Вся загвоздка в вычислительном аппарате и алгоритмах (которые возможно придется еще придумать), с помощью которых можно будет рассчитать svg-примитивы...

S>я малость погорячился, сказав про флэш. Гараздо было бы лучше сузить рассмотрение проблемы использованием только SVG. Напомню, что SVG — это XML-based язык. И текст svg-файла получить из исходных xml-данных — труда не составляет с помощью тех же xsl-темплейтов. Вся загвоздка в вычислительном аппарате и алгоритмах (которые возможно придется еще придумать), с помощью которых можно будет рассчитать svg-примитивы...

Мне почему-то кажется, что если трудность только в вычислениях, то это как раз поле, идеальное для пользовательских расширений. Какой-нибудь JavaScript может ведь решить проблему? Или он в Вашем случае недостаточен?

D>Мне почему-то кажется, что если трудность только в вычислениях, то это как раз поле, идеальное для пользовательских расширений. Какой-нибудь JavaScript может ведь решить проблему? Или он в Вашем случае недостаточен?
да, верно заметили, что это поле деятельности для пользовательских расширений. И если вспомнить о постановке задачи — проблема именно в мат.аппарате и в частности в алгоритмах для проведения расчетов.

замечу, что вычисления не обязательно проводить на стороне клиента. Да и, скажем так, нежелательно нагружать клиента вычислительными операциями — пусть их берёт на себя серверная сторона. Конечно можно использовать тот же JavaScript и на стороне сервера. Выбор языка, на котором будет реализована необходимая функциональность, сейчас не основной вопрос. Это может быть как C/C++, так и java и что угодно иное. Напомню, что речь не о нём, а о математическом аппарате, необходимом для решения задачи И каких бы то ни было конструктивных предложений/идей пока почти "ноль"

Прошу прощения, но замечу, что Ваш ответ, увы, не в тему

Здравствуйте, space®, Вы писали:

> для решения задачи И каких бы то ни было конструктивных > предложений/идей пока почти "ноль"

Вообще-то XML->(XSL)->SVG это как бы вполне проработанная область, и ее много кто использует. Ты же ставишь проблему отображения _специфических_ данных или создание _специфических_ представлений. Так что эту специфику надо более конкретно, а то конструктивных предложений не будет.

автозаполнение, блин...

G>Вообще-то XML->(XSL)->SVG это как бы вполне проработанная область, и ее много кто использует.
что много кто использует, согласен. Но что-то готовых решений для своей задачи пока не нашёл. Возможно не там искал Изюминка ведь в том — кто и как использует...

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

Да, ты прав. Попробую в ближайшее свободное время добавить конкректики