dozenНе понравилось. Слишком непривычно, непонятно - будет работать али нет, да и незачем - у него же Синдбада не было, он и так разных там варкрафтов гонял, команды футбольные тренировал, этот... как его... спайс добывал. Надо же и поработать для разнообразия! Вот уж по барабану! Олухи какие-нибудь. Кстати, подсказал бы им кто Processing на клиента перетащить на своей блок-схеме - забыли, небось. Ведь еще лет пять провозятся!

jooherАх, вона в чем дело... А "опыт", значицца, без понятия, чо там в "старом js" творицца - ему обязательно мои исходники подавай, да еще "одним архивом"... Поверьте, дорогой: простое молчание смотрится куда менее позороно, чем "жалкий лепет оправданий". Не говоря уж об откровенном признании - это просто уважение вызывает. "Криптополабуда", кстати, это простейший язык для интерпретации: всего два слова! Но для "некоторого опыта по этой теме" - оно, конечно, "магические взаимосвязи"... Между прочим, в приведенном примере вообще ОДНО такое "слово" используется.

PartisanДа, к сожалению. Шоб роздал тут пару-тройку щелбанов всяким... шоб не слышно было зубовного скрежета прямо отсюда. А хрен ли там "использовать"? Там же нет ничего! Это всего лишь технологическое обеспечение APS, и ничего более.Я-то как раз ПРЕКРАСНО знаю, что это. См. выше.

rGloryО! Ну, Ваше мнение для меня настолько ценно, что я, канэшна, срочно пересмотрю все свои взгляды. А, это Падеборн - я там и не был никогда, я думал - Гаага. Да, разгром полный, ажно пол-очка разница!Господи, да конечно вру! Меня ж до сих пор корежит, что "у Dragon только Юрий"!Ну да, ну да. Приношу искренние извинения. Всех турниров же не упомнишь - моя вина, старею...Совершенно верно, никто не мешал. Просто нам такая идиотская проблема как-то в голову не пришла. К тому же, кто знал - вдруг здесь объявился бы не я, а Юра. И чо делать? А у нас как-то проще все получалось:

Сочтемся славою - ведь мы свои же люди!
Пускай нам общим памятником будет
Мираж, Дракон, и даже Матадор.Совершенно верно. Ни в малейшей степени! Владимир еще в глубоком детстве прочитал, что "недооценка своих сил намного хуже, чем их переоценка". И поверил. Да, я полностью согласен: "Это опять-таки случай так называемого вранья". Никогда я противоположного не утверждал.

dozenУмница! Я просто поражаюсь такому полету мысли. Особенно противно, что "баннер" делал именно я - в жисть бы не подумал, что кто-то догадается. Браво! Соврешенно верно: Кентавр - УНИКАЛЬНАЯ программа! ПОТРЯСАЮЩАЯ! Среди шахматных ничего подобного никогда не было, нет и не будет. А использовал он Миража, как несложно догадаться (как же это Вы, сэр - такая феноменальная прозорливость, и тут же, следом...) для страховки от грубых ошибок, за которые любая переборная программа жестоко наказывает. Примерно так:
Кентавр: Я, пожалуй, слона на e3 сейчас передвину...
Мираж: Ну, если коня на b5 не жалко - валяй...

SERGEY_BIG
Я уже много лет ни на кого не обижаюсь. Я не против ни юмора, ни "безобидного троллизма для", но ХОТЬ ЧТО-ТО КРОМЕ должно же быть! Терминология - да: моя, Антона, Романа, ... но ведь другую откуда взять? Да, термин "шаблон" БЕЗУМНО перегружен - а что делать? Ну, хорошо, предположим: серверный - template, траекторный - pointer, структурный - structure, хранения - tag, атрибутный - class. И что, понятнее будет? А "домашнестраничный", "чужестранный", "расчетный", "базоданновый" - чего с ними делать?

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

Вначале набросаем желательный внешний вид виртуальных страниц.

Морда: навигация по группам объектов одного класса (или виртуального класса, типа Shippers). Плюс каждому ребенку число евойных детей. Пустовата страница, но больше здесь ничего и не прибавишь - у Access еще меньше информации по этому делу. При этом адреса, должности и прочая хрень даже групповых страниц не заслуживают. Столь же зияющая пустота у Countries - им даже количество детей неприлично выводить, потому как попали сюда лишь некоторые. Городам же "папу" вывести вполне допустимо. Предприятиям же, за исключением таинственных Shippers, выводим и папу, и деда. Категориям и продуктам (формат группового вывода вполне терпимый) разрешаем иметь персональные страницы. Employees я бы ваще выкинул на фиг - токо путаются под ногами. Но низзя - любимцы Access - скажут: испугался, дескать, со сложными вещами-то работать... Пущай сидят в том же формате - все равно на них в любом виде глядеть тошно. Persons... Ну, должность выведем для красоты... Персональных страниц они явно не заслуживают - у них больше просто гроша за душой нет, а зачем тогда эта страница без навигации? А, ну да - прилепим им в качестве ссылки фирму, на которой они работают. Те, которые Employees - ясный пень, на свою персональную должны укакзывать. Orders... Здесь бы не хило фильтры поставить (кстати, и на остальных фильтры по родительским столбцам). Ладно, фильтры - опосля, как и вообще заголовки таблиц.

Теперь "персоналии". Сверху, разумеется, шапка - "все о нем": Phone, Fax, Address, и все прочее, что попадется под руку в этой поганой базе. Где надо - со ссылкой куда надо. А вот дальше, собссно, и начинается то, ради чего я весь этот огород и городил: связи.

Самое простое - Order. Но и самое важное - это "информация к размышлению" для всех остальных персональных страниц. Сколько и когда какого товара куда переехало, сколько бабок отвалил каждый Customer всяким там Suppliers и Shippers (или, наоборот, оштрафовал какую падлу за срыв сроков). Рейтинги поставщиков и товаров, так и быть, считать не будем. Если задавать диапазон дат - это еще и фильтр, какие компании с какими в это время поддерживали связи, какие товары пользовались популярностью и т.д. Так что число виртуальных страниц быстренько улетает в бесконечность, а вывод их становится все более "задумчивым". Можно рисовать всякие графики состояния текущего счета, но мы этого делать не будем (разве что отдельным столбцом дадим). Для страниц товаров и категорий, таким образом, будет видна динамика востребованности (по фирмам, городам, странам, общая), а город или страна, по сути, то же обобщенное предприятие - связи с партнерами, движение товаров (категорий), состояние "кармана". Вот такое вот примерное общее "ТЗ". Что-то мне подсказывает (опять, небось, спина), что выглядеть все это дело должно НУ ОЧЕНЬ смешно. Если уж эти друзья даже с названиями компаний и с телефонами умудрились запутаться... О другом ТЗ я уже говорил: разобраться с Гуглем, чтобы юзеры знали, какие этому козлу вопросы нужно задавать для получения сколько-нибудь "релевантных" ответов.

Что скажете, господа? И скажете ли что?

Vladimir Rybinkin
Что скажете, господа?
Что было бы весьма интересно пообщаться с господином Шпеером, уж который год ждем.
И было бы здорово, если Вы передадите ему это приглашение.

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

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


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

Упорству VR можно только позавидовать.

К концу жизни, а точнее на склоне лет, Иеремия пережил поразительную метаморфозу. Наглухо запершись в своем подвале, из которого он убрал все до единого обломки аппаратов, и оставшись наедине с пустыми стенами, деревянной лежанкой, табуретом и старым железным рельсом, он уже никогда не покидал это убежище, или, если угодно, добровольную темницу. Кроме куска хлеба и кружки воды через небольшое дверное окошко ему передавали предметы, которые он требовал, а требовал он все эти шестнадцать лет одного и того же: молотков различного веса и формы. В общей сложности он получил их 3219 штук; когда же великое сердце остановилось, по всему подвалу сотнями валялись заржавевшие, сплющенные титаническими усилиями молотки. "Я ей покажу!", "Я ей задам жару!", "Еще чуть-чуть, и я ее порешу!" - такими, набросанными его характерным, неразборчивым почерком замечаниями пестрят эти толстые тетради, пересыпанные металлическими опилками. Кому собирался он задать жару? Кого порешить? Это пребудет тайной - противница, столь же загадочная, сколь и могущественная, не названа ни разу по имени. Видится мне, что в минуту озарения, которое нередко посещает великие души, он решил совершить на самом высоком, предельном уровне - то, что прежде пробовал сделать не столь дерзновенно. Теперь же, укрывшись в своей добровольной темнице от своры скудоумных хулителей, гордый старец через подвальную дверь вошел в историю, ибо - это моя гипотеза - схватился с самой могущественной на свете противницей: все эти шестнадцать каторжных лет его ни на минуту не оставляла мысль, что он штурмует средоточие бытия и неустанно, без колебаний, сомнений и жалости, бьет самое материю!

dozen
А здесь мы ждем работоспособного решения. Да-да, работоспособного на современных, стандартных, браузерах, а не на вышедшем из употребления дырявом IE5.
Решения чего?
Имхо не столь принципиально, на каком браузере работает решение.
Важно что именно решается, и как это делается - принцип работы, имеет он ценность сам по себе или нет.
А браузер можно уговорить плагином в конце концов.

но не в этой теме.
Если честно, не вижу конструктивных отличий тем автора друг от друга. Впрочем, если искомый персонаж появится, грех не создать/поднять соответствующую ветку.

Gipnoss
Решения чего?

Решения поставленной автором (перед собой) задачи. Мне задача покуда в деталях неясна, что-то вроде автогенератора навигации по сетевой базе (но причем тогда тут процессинг на клиенте?).

Имхо не столь принципиально, на каком браузере работает решение... браузер можно уговорить плагином

Для начала неплохо бы понять, имеет ли смысл "уговаривать". Ставить IE5 только для того, чтобы принять участие в дискуссии -- слишком много мороки.

Vladimir Rybinkin
ему обязательно мои исходники подавай, да еще "одним архивом"... Поверьте, дорогой: простое молчание смотрится куда менее позороно, чем "жалкий лепет оправданий".

Типа это я теперь сам виноват, что в твоем говне не разобрался? Криптолабуда кстати - это отнюдь не "bcdem" и не "afijklosz_", и даже не m.i(e,"q","","i",0,"s",m.a(),"l",m.a()), а весь твой код целиком. В нем возможно и стоило бы разбираться ради интереса, если бы "благодаря Витьке" не было уже известно, что это тормозное полурабочее... нечто (слово г.. уже было). Так што ты уж, дорогой, не обижайся. Поэтому тебе и предлагают выкладывать исходники - может в них что-то осмысленное можно будет увидеть.

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

Добавление от 01.09.2009 22:54:

Vladimir Rybinkin
какие этому козлу вопросы нужно задавать для получения сколько-нибудь "релевантных" ответов.

ничо што я Вас цытирую?

jooher
Поэтому тебе и предлагают выкладывать исходники - может в них что-то осмысленное можно будет
увидеть.
Ага, сейчас. Мастер уже сказал своё неуловимое мнение, деталями пусть другие занимаются. В
предыдущий раз выжимали алгоритм, выжали полудохлый исходник, с поведением которого было всё
более-менее ясно уже с первых предположений о замысле Мастера. Сейчас начали с черте-чего, кончится,
видимо, полным пшиком. Половину рекордной дистанции в 39 страниц уже прошли. Я только терпению
участников удивляюсь. Ну любопытно иногда поприкалываться, но всему же есть предел, да?

Vladimir RybinkinНу ivanhoe улетел в теплые края, так чта придется, Вам, Владимир Батькович с собственной спиной советоваться. Или с тем, что ниже, разницы наверное уже не будет...

jooher
Когда же, например, я тут предлагал обсудить свое решение обозначенной тобой темы
каюсь, когда-то считал, что твой код трудно читать. но всё познается в сравнении. после кода ВР я готов к любому.

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

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

All
Я хочу перетащить на клиента возможно большую часть обработки данных, необходимой для удовлетворения потребностей того самого клиента (любишь кататься - люби и саночки возить). Не какой-то вшивый AJAX, который "предохраняет" пользователя от мучительного ожидания ответов с сервера (можно подумать, нынешние юзеры ваще знают, что это такое), а полноценный медиатор - с ним, и только с ним общается человек, для которого он и есть весь Интернет - понятный, привычный, персональный, "в домашних тапочках".

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

В моем случае клиент предназначен для общения с СУБД сервера (все остальные виды общения все равно когда-нить сведутся к этому ). Итак, на клиента подается некотрая выборка из БД (для простоты - из одной). Все ссылки препарированы перед подачей на клиента в локальные, так что можно считать выборку просто самостоятельной БД, а клиента - СУБД. Грубо говоря, СУБД клиента(ов) взаимодействует с СУБД сервера(ов). Ну и...
- Тут юзер... эта... кнопку нажал...
- Скажи ему что-нибудь, пусть отвяжется.

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

На логическом уровне БД - граф, у которого каждый узел может иметь произвольное число ребер (точнее, дуг) на другие узлы, и произвольное число других информационных полей (в т.ч. полей-массивов, вроде нескольких телефонов). Никаких "нормальных" форм, никаких плоских таблиц - данные РЕАЛЬНЫЕ, а не погремушки от РБД! Вся эта кухня управляется метаданными (классами) - тот же субграф, но предназначенный главным образом для самой клиентской СУБД. При инициализации объекты БД из транспортного формата размалываются на атомарные элементы (узлы, поля, субполя) , т.е. переводятся в некоторое подобие "неплотного" трехмерного массива (или, если угодно, дерева) - для удобства адресации. Иными словами, доступ к узлу по ID - как к обычному элементу массива [], к полю - [][], к субполю - [][][]. То же для метаданных.

По командам юзера СУБД клиента рыщет по данным, наводя при необходимости нужные справки в субграфе метаданных, и обменивается данными с "настоящей" СУБД. Ну и юзера не забывает.

Теперь - за дело. Вначале наведем кое-какой порядок в текстах - давно не "умывались"... сделано! Ну, начнем, помолясь...

Ну вот, сразу мордой в салат: метаданные для классов "рваные", число их различное, а втискивать сюда технологию Синдбада (которой все равно, скоко там слоев метаданных) - мороз по коже! Нет уж, пока бум располагать метаданные в начале и конце класса (какая-никакая гибкость), на худой конец тег классу пришпилим (дважды уже отбивался от этой навязчивой идеи ). Ага! Нужно как-то указатель на массив 3-го измерения, как на одномерный получить. Тогда в малом шаблоне можно будет держать и формат выдачи, и все нужные траектории. Адрес мне надо, АДРЕС, джаваскриптизеры хреновы! Дело, однако, благородное - нужно хотя бы попытаться...

Так, что-то состряпали. Ну, Спаси и Сохрани! Ой, мама! Где у нас валерьянка? Это... это песня! Она... ГОСПОДИ, ОНА ЖЕ ЕЩЕ И РАБОТАЕТ!!! Но все дети (как и заголовок) выглядят, как однояйцевые близнецы, а именно:
Если "вслепую" пощелкать по ссылкам, можно добраться и до внуков, которые имеют имя класса (спасибо, Витек, надоумил!) и, поскольку имя класса выводится в обход этого замечательного произведения, выглядят чуть понятнее:
Ух ты! Легкое движение руки, и все это сменилось на "Company: Alfreds Futterkiste" и прочие привычные глазу страницы. Выглядит это дело так:
А внутри m.g второй параметр считается уже одномерным массивом, и она в нем вполне успешно ковыряется. Неужто сделал?! Похоже, что да, однако потрясение слишком сильное, чтобы продолжать - давненько не брал я в руки ядра SINT, которое и не такое вытворяло. Но от сраного JS в глаз получить... Блин, и водки в доме нет... Тьфу! Стоит в баре бутылка, на ней написано "уксус", а внутре и правда уксус... коньяк с детства не переношу, да и дед тоже - года два здесь стоит... рябина... тоже кислятина... Вау! Усе, прощайте, родные, прощайте, друзья - сегодня с поганцем отмучился я!

Vladimir Rybinkin
предугадывая пожелания пользователя (голубая мечта этих придурков).

Почему это придурков?
Что? Раз пользователь, то значит придурок?

Добавление от 02.09.2009 17:01:

Vladimir Rybinkin
Ессно, в самых общих чертах, поскольку именно этой "организацией" я как раз и занимаюсь.
Обана! А почему не наоборот? То, чем занимаетесь - подробно, а о чём знаете только понаслышке - "в самых общих чертах"

На логическом уровне БД - граф
Не всё можно уложить в дерево. Например, если узлы и ветки динамически вычисляемы, то может не получиться!

P.S. Эх. Опять мастер наклюкался! А у меня ещё столько вопросов!!

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

Мне одному это мутное описание браузерные silverlight (например) приложения напоминает?

Zafod B.
Мне одному это мутное описание браузерные silverlight (например) приложения напоминает?

Да и не только silverlight. Много технологий, начиная с древних Java applets, Flash, и на современном этапе, либы типа GWT -- все позволяют писать сложную логику на клиенте.

Если ограничить себя только JS (ради минимализма или портабельности), то остается (кроме чисто JS-либ a-la jQuery) только GWT (IMHO; кто еще что знает?).

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

dozen
возможно, тебе стоит попробовать описать свой подход еще раз

Ок. Дубль 3. публика разогрета, может подхватит

Фреймворк dap (Data Access Pages) разработан для интерактивных веб-приложений, активно работающих с внешними данными. Проект в младенческой стадии, но в принципе все работает, и работает хорошо.

Домашняя страничка проекта http://dapmx.org (правда, там по-нерусски, зато с примерами и подробно). Немного заброшено в связи с работой над новой версией.

Основная идея dap - описание структуры документа в "функциональном" стиле (функциональном в том же смысле, что и, скажем, функциональные языки программирования - Lisp, ML). Ядром dap является язык правил построения нода из шаблона разметки (в общем случае, это совершенно не обязательно HTML) в зависимости от контекста места, в которое нод вставляется. Контекст описывается переменными состояния (статусами) и данными от источника. Таким образом, генерируемые элементы dap-документа получаются как функции от шаблона и контекста. При апдейте статусов (обычно это происходит по user event), происходит автоматическое каскадное обновление нодов, зависящих от изменившихся статусов: все зависимые ноды каскадно перестраиваются АВТОМАТИЧЕСКИ. Все зависимости отслеживаются самим dapом, никакие дополнительные телодвижения (назначение нодам уникальных idов, навешивание onclickов, сочинение функций-обработчиков событий и поиск зависимостей) - от программиста НЕ ТРЕБУЮТСЯ - вообще никакие дополнительные скрипты на странице обычно не требуются. Все происходит автоматом. Что должно обновиться - обновляется, что не должно - не трогается.

В ядре реализован базовый функционал для работы с внешними XML-данными, легко расширяемый при необходимости. Одна из важных фич, которой было уделено серьезное внимание, - расширяемость/модульность. Рекомендованный способ построения dap-приложений - организация их в набор библиотек, которые могут использоваться на разных страницах проекта или в разных проектах. Причем библиотек не скриптовых хаков, а конкретных объектов - шаблонов.

В отличие от подхода ВР (насколько я его понял) и от того же GWT, дап описывает не процесс создания элементов документа (императивное построение), а непосредственно сами элементы и зависимости между ними (функциональное описание).

Простенький пример

Взять список производителей (брендов) по адресу http://dapmx.org/samples/bazamagaza/?_=AllBrands, показать. При нажатии на бренд показывать (то есть не просто показать один раз, а обновлять список при каждом новом нажатии) список <ul> товаров этого производителя (поле display - название товара), используя запрос вида http://dapmx.org/samples/bazamagaza/?_=BestOf&brand=Yamaha, а при нажатии на товар - показывать его цену (поле price), скажем, в теге <h1>, и описание в теге <p>, а если описания нет - то так и писать: "описания нет"

jooher

При апдейте статусов (обычно это происходит по user event), происходит автоматическое каскадное обновление нодов...

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

Если первой строкой на сайте будет "ФУНКЦИОНАЛЬНЫЙ ЯЗЫК ДЛЯ ВЕБ" -- то это сразу объясняет в целом, что это. Люди заинтересуются и им уже можно скармливать более длинные доки.

В ядре реализован базовый функционал для работы с внешними XML-данными, легко расширяемый при необходимости.

То есть можно запросить внешний REST или SOAP-сервис? Как насчет JSON?

Простенький пример

Ыыы. Вызывает затруднение невозможность использования предыдущего опыта. То есть без твоих комментариев даже предположить, что этот код делает -- нереально. Нельзя какие-то aliases для операций ввести? Типа,

И почему в u="brand$" после brand, а в объявлении -- до?

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