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

Вкратце, хотелось бы обсудить и разобрать методику построения, разбиения на модули и взаимодействия между ними и пользователем.
В чем существенные отличия между обычным и ajax-приложением.
Как организовать сохранение view-state для ajax-реализации. (в обычном все очевидно - передавать параметры состояния через url).

Добавлено через 2 минуты и 13 секунд

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

И загружалось бы непосредственно в 



Это как раз то, на чем я акцентировал внимание. Если у тебя приложение уже разбито на некоторые минимальные блоки, то для него нет разницы как работать в ajax-режиме или нет. Оно великолепно будет работать в обоих случаях.


Именно отдельный action/view
Просто твоя базовая страница - на самом деле представляет собой лишь агрегатор более мелких частей, таких как корзина, линия товара - не весь список, а именно линия 1го конкретного товара. Тогда и обновляться у тебя будет не весь список сообщений в gmail, 
а только конкретное письмо.

 
Кто нам мешает в этом html - прислать кусочек javascript?
Что-то вроде такого.

Я бы посоветовал углубиться в изучение jquery.

awers, обалденный совет не в тему 
jQuery и так пользуюсь 

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

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

я использую что то вроде

service->| Frontend |->| js
              | Backend        | php

если по архитектуре. в основном приложении есть Frontend loader (js+html), автоматическая инициализация загружаемого куска module_init .. 

про это? (что то вообще с мыслями собраться немогу)

awers, 
Вот смотри. Допустим у нас есть страница/каталог магазина. Накидаем на нее побольше ерунды, чтобы разбирать было интереснее
На которой
а) список товаров
б) лента каких-нибудь новостей
в) корзина
г) меню

Это если крупным планом 

Соответственно имеем к примеру 
action/catalog/ 
который рендерит один view. В который входит список и корзина. Новости и меню - у нас общие на весь сайт и за них допустим отвечает класс предок.

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

Добавлено через 2 минуты и 5 секунд
Да и упустил, работать варианты должны, как под AJAX, так и стандартно, без существенных архитектурных изменений.

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

awers,  пока это сферические кони в вакууме. 
Для конкретного магазина - проще новый написать, если изначально писал криво.

Но так сложилось, что есть системы с затратами труда более 5ти человеколет. И тут переписывать все заново - не самое лучшее решение.

Это сообщение отредактировал(а) Fortop - 11.5.2008, 16:49

Т.е. общесистемное сообщение показывается неизвестно где в блоке корзины...
Случаи когда мы можем показать просто полученный html еденичны. Намного ведь лучше если обновится блок корзины, а сообщение появится с какаим-то ярким оформлением под шапкой сайта и потом будет "затухать" вплоть до полного ищезновения. 


Пример в студию! Если я себе прекрастно представляю как может быть достпна корзина через front_controller, то отдельное сообщение... 
Да и смысл вопроса моего вы поняли не верно. Не важно что у вас уже есть сверстаный отдельно блок корзины. У вас запрос приходит на ОБНОВЛЕНИЕ корзины. И в него вам все равно прийдется внести изменения (разговор то был изначально о трудоемкоти добавлния ajax на сайт без оного). 
Если у вас просмотр части корзины оформлен как отдельный action (хотя я против такого подхода), то вам нужно добавить анализ "а не от xmlhttp ли у нас запрос пришел" и редирект на просмотр блока корзины, а не на Referer.
Если как некий компонент, подключаемый только из view, то прийдется добавить этот самый view и в нем подключать этот самый блок.


Браузеры мешают. Они его просто не выполнят )

Ну и в конце по уже новой теме )
Разници нет никакой. Есть просто некий объем дополнительной работы, коотрый приходится выпонять. А именно, добавлять альтернативное отображение. Я считаю, что за отображение данных должен отвечать JS на стороне клиента, а не отданный с сервера ответ. Именно потому не признаю обмен кусками html. 

box.phtml

list.phtml

Соответсвенно. 

Я специально упростил. Вообще тут должны быть еще имена контролеров и возможно параметры.


Доступ к отдельному сообщению



controller - box
view - in
params - line/1
Рендерим только     


Обработка списка, если он вызван как обычно



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

Сохранить на диске как a.html


Добавлено @ 13:50

Ок, мысль я понял.

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

Это сообщение отредактировал(а) Fortop - 12.5.2008, 13:51

Fortop, вот на приере строки сообщений. Ваш render -- обращение к модулю через контроллер, приравниваемый к обычному вызову?
->render('line'); выполняет какие-то запросы к базе или он принимает данные, которые рендерит параметрами?
Если он принимает данные параметрами, то откуда он их возимет при "http://site/app/box/in/line/1"?
Если выполняет запросы, то не много ли запросов на одну страницу (список из 50 сообщений это минимум 50 запросов)? 
Если "смотрит откуда его вызвали", то не черезмерное ли это усложенеие таких простых операций как рендеринг html?


Функционал реаизован при любом подходе ) Данные то у вас и так загрухались/изменялись ) Все остальное вам все так же прийдется делать. Все на том же замученном примере корзины. Было:

В моем варианте это превратиться в:

А с вашим подходом изменения по трудоемкости будут отличатся? На стороне js, да. На стороне сервера -- очень врядли.


Т.е. html, приходящий на вход все равно аназируется, разбивается на части, показывается в разных частях страници? Тогда вообще становится сомнительным обмен html-ем. Хотя вру, конечно, есть разница. При изменении верски какого-то блока нет необходимости вносить изменения в js.

Очень важные моменты 
Надо подумать.

Какие есть идеи?


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

Итак  поскольку свежих идей не появилось, то мусолим старые.



Ответ на все эти если. Получив вызов мы из имеющихся параметров строим условие фильтра и выполняем 1! запрос.
Если параметры есть, то взапрос нам отдаст line = 1
Если параметров нет - то запрос нам отдаст весь список.

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

Никаких 50 запросов не будет. Только если пользователь решит поочередно все 50 записей просмотреть в одиночном режиме. Но в этом случае обходных путей по-большому счету - нет.