NYCPHP Meetup

NYPHP.org

[nycphp-talk] JSON and MVC

Hans Zaunere lists at zaunere.com
Wed Jul 15 11:52:06 EDT 2009


> 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?

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




More information about the talk mailing list