Questions on JavaScriptMVC

[peter]

Hi everybody,
J've just stumbled on JavaScript MVC. I think it's great!
It is no simple feat to build a MVC framework that really integrates
AJAX.
Is there some page that can illustrate the BIG picture about
JavaScriptMVC?

Some thing in the lines of these urls:
http://glyphobet.net/blog/essay/153
or
http://www.phpied.com/ajax-mvc/
showing how the MVC maps into JavaScriptMVC structures, methods, etc.

Thanks and keep up the good work!

[Daff]

Hi.

I just scanned through the articles but let me try to explain my JSMVC
MVC idea / impression:
Ajax applications break the old Request page / Respond complete HTML
page and the established server side MVC Frameworks (Struts, CakePHP,
RoR and so on) methods may lead to an ugly "replace some html parts
somehow with other html" approach.
Since Ajax needs by definition JavaScript I came to the conclusion
that there is no way around coding JS. There are several approaches
like Google Web Toolkit, XAjax, Echo or RoR (correct me if I'm wrong I
never really used it) but they just compile / translate from the
server side language to JS which means that you're most likely not
able to use all possibilities offered by JavaScript.

I just started with JS about two months ago but the first problem I
encountered was that it can - like PHP - become very chaotic spaghetti
code (you can do amazing things with all the thousands of libraries
and frameworks but none offered a - for me - convincing way to
structure your source) so JSMVC was the best thing to get started.

Unfortunately the Model of JSMVC only offers interaction with REST
webservices and as far as I know RoR has the only native RESTful
implementation so
JavaScript MVC is currently more an MVC without model for me (i had to
do my model stuff in the controller) but the Ajax approach is already
quite nice (see http://javascriptmvc.com/learningcenter/ajax/api.html).
In my current project model data is offered by Java via the Direct Web
Remoting Framework (http://getahead.org/dwr/) but the basic idea is
quite nice:
Your Server just offers the model data in any form (e.g. XML or JSON)
you request it in your Controller via Ajax and render it to a view
with JSMVC (all done on the client side). The huge benefit is, that
other servers / sites or clients can easily request and process this
data (and only the data) as well so we have already an up and running
Webservice (think of mashups and web interoperability in general...
why create some strange and extensive APIs when your application
offers one by design?). As mentioned I'm curently using DWR but I'm
also thinking about using JSMVC in my CakePHP Projects, too. Depending
on the content type requested it can e.g. either send its model data
as a JSON object, render the same data as XML or just spit it out as
HTML (hm think XHTML + CSS would be better). Using JSMVC the JSON
object can be directly rendered to a view. Or let a desktop
application request the same data and do something else...

That is in my opinion the most important part of the big picture
(besides helping you to structure and organize your code in a clean
manner).
I think that Model 2.0 (http://javascriptmvc.com/blog/?p=29) is the
most important next step for JSMVC so that you can have real MVC
separation with webservices other than REST based ones.

Regards
Daff

On 4 Jun., 10:30, peter <peter.chan...@gmail.com> wrote:
> Hi everybody,
> J've just stumbled on JavaScript MVC. I think it's great!
> It is no simple feat to build a MVC framework that really integrates
> AJAX.
> Is there some page that can illustrate the BIG picture about
> JavaScriptMVC?
>
> Some thing in the lines of these urls:http://glyphobet.net/blog/essay/153

> orhttp://www.phpied.com/ajax-mvc/

[Justin Meyer]

That is a very good explanation.

Yes, JavaScriptMVC is designed to support what is (in my mind)  the next generation of application architecture.  It's something called Thin Server Architecture.

It's based around the idea that services will be everywhere, and applications will coordinate between them - mashups.  This is what people are saying will be web 3.0 (but I hate that term).

The advantages of this model:

• It forces the creation of reusable service
• Applications are just HTML + JS + CSS, so they:
• are easy to host
• separate the graphical interface from the service, which makes services more stable.  For example, if something in the interface breaks, it doesn't break on the server, it only breaks for that one user.
• separate the graphical interface from the service, which make it easier for Front-end developers to focus on their part and back-end / server developers to focus on that part.
  
• Performance benefits because all interface logic runs in thousands of web-browsers instead of 1 server.  This exploits parallelism.

We don't have a picture that illustrates how to develop JavaScriptMVC.  That would be a good addition to the learning center (http://javascriptmvc.com/learningcenter/index.html).  But Daff's explanation is correct:

Model - Wraps Ajax Requests

Task.find('all')

View - Displays html

<% for(var i=0; i < tasks.length; i++){ %>
       <p><%= tasks[i].name %></p>
<% } %>

Controller - responds to events

onclick : function(params){
    this.tasks = Task.find('all');
    this.render({to: 'tasks'})
}

****** This is showing synchronous loading of a list of tasks, for asynchronous and a better user experience, you would do something more like:

onclick : function(params){
    Task.find('all',{limit: 20}, this.continue_to('list'));
    this.render({text: "Loading ...", to: "tasks"});
},
list: function(tasks){
    this.tasks = tasks;
    this.render({to: 'tasks'});
}

Daff, I'm working on the new Model right now.  Would you like to take a crack at this diagram?  We'll add it to the learning center and you to the contributors.

--
Justin Meyer

Jupiter IT Solutions
847-924-6039
justin...@gmail.com
AOL: jusbarmey

[Daff]

Hi Justin.

Well yes of course :) Thought about blogging something like that
myself.
What where you thinking about? Some pictures, source examples (you
seem to be one of the RoR guys but maybe people need examples in
another server side language (esp. PHP, Java and hm ok... Perl), too
to get an idea about how it works), descriptions?
How is work with new Model going on (don't want to press I am just
excited about the new possibilities :)?

I've heard the term Web 3.0 (since mashups and all that APIs belong to
the "Web 2.0") mostly in connection with the semantic web idea but
thinking about it the Thin Server architecture does exactly that...
making data in the web machine accessible and processible.

Regards
Daff

On 4 Jun., 19:50, "Justin Meyer" <justinbme...@gmail.com> wrote:
> That is a very good explanation.
>
> Yes, JavaScriptMVC is designed to support what is (in my mind) the next
> generation of application architecture. It's something called Thin Server
> Architecture.
>
> It's based around the idea that services will be everywhere, and
> applications will coordinate between them - mashups. This is what people
> are saying will be web 3.0 (but I hate that term).
>
> The advantages of this model:
>

> - It forces the creation of reusable service
> - Applications are just HTML + JS + CSS, so they:
> - are easy to host
> - separate the graphical interface from the service, which makes

> services more stable. For example, if something in the
> interface breaks, it
> doesn't break on the server, it only breaks for that one user.

> - separate the graphical interface from the service, which make it

> easier for Front-end developers to focus on their part and
> back-end / server
> developers to focus on that part.

> - Performance benefits because all interface logic runs in thousands

> > quite nice (seehttp://javascriptmvc.com/learningcenter/ajax/api.html).

> justinbme...@gmail.com
> AOL: jusbarmey

[Justin Meyer]

In my opinion, ajax and social applications were web 2.0.  Mashups are a feasible version of the semantic web.  It's really hard to have mashups be 2.0 when there really isn't an important mashup application, compared to thinks like GoogleMaps+Wikipedia+Facebook+etc.

To be honest, I'm struggling with the new Model.  I've got something working, but I don't like it.  Here's how it works right now:

The basic model provides a simple active record type structure that inheriting classes need to fill in.  Functions like:

.find and .save

call find_one, find_many, create, and update which are provided by the inheriting class.

Validations and other functionality will be able to plugin to anything inheriting from base model class.

I currently have at least partial functionality working for:

• AjaxModel
• CookieModel
• RemoteModel
• RestModel

More will eventually be filled in.

We're looking for a way to standardize ways of retrieving and editing information.  This makes thinks like scaffolds eventually  possible.  A goal for JavaScriptMVC 2.0 is for someone to write a model and controller and have a working application.  For example:


Todo = MVC.RestModel.extend('todos')

and

TodosController = MVC.Controller.extend('todos', { scaffold: 'todo' }, {} )

This should result in an grid allowing the user to create, modify, and delete todos.



Why don't I like it?  I feel like it's a stretch to wrestle all data into a CRUD model.  And, the inheriting classes aren't easy to extend.  I'm betting I write it once, learn from it, and do it again.

justin...@gmail.com
AOL: jusbarmey

[peter]

Hi Justin and Daff,

I guess there is no other reply to my initial question. I am still
trying to get the big picture of JavascriptMVC's MVC model.

OK, the standard MVC model applies very well to Web 1.0. Requests from
the user goes to the controller, which sends requests to the model
module, and finally induces the view module to produce a new view. I
suppose JavascriptMVC can do that well.

When AJAX and Web 2.0 is added to the picture, the standard MVC model
needs to be updated. Some authors suggest that there is a partial
model in the client post (so as to produce fast results without making
a round trip to the server). And of course the partial model needs to
be synchronized with the full model residing on the server (for
persistence purposes).

The following online doc. explains it well (but I can't find its
official reference):
www.sistedes.es/sistedes/pdf/2007/SCHA-07-Morales-MVC.pdf

Even the book "Ajax In Action" talks about different interaction
models such as content-centric, script-centric, or data-centric.

Aside from philosophic considerations: some concrete questions you
might answer:

1) what does JavascriptMVC do to support coders implementing a MVC
application based on Ajax - in the way of organising browser client
code and server code ?

2) Do you have an example showing how to get data residing in a DB or
a server-side file?
Example the 'todo' class might save its data to a file and retrieve it
when it restarts.
Things start to be "serious" when this data is shared by several users
(e.g. company agenda),
but that's when you start to see a model module in the client and in
the server.

It would be interesting to see some server code (my favorite is PHP,
as with many thousands of coders).

[Daff]

Hi Peter.

Where do you get all the papers from ;) Looks interesting, I'll to
read it completely through, soon.
But... an important thing is that AJAX itself is not the revolutionary
approach it is hyped to be.
In fact the idea of sending and processing http requests
asynchronously with JavaScript is incredibly trivial.
But this tiny simple asynchronous request was what made JavaScript
socially acceptable in the browser world
(it used to be a dirty and unsecure scripting language which you
better turn off, before).
Lots of frameworks popped up offering a lot of eye candy and language
beautifiers around the asynchronous
request object and JavaScript in general and everything was wrapped in
the fancy term AJAX and well...
that's what some people call the revolution. I read a nice Article on
Ajaxian yesterday,
that "Ajax was one of the most successful rebrandings in software
history"
http://ajaxian.com/archives/javascript-rebranded-check.

Well.. in a revolution, philosophers are needed, of course,
but what finally makes a revolution are the people walking the
streets.
That is why I'm so happy about all the rapid internet application
developers in general and
Brians and Justins work in particular because they simply write code
before writing an abstract paper
(maybe some kind of philosophers walking the street ;).
I think you are at the moment very free to use the AJAX technology and
frameworks as it's most suitable for your needs (just replace some
HTML,
do some eye candy on your page, don't use ist at all or use it with
JSMVC). There aren't really established best AJAX practises yet so you
can choose freely
and you shouldn't use a framework, technology or design pattern if it
doesn't make sense to you or seems to complicated (the most important
thing in RIAD for me is to keep it as damn SIMPLE as possible).

But I think what you - like me, too - are missing on the JSMVC
documentation are examples for a server side part other than ruby.
I still want to write a tutorial about this and maybe a little
framework implementing the idea, but I don't have
time for it at the moment.
So let me just give you a very quick (and dirty ;) example (which
probably won't instantly work but I hope you get the idea):

Server side (load.php):

<?php
// Here some data in an array (may come from the database, too)
$test = array("test" => "Hello", "thing" => "World");
echo json_encode($test);
// Will print something like
// { test : Hello, thing: World }
// which can be evaluated directly as a JavaScript object
?>

JSMVC:

Controller('todos',
{
"a click" : function(params)
{
this.element = params.element;
this.element.innerHTML = 'Loading...';
new Ajax.Request('load.php', {onComplete: this.continue_to('load')}
},

load : function(response)
{
// NEVER EVER do this in production ;)
// Use something like Prototypes
response.responseText.evalJSON();
this.data = eval(response.responseText);
this.render( { to: this.element });
}
});

views/todos/load.ejs

Test: <%= data.test %> <br />
Thing: <%= data.thing %><br />


I think it is now obvious what is meant with "Thin Server
Architecture".
Just two lines of PHP code offer the data you need, everything else is
done on the client side
(that is the important thing I wanted to point out).
I'm still working on a more detailed (and working ;) example. But I
hope you get a better idea now.

Daff

[Justin Meyer]

Special delivery!

http://javascriptmvc.com/blog/?p=68

Let me know if that explains how everything is working.

[Justin Meyer]

For all those non-rails people out there. Just replace the RHS of
that image with your own service, and the JavaScriptMVC model with
your own model. Controller and Views are still very useful.

[peter]

Justin,

Your blog
http://javascriptmvc.com/blog/?p=68
is certainly very instructive.

To summarize (reusing the titles used in the paper by Morales, see
ref. above:
http://www.sistedes.es/sistedes/pdf/2007/SCHA-07-Morales-MVC.pdf)

1° "Server-side MVC" is provided by frameworks such as phpmvc, ROR,
etc.

2° A simple implementation using JavascriptMVC and PHP, such as that
suggested by Daff, is "RIA MVC". Server side data is obtained by Ajax
requests. Of course javascript runs only on the client (except for
Rhino etc.).

3° Your own schema with a server MVC is the so-called "Mixed client-
side and server-side MVC(2)" model.
- The names of similar objects on both sides must match (e.g.
"tasks"). This danger can be reduced with code generators
(JavascriptMVC2.0 ?)

Questions:
a) Do we have to produce specific codes for the MVC system on each
(client/server) side or will the generators take care of that (in due
time...) ?

b) How flexible will it be :
- Can we choose phpMVC instead of ROR ? I don't have any experience
with ROR. Maybe ROR already caters for the situation 3°. I suppose the
big dilema for you is what language to build the code generators...
- Can we choose sockets instead of Ajax ? because Ajax is limited
within the same domain.

c) What do you think of the "RIA Deeper MVC" model suggested in
Morales' paper ?
- OK, I think the titles can be improved ... but that is not the
point :-)


Daff,

> > > Where do you get all the papers from ;) Looks interesting

Just Google it and be patient to look through at least 100
references ;-).

I hope you don't mind philosophying about application architectures.
To me, that is the main reason for using such complicated codes and
structures.
*** You have to provide the motivation ***
because the effort to learn to use such architectures seems so time-
consuming before it gets to produce results.

Personally, I've coded a "sphagetti" Ajax proto-type and I think it is
very difficult to debug and maintain ...

[Daff]

Peter.

You are certainly right. I personally really like philosohpying about
application architectures at least as much as I like to implement
them.
You are right that learning the concepts is often very time consuming,
too. I learned, that you have always have to prototype some frameworks
and technologies or your own architecture sooner or later to get a
real feeling for it. And if it doesn't make sense after that you're
probably on the wrong way (my favourite example for that is the Struts
MVC framework in Java... it takes really time to get into it and after
working some time with it I still don't see what advantages it offers
to me and I would never use it myself regarding all the much funnier,
easier and more up to date web frameworks).

I still want to write a small RIAD framework combining PHP as the
Server backend and JavaScript MVC as the Frontend.
Would you like to join me in this task? I guess that an established
PHP MVC framework has too much overhead (things you really don't need)
for this kind of architecture.
All you need is an Object Relational Database mapper (I really like
this things... maybe because I'm not such an SQL fan ;) and some kind
of simple php controller for retrieving, mapping and preprocessing
(respectively postprocessing e.g. from forms) all the data and output
it in an exchange format (I prefer JSON but it couls be also XML... or
HTML even if it's not necessary). I don't know how the work with the
Model 2.0 is going on because I haven't had the time to checkout the
trunk but as far as I understood the new model should be able to
process these data or ther is the possibility to implement an extended
model.

a) / b) I don't think that there will be server side language code
generators because JavaScript MVC is and should be completely client
side (it's one of the most important features of JSMVC that it doesn't
depend on any specific server technology).
Sockets instead of AJAX? Hm. I think thats on step ahead because
- JavaScript doesn't support sokets as far as I know
- You would have to implement your own RPC protocoll, probably on a
different port, which nullifies all the current advantages of
interoperability and independency
The same domain issue could e.g. be solved with an AJAX proxy on the
server side so that data from different domains seem to come from the
same one.

Oh and maybe you want to read this
http://sofea.googlegroups.com/web/Life%20above%20the%20Service%20Tier%20v1_1.pdf

Daff

On Jul 10, 11:13 am, peter <peter.chan...@gmail.com> wrote:
> Justin,
>
> Your bloghttp://javascriptmvc.com/blog/?p=68

[peter]

There are way ***too many*** PHP-MVC frameworks, see (french text with
links to home sites)
http://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP

In the JavascriptMVC "Model" documentation, there's some talk about
REST and Jester.
I tried to follow up on these subjects, but there are lots of
references and I didn't end up wiser.

A simple/short example of interface with PHP would be beneficial to
JavascriptMVC beginners.
It will have to respect the MVC principles, like having a centralized
place for the scripts, etc.

How can I help ?

[Justin Meyer]

Peter,
I haven't used PHP since college, so I'm not the person to show you
how to make a REST interface in php. However, I'll give you the ins
and outs for an example XML Recipe resource.

Recipe.find('all') -> GET recipes.xml RETURNS:

<?xml version="1.0" encoding="UTF-8"?>
<recipes>
<recipe>
<id type="integer">48</id>
<instructions>Call Mom!
Bring chicken.</instructions>
<title>Chicken Soup</title>
</recipe>
</recipes>

Recipe.create({title: 'Toast', instructions: 'heat bread'}) ->

POST: recipes.xml POST DATA =
recipe[title]=Toast&recipe[instructions]=Heat%20Bread

RETURNS:
STATUS: 201
RESPONSE_HEADER: LOCATION = http://yourdomain.com/recipes/50
RESPONSE: ""


Recipe.find(50) ->

GET: recipes/50.xml
RETURNS:
<?xml version="1.0" encoding="UTF-8"?>
<recipe>
<id type="integer">50</id>
<instructions>Call Mom!
Bring chicken.</instructions>
<title>Chicken Soup</title>
</recipe>

Recipe.update(50, {title: 'gum', instructions: 'chew'}); ->

PUT: recipes/50.xml
~! This is simulated as a post, a _method=put is added to the post
data
POST DATA = recipe[title]=gum&recipe[instructions]=chew&method=_put

RETURNS:
STATUS: 201
RESPONSE_HEADER: LOCATION = http://yourdomain.com/recipes/50
RESPONSE: ""

recipe.destroy() ->

DELETE: recipes/50.xml
~! This is simulated as a post, a _method=delete is added to the post
data
POST DATA = method=_delete
RETURNS:
STATUS: 200
RESPONSE: ""


Does this help?
One thing is that rails breaks convention by naming resources with
their extension (recipes.xml or recipes.json). Other people set the
Accept Request header (application/xml or application/json).

On Jul 10, 9:07 am, peter <peter.chan...@gmail.com> wrote:
> There are way ***too many*** PHP-MVC frameworks, see (french text with

> links to home sites)http://fr.wikipedia.org/wiki/Liste_de_frameworks_PHP

[Daff]

Hi Justin.

I guess you are right. A REST interface will make most sense.
I want to try out this:
http://phprestsql.sourceforge.net/
Looks promising and simple to change (the first thing I want to do is
include an object relational mapper ;)

Regards
Daff

On Jul 10, 5:34 pm, Justin Meyer <JustinBMe...@gmail.com> wrote:
> Peter,
>   I haven't used PHP since college, so I'm not the person to show you
> how to make a REST interface in php.  However, I'll give you the ins
> and outs for an example XML Recipe resource.
>
> Recipe.find('all') -> GET recipes.xml RETURNS:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <recipes>
>   <recipe>
>     <id type="integer">48</id>
>     <instructions>Call Mom!
> Bring chicken.</instructions>
>     <title>Chicken Soup</title>
>   </recipe>
> </recipes>
>
> Recipe.create({title: 'Toast', instructions: 'heat bread'}) ->
>
> POST: recipes.xml   POST DATA =
> recipe[title]=Toast&recipe[instructions]=Heat%20Bread
>
> RETURNS:
>   STATUS: 201

>   RESPONSE_HEADER:  LOCATION =http://yourdomain.com/recipes/50

>   RESPONSE: ""
>
> Recipe.find(50) ->
>
> GET: recipes/50.xml
> RETURNS:
> <?xml version="1.0" encoding="UTF-8"?>
> <recipe>
>     <id type="integer">50</id>
>     <instructions>Call Mom!
> Bring chicken.</instructions>
>     <title>Chicken Soup</title>
> </recipe>
>
> Recipe.update(50, {title: 'gum', instructions: 'chew'}); ->
>
> PUT: recipes/50.xml
> ~! This is simulated as a post, a _method=put is added to the post
> data
> POST DATA = recipe[title]=gum&recipe[instructions]=chew&method=_put
>
> RETURNS:
>   STATUS: 201

>   RESPONSE_HEADER:  LOCATION =http://yourdomain.com/recipes/50

[peter]

Justin,

Thanks it certainly helps!

Of the fundamental building blocks M+V+C, the M module is the least
documented in the learning center
(just "API", no "demo" or "learn" links). In fact there is a small
bugger on this page
http://javascriptmvc.com/learningcenter/model/index.html
on the install paragraph, the example says load the inflector plugin.

Cheers.