<br><br><div class="gmail_quote">14 апреля 2009 г. 13:03 пользователь Pavel Wolneykien <span dir="ltr"><<a href="mailto:manowar@altlinux.org">manowar@altlinux.org</a>></span> написал:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
Stanislav Ievlev <<a href="mailto:stanislav.ievlev@gmail.com">stanislav.ievlev@gmail.com</a>> wrote:<br>
<br>
><br>
><br>
> После прочитывания показалось, что metaalterator не должен быть бакендом, собственно это и не бакенд - это моделирование данных. Есть<br>
> определённый смысл оформить его как библиотеку guile.<br>
<br>
</div> Почему не бакенд? БД традиционно называют бакендом, а я его начинал<br>
писать как маленькую БД. :))<br>
<div class="im"><br>
> Вообще задача моделирования очень сложная - мы кажется уже делали два или три захода - ничего путного не получилось. Очень хочется чтобы<br>
> metaalterator стал-таки средством моделирования в alterator ;)<br>
<br>
</div> А что за заходы? Можно ткнуть носом?.. :)</blockquote><div>Боюсь что сейчас ткнуть можно только в историю tla/git ;)<br><br>Первая модель была отдельным слоем между бакендом и интерфейсом. Эта прослойка могла из одного высокоуровневого запроса делать несколько низкоуровневых запросов и объединять несколько низкоуровневых ответов в один высокоуровневый. Но работало это всё в теории. На практике соорудить сферического коня с приемлемой скоростью работы и функционалом не получилось.<br>
<br> Остатки можно поглядеть на ftp в Compact 3.0 ... по-моему там так и называлось оно - model.<br><br>Вторая попытка - это "бакенды над бакендами", идея та же. В сочетании с constraints можно найти в 4.0 ... кажется таким был users. Там на высоком уровне пользователь добавлялся, а на низком пахали два отдельных бакенда - один для пользователей и второй для групп. Идея провалилась прежде всего из-за того что отлаживать такие бакенды было практически невозможно - не очень удачное на тот момент (да и сейчас) устройство alterator было. Да и вообще не очень удобно было работать.<br>
<br>"constraints" тоже можно считать частью этой попытки. Идея была из некоторого описания параметров бакенда автоматом получать подходящее поведение в интерфейсе. Провалилось из-за того что автомата как всегда не хватало - я много получил мата от разработчиков модулей ;)<br>
Потом "constraints" распались на "эффекты" и "типы". Последние живы и процветают, первые в общем-то не очень нужны ибо есть ajax на схеме ;)<br><br><br></div></div>