JavaScriptMVC 1.5

[Justin Meyer]

Please excuse a quick plug for JavaScriptMVC. I wouldn't do this if I
didn't think a few of you would be interested, and JavaScriptMVC is
exactly for SOFEA applications.

As a few of you might know, I'm the core-est of core contributors for
JavaScriptMVC. We are getting very close to launching a beta of our
1.5 version. If you haven't done so you might want to check it out.
We're trying to address some of the biggest challenges that SOFEA in
the browser faces. And, I think we are doing it in a way that is
fundamentally better than other JavaScript libraries / frameworks
(Dojo can suck it Kris Zyp, jk).

My vision for JavaScriptMVC is to provide direction to JavaScript
developers. Like RoR, there is a specific way you do almost
everything and maintainability is paramount.

I made a video (http://javascriptmvc.com/screencasts/two_point_oh.htm)
that walks through creating a scaffolded Cookbook application much
like OnLamp's Rolling with Ruby on rails. It takes 6 lines of code!
It shows off many new 1.5 features including:

Code Generators
Scaffolding
Automatic Server-side Compression

And, a few of JavaScriptMVC's standard features include:

Model View Controller architecture
Automatic Testing and Test helpers

But, it didn't show JMVC's latest feature:

Automatic documentation generation


With JavaScriptMVC, I'm not focused on features. I'm focusing on
making it stupidly easy to do all the crap people normally have to do
to have a complex JavaScript application (organize, compress, test,
document). And, to make starting one as simple as possible (Code
Generators, Scaffolding).

Any feedback, ideas, suggestions, criticisms are greatly
appreciated.

[Peter Svensson]

:) Go, Justin! Personally, I'd prefer a world where all JS toolkits were interoperable. The scaffolding and generation stuff sounds really interesting. I'll check it out.
A defence for Dojo could be that it has a very strong hierarchicall widget system which, together with the smart loader kind of 'enforces' good behaviour which lead to portable and modularized apps. This is another issue entrely than developer-support, scaffolding et.c.

Cheers,
PS

[Justin Meyer]

I think talking about the methods of building SOFEA is a worthwhile
discussion for our group. I've always been very interested in how
other people organize their projects. Please share if you have any
good methods.

Dojo's widget system is spectacular in its scope, but I don't have
much experience w/ dojo (other than reading about it) since Dojo 0.9.
When using YUI, EXT, or Dojo, I often found myself stringing together
components in more or less a random fashion. Even worse, sometimes
the components don't do exactly what you want so you have to modify
them. This ends up with code being strewn around everywhere. Yes,
the individual components are reusable; but the overall application
structure is like week old spaghetti.

It's the same thing when I program Java vs RoR. My Jabbify (http://
jabbify.com) is half Jetty, half RoR. Without looking at the docs,
someone would have no idea where a piece of functionality is in the
Java code. This is in stark contrast to the RoR where someone would
instantly know where to look.

Are you able to avoid this problem with Dojo? What steps do you
take? Can you avoid making custom widgets w/ Dojo. Are you using
their templates?

On of JavaScriptMVC's biggest strengths is it's use of event delegated
controllers. It makes using client side template views more practical
as you don't have to go back into your generated HTML and attach event
handlers.


A few things about your prior message:

JavaScriptMVC, like jQuery, has a no_conflict mode where everything is
namespaced under MVC. Furthermore, if you use jQuery or Prototype, it
will replace it's own core with parts from those libraries - something
I am calling library interdependence.

JavaScriptMVC has no pre-packaged 'graphical' widgets. It's more
designed for building the widgets themselves from the ground up.

On Sep 25, 2:40 am, "Peter Svensson" <psvens...@gmail.com> wrote:
> :) Go, Justin! Personally, I'd prefer a world where all JS toolkits were
> interoperable. The scaffolding and generation stuff sounds really
> interesting. I'll check it out.
> A defence for Dojo could be that it has a very strong hierarchicall widget
> system which, together with the smart loader kind of 'enforces' good
> behaviour which lead to portable and modularized apps. This is another issue
> entrely than developer-support, scaffolding et.c.
>
> Cheers,
> PS
>

[Peter Svensson]

Hi Justin. I completely agree on the Java part. I'm trying very hard to not have to do any more Java coding - ever. It's harder than it sounds, though. From what I know of JavascriptMVC it's strength lies very much in its enforcing logic, which sounds really nice. Since  Server-side JS is becoming more popular, non-bling toolkits will also become more important.

I hope to be able to briefly describe how Dojo helps me in throwing up quick mockups. Let's see.
Dojo can be used 'under the covers' entirely, even with graphically intensive components, but likewise almost all components / widgets / 'Dijits' can be declared inside the page, including ones you've made yourself.

Here's a quick example, which define some settings for Dojo, including where to search for my custom component. Also, it sets parseOnLoad to true, which tells Dojo to scan through the page and create all components it finds. The dojo.require statement loads specific components so that they can be used in markup later.

----- inside head -----

<script type="text/javascript">
        djConfig=
        {
                parseOnLoad: true,
                isDebug: true,
                modulePaths: {scaffold: "../test/scaffold"}
        }
        </script>
        <script src="../dojo/dojo.js"  type="text/javascript"></script>

        <script type="text/javascript">
            dojo.require("dojo.parser");
            dojo.require("scaffold.main");
        </script>

---- Inside body -------

What the below markup does is to define an instance of a widget (that I've made) called scaffold.main. The name scaffold is declared in the djConfig setting modulePaths to be at a specific relative url. Under that url, Dojo will search for a file called main.js . The rest of the markup proeprties are provided as properties to the class which defines the component, if already present. This means that if the component have defined a property called 'content' (which it has), it will be filled with the value in the markup.

<div dojoType="scaffold.main" style="height:110px;"
         content="{'news': 'http://localhost/dojodev/test/scaffold/content/news.html', 'products': 'scaffold/content/products.html', 'partners': 'scaffold/content/partners.html', 'people' : 'scaffold/content/people.html'}">
    </div>

---- js code -------

This is the beginning of the file called 'main.js' udner the ../test/scaffold directory. It begins be declaring that it provides the specific class. Why this is necessary is because one file sometimes declare several classes / components. After that it require in what it needs, so all requires for all components in the page need not be listed and maintained in the page using components, which is a good modularization.

Further down comes the content property. And then a couple of magic functions, which are called by Dojo at certain points in the component lifecycle. There's a destry as well (if you want, et.c.).




dojo.provide("scaffold.main");

dojo.require("dijit._Templated");
dojo.require("dijit._Widget");

dojo.require("dijit.layout.ContentPane");
dojo.require("dijit.layout.StackContainer");
dojo.require("dojox.fx");
dojo.require("dojox.fx.easing");

dojo.declare("scaffold.main", [  dijit._Widget, dijit._Templated ],
{
  templatePath            : dojo.moduleUrl("scaffold","templates/main.html"),
  widgetsInTemplate        : true,

  content                       : {}, // name - url pairs for menu building
  lastitem                      : "",
 
  constructor: function()
  {
    console.log("constructor for scaffold.main called");
  },
 
  postCreate: function()
  {
    console.log("postCreate for scaffold.main called");
    for(var k in this.content)
    {

...
...

note the 'tempalePath' property, which defines a file which contain the HTML snippet that the component use (if any), which can use basic templating ( ${foo} to insert a 'this.foo' of the component class on creation), or DTL (Django Templating System).

Dojo also have a build system, similar (but 100x more hairy :) to JavascriptMVC, which inline templates as strings, compresses and concatenates many files to few, et.c.

Ahem.. Thanks for listening :) Sorry for the off-topic!