NYCPHP Meetup

[Hans Zaunere]

> > So I think I see what you're saying.  Keep all markup (aside from
> > perhaps the initial request) off the server.
> >
> > I thought about this, and played around with it a bit.  There are a
> > couple of problems, or at least contradictions...
> >
> > -- everyone I talk to says do as much as you can on the server
> >
> > -- and with good reason, since complex JS is just a hack after another
> >
> > -- if I do only receive raw "bare-metal" data points via JSON from
> > the server, it seems that the JS complexity gets astronomic, which has
> > obvious problems and frankly greatly reduces overall application
> > agility in my opinion (ie, markup structure, visual appearance, and
> > application logic are once again lumped together).
> >
> 
> It's just another type of file. You can have the front-end request the
> template, and then the data if you like. You could even send the
> template with the data, although that seems icky to me.
> 
> Point is, there's as little reason to mix your template js with your
> logic js or framework as there is to mix template php with action php.
> But yes, your application has expanded. You now have one model, but
> two view/controller sets.

Yeah definitely there's no problem with various types of output contexts as Jake pointed out.  We've been doing this for a while - XML for web services, HTML for web sites, CSV sometimes, etc.

But what would a template for this look like?  What I'm having trouble streamlining is what those actual templates look like.  They're not outputting dynamically generated text anymore, per se.  They're outputting low level data structures (like an array) which classic templating doesn't seem to jive with.

The quick correlation to existing template methodology, in my opinion, would be to build the JSON "markup" directly, just like we've done for HTML/XML, using presentation logic and the template engine.  For example something roughly like this:

["
<?php foreach( $Messages as $M ): ?>
{\"MessageGID\":\"<?=$M->MessageGID?>\",
\"LRGID\":\"<?=$M->LRGID?>\",
\"AccountGID\":\"<?=$M->AccountGID?>\",
\"Status\":<?=$M->Status?>},
\"mi_\":\"<img src=\\\"<?=$M->ImgSrc?>" \\\/>\"
<?php endforeach; ?>
"]

Where $Messages/$M are adapted object that correctly escapes/formats things for the JSON syntax - just like they've done for HTML.  But obviously this negates the need for json_encode().  Is this what people are doing?

Say it ain't so...

> > Seems as though it's 2003 again...
> >
> 
> Yes, but with closures. :-)

Yah - say it ain't so :)

H