petermichaux

vor 14 Jahrendiscuss

You're right about the event being part of the DOM. If that is a concern, you can define your own view handlers that unpack the DOM event and forward the data to the controller handler. There is no way to autogenerate view handlers that know what needs to be unpacked in what way.

petermichaux

vor 14 Jahrendiscuss

SetView.js contains a class called "maria.SetView". borrow.js does not contain a class but a function called "maria.borrow". Regardless these files all are concatenated to become a file simply called maria.js.

petermichaux

vor 14 Jahrendiscuss

A controller and the strategy pattern allow a view to behave differently by plugging in a different controller into the view. This interchangeability of behavior is not something I've leaned on frequently in my own programming.

I am finding, while programming example applications for Maria, that splitting the event handling out to the controller is forcing me to make better APIs on my views to keep the DOM encapsulated. Allowing the controller to get the form data, without exposing any DOM information, for example. The view code ends up being very satisfying in a way I haven't experienced before.

What I'm hoping will happen is that after using strict view and controller separation for a while, I'll start to get insights where the strategy part could be used more. I think its the kind of thing that will sneak up on me over time and I'll start to see more uses for it.

petermichaux

vor 14 Jahrendiscuss

Which differences? You can use any file system hierarchy you like with Maria.

petermichaux

vor 14 Jahrendiscuss

fzzzy,

Thanks for taking a look at Maria. You definitely got the gist of how things work with Maria but there are a few subtleties that might change your perspective on the relationship between views and controllers in an app built with Maria.

If a view has the following

    maria.ElementView.subclass(myApp, 'MyView', {
        uiActions: {
            'click .alpha'   : 'onClickAlpha'   ,
            'mouseover .beta': 'onMouseoverBeta'
        },
        ...

That auto-generates two methods on the view that forward handling to the controller.

    myApp.MyView.prototype.onClickAlpha = function(evt) {
        this.getController().onClickAlpha(evt);
    };
    myApp.MyView.prototype.onMouseoverBeta = function(evt) {
        this.getController().onMouseoverBeta(evt);
    };

So it is actually the view that handles the DOM events.

If you don't want the controller to handle the raw DOM event or you don't want a controller involved in handling the event at all, you can define the handler methods on the view yourself and then the auto-generated methods will not be created. For example,

    maria.ElementView.subclass(myApp, 'MyView', {
        uiActions: {
            'click .alpha'   : 'onClickAlpha'   ,
            'mouseover .beta': 'onMouseoverBeta'
        },
        properties: {
            onClickAlpha: function(evt) {
                // not sending evt to the controller
                // and controller method name is different
                this.getController().onSomething(1, 2, 3);
            },
            onMouseoverBeta: function(evt) {
                alert('no controller involved here');
            },
            ...

Also about who should query the form data: the view or the controller. I believe the view should be the only player in the game that knows about the DOM. If the way that the form data has to be retrieved from the DOM changes, then only the view needs to be updated. This makes sense to me as the view is the one that creates the form so the view should encapsulated all access to the form.

In the real world, the view/controller separation can be fuzzy. With Maria you can easily live without any controllers and have the views handle all user events or you can go wild with controllers and have all kinds of interchangeable view behavior thanks to the flexibility provided by controllers and the strategy pattern.

petermichaux

vor 15 Jahrendiscuss

They didn't say "The King Henry VIII is dead. Long live the King Edward VI". In the JavaScript article, The "OLD king" is "JavaScript the source language". The "NEW king" is "JavaScript the compilation target". So the idea of old and new is in there. Sort of. :-)

petermichaux

vor 15 Jahrendiscuss

You know how on January 10th, 2011 you were still writing 2010 by accident? I was off by a decade. Corrected.

petermichaux

vor 15 Jahrendiscuss

If you like minimalistic languages, have you checked out Scheme? Because of its macros, the core language can stay small and the users can expand its syntax.

petermichaux

vor 15 Jahrendiscuss

There was an ES4-to-ES3 compiler. The Traceur compiler takes many of the Harmony ideas and compiles to ES3.

petermichaux

vor 15 Jahrendiscuss

Yes but many of the ideas in CoffeeScript were likely slated for ES.next before CoffeeScript. So it has been working in both directions.

petermichaux

vor 15 Jahrendiscuss

Features that can be added through libraries should be added that way. You cannot add new syntax which involves scoping of variables through libraries. How would you do destructuring assignments with a library and have it as succinct as it can be done with syntax?

petermichaux

vor 17 Jahrendiscuss

http://github.com/jrockway/lisp

Please let us know when it is ready ;-)

petermichaux

vor 19 Jahrendiscuss

Please write about how you do this and how you interact with the files (loading and serializing). I'm looking at alternatives to using relational databases and information about how to avoid data corruption (features analogous to transactions) is scare. How would you convince a mission critical site developer that this is safe?

petermichaux

Submissions

"LuaJIT's interpreter () beats V8's JIT compiler" - Mike Pall

comments