Yes very much MVC style separation of concerns. I didn't want to
reinvent the wheel with how my view
implementation is done and being new to the front-side of things, I
wasn't sure which direction to take, but
certainly one that would entail the least amount of duplication of
code and as much separation between the layers as feasible.
One of the most frustrating aspects of this discovery and working with
javascript is the abundant amount of advice
and sample code that doesn't have much back bone for good programming
practices. So while I certainly accept a
pragmatist's approach to solving a problem, I also would prefer to
have some sort of base pattern or mechanism so
I don't have to write a redundant but slightly variant code to render
the data.. Plus, I figured that many others
before me would have had to deal with this problem.
I've perused through few AJAX books as well and maybe I haven't looked
at the right book or correct section, but I didn't
notice anything that would be of help for this scenario.
Is there one that's recommended above others?
Justin
On Sep 11, 3:55 pm, "T.J. Crowder" <[EMAIL PROTECTED]> wrote:
> Hi Justin,
>
> If you're thinking MVC, off-the-cuff I'd say think of the client-side
> script as the Controller, the HTML as the View(s), and the server-side
> stuff as the Model. So an Ajax request is a message from the
> Controller to the Model. The data coming back knows nothing about the
> Views; the Controller (the JavaScript on the page) is responsible for
> taking the data and updating the Views, which are the various HTML
> elements involved in the UI. So in an MVC app, it's probably not
> appropriate for the JSON to specify the HTML element that gets updated
> with it; instead, it's up to the JavaScript code on the page to handle
> that association. (Although that depends; if the ID on the element is
> data-derived, it could easily come from the model.)
>
> But that's just one interpretation. The server-side stuff could be
> doing more of the heavy-lifting, so what you're seeing from the client
> end of things is mostly View implementation with a bit of Controller
> thrown in, with the rest on the server out of your immediate sight. A
> lot of MVC involves blurring of the boundaries.
>
> When you say "Most of the code samples [you've] seen...", remember
> that most of the code you've seen is either sample code, or code
> written "pragmatically" (whatever that's supposed to mean this week),
> or code written by juniors who wouldn't know MVCs from ABCs (e.g.,
> alphabetti spaeghetti, or "Spaghettios" for our American friends).
>
> Or, of course, people could be using a different model entirely, MVC
> not being the only game in town (although it's a pretty good one).
>
> Rambling my way to my point, it's up to you. It's up to how you
> structure the data exchange between the client and server, how you set
> up your pages, and how you write your script. If you want to do
> strict separation of concerns , there's no reason you can't, and in
> fact the nature of the beast makes it a bit easier to think that
> through.
>
> (The Template class can certainly help with your View implementation.)
>
> FWIW,
> --
> T.J. Crowder
> tj / crowder software / com
>
> On Sep 11, 8:25 pm, Justin <[EMAIL PROTECTED]> wrote:
>
> > Hi folks,
> > I'm not an expert on front-end development and if this is the wrong
> > group to post, please point me in the correct direction.
>
> > I'm looking at ways to separate the HTML layout of a page in
> > javascript from JSON data that I receive from the server. What are the
> > ways to render the JSON on the client?
>
> > Most of the code samples I've seen involve displaying the received
> > JSON seem to have an intimate knowledge of how the html is laid out
> > and which elements and types used to display the data. Typically what
> > I see is something similar to:
>
> > function makeHttpRequest()
> > {
> > httpRequest.open("GET", url, true)
> > httpRequest.onreadystatechange = updatePage;
> > httpRequest.send();
>
> > }
>
> > function updatePage() {
> > if (xmlHttp.readyState == 4) {
> > eval("var response = ("+request.responseText+")");
>
> > for(var i in response.data.row.items)
> > {
> > document.getElementById("body").innerHTML += "<div
> > id='icon'><img src='"+response.data.row.items[i].icon +"'/></div>";
>
> > for(var j in response.data.row.items[i].item)
> > {
> > document.getElementById("body").innerHTML += "<div
> > id='item'
> > onclick=\""+ response.data.row.items[i].action +"\">"+
> > response.data.row.items[i].item[j] +"</div>";
> > }
> > }
> > }
>
> > }
>
> > Assuming that our view consists simple HTML with separate javascript &
> > CSS files, this approach seems to intrinsically cause coupling of the
> > markup with javascript. Following this approach, every section of a
> > page that needs to fetch data from the server would have a different
> > 'updatePage' to handle the response. In addition, if the layout of the
> > page changed from a 'div' to some other type of tag, you have to
> > remember to go and modify the javascript.
>
> > I've read about the 'Template' object under prototype and I suppose
> > one thing you could do is have the server send back template string
> > and with the id of the element to update along with rest of the JSON
> > data and then use it after deserializing the data.
>
> > Is there a better way to achieve this separation using prototype/
> > scriptaculous?
>
> > Thanks,
> > Justin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
