NYCPHP Meetup

[Anirudhsinh Zala]

On Wednesday 15 Jul 2009 8:01:14 pm Hans Zaunere 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...?

There are 2 possible solutions, if I have understood your problem correctly.

1st: If presentation logic and data both would be sent in certain format say 
JSON, then why not just to send whole rendered document in HTML to client and 
let DOM just display it. Why DOM has to bother about parsing those data and 
presentation logic 1st into JS and then displaying into browser?

You may ask that purposes are to minimize server parsing, save bandwidth or 
faster transmission. They are correct but then if data is of small amount then 
you can just send complete rendered HTML to client to just display it using 
Ajax as said above

2nd: But if there are large amount of data and/or JSON is must to use then 
XSLT type of technology is needed preloaded at client side where DOM would 
read that rendering information from there and read data from JSON and then 
display it in browser.

In short those XSLT/JSLT would be called as JS templates as said by Chris.

Thanks

Anirudh Zala

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