NYCPHP Meetup

[Jake McGraw]

On Wed, Jul 15, 2009 at 11:52 AM, Hans Zaunere<lists at zaunere.com> wrote:
>> I've had great success using Zend Framework ContextSwitch Action
>> Helper:
>>
>> http://woo.ly/9it
>>
>> It is a plugin for the Zend MVC system that detects what format you're
>> requesting a page in, using explicitly set context (format) in the
>> page request:
>>
>> http://myzendapp.com/module/controller/action?format=json
>> (?format=json sets the context to JSON encoding)
>>
>> or automatically detecting the context based on the request type. For
>> example, many JavaScript frameworks submit a special header to
>> differentiate an AJAX request from a standard HTTP request. The
>> ContextSwitch (in this case the AjaxContext) will detect this and
>> seamlessly deliver JSON. Other useful features include disabling
>> layouts, automatically encoding output to JSON and rerouting request
>> based on context type.
>>
>> Granted you'll have to work with Zend MVC, so this isn't a general
>> solution to the problem, but perhaps you can glean some theory of
>> operation from the way that they have set it up.
>
> Hi Jake, thanks for the info.  The context switching I can manage pretty
> easily, but it's the actual rendering and output of the data in the format
> needed for JSON.
>
> I don't see any examples from the above links on how the template/data
> output is actually handled - have you seen any examples of this?
>

See: http://jakemcgraw.com/php/zend/ContextSwitchExample.html

There are four actions, three of which will switch into Ajax mode if
the request originated from XHR:

The "view" action will disable the layout and render the
"comment/view.ajax.phtml" template if requested via Ajax.

The "form" action will disable the layout and render the
"comment/form.ajax.phtml" template if requested via Ajax.

The "process" action will disable the layout and view rendering, and
dump a JSON encoding of the "$this->view" member if requested via
Ajax. It also sends an updated Content-type header.

Finally, the "index" action will use the layout and render the
"comment/index.phtml" template regardless of being requested via a
normal request or XHR.

So, ContextSwitch not only directs request to the correct action, but
also points to the correct template (or for JSON, simply dumps the
variables).

Hope that helps!

- jake

> H
>
>
>> On Wed, Jul 15, 2009 at 10:31 AM, Hans Zaunere<lists at zaunere.com>
>> wrote:
>> > Hello,
>> >
>> > As I work with and need to support JSON applications more and more, I
>> > quickly remember why the mantra "don't use javascript" from
>> yesteryear was
>> > in place.  Worse, perhaps, is how the browser and server need to
>> interface
>> > with each other in complex JSON based applications.
>> >
>> > We're all familiar with the typical MVC pattern, and the use of
>> templates to
>> > organize and manipulate fragments of HTML/etc.  This is a very well
>> solved
>> > problem that's been established for years.
>> >
>> > Web 2.0, if you will, is "fragment" requests/responses.  I think of
>> this as
>> > the basic Ajax type of website, whereby the server is now sending
>> back these
>> > fragments of HTML rather than assembling them into complete documents
>> and
>> > sending that back.  The Javascript on the browser actually assembles
>> and
>> > moves things around as needed on the client side.
>> >
>> > Web 3.0 (insert kitsch marketing term here), I've found as being the
>> > complete manipulation, in real time, of nearly the entire document.
>>  Vast
>> > chunks of the document are living and breathing, and being effected
>> by
>> > events, timers, user interaction, server polling, etc.
>> >
>> > In order to the support this, a high degree of granularity for
>> dealing with
>> > HTML tags and IDs is needed.  Using fragments as we did in Web 2.0
>> doesn't
>> > provide this level of granularity so pure JSON is required.  What
>> this means
>> > (to me) basically is that tag content itself or even elemental HTML
>> > fragments (very small chunks, like single p, h1, img, etc) need to be
>> > manipulated both on the server and browser side.
>> >
>> > The problem with this, however, is that it causes the server-side to
>> retrace
>> > to the ugly days of mixing and mashing PHP/HTML/etc.  For example, to
>> push
>> > out a set of IDs to the client, I no longer use a template to spit
>> back a
>> > fragment.  Rather, I put tags and data into an array directly, and
>> then
>> > json_encode() that, and send that back to the client.
>> >
>> > For example, a dynamic forum type of thing:
>> >
>> > $JSON['ID']["mi_$GID"] = "<img src=\"{$Page-
>> >ImagesURL}lr/icon_phone.png\"
>> > />";
>> >
>> > $JSON['ID']["bl_$GID"] = "{$M->BylineDate} | <b>{$M->FirstName}
>> > {$M->LastName}</b>";
>> >
>> > $JSON['ID']["rcb_$GID"] = $M->ReplyCount;
>> >
>> > $JSON['ID']["hc_$GID"] = $M->Title;
>> >
>> > echo json_encode($JSON['ID']);
>> >
>> >
>> > The Javascript then takes each element from the array and manipulates
>> the
>> > DOM as appropriate.  Why not just stuff things in innerHTML you may
>> ask?
>> > Because that's not granular enough, and should the user be
>> interactive with
>> > that particular element, the user has just lost his current state.
>> >
>> > So hopefully others have run into these types of issues and I'm
>> curious as
>> > to how others deal with it.  Thoughts, experiences, etc?  I've
>> thought about
>> > how to use some type of elemental templating, but there doesn't
>> appear to be
>> > anything that's a fit for this type of thing.  And no easy way I can
>> think
>> > of for building something to handle this.
>> >
>> > Or, perhaps I'm completely missing some elementary concept that makes
>> all
>> > this moot...?
>> >
>> > Looking forward to everyone's thoughts.
>> >
>> > H
>> >
>> >
>> > _______________________________________________
>> > New York PHP User Group Community Talk Mailing List
>> > http://lists.nyphp.org/mailman/listinfo/talk
>> >
>> > http://www.nyphp.org/show_participation.php
>> >
>> _______________________________________________
>> New York PHP User Group Community Talk Mailing List
>> http://lists.nyphp.org/mailman/listinfo/talk
>>
>> http://www.nyphp.org/show_participation.php
>
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show_participation.php
>