views:

54

answers:

1

Hi, Building a browsergame I came from PHP to JavaScript, which I now also want to use at the server side. As I'm going to require Users to have JavaScript either way, I'm going to take extensive use of it. I want to use in in a object-oriented way though.

Considering MVC, Models will be used on both client and server side. Views are only used at the client side. The interface is split into multiple parts: a main sidemenu, main content and some widgets. I'll take the part I've already done as example: The menu is split into three categories with multiple entries. Each entry is a link with an attached action (like switching the content).

// menuview:
var self = new View();
var generalMenu = new MenuCategory('generalmenu')
    .addEntry(new MenuEntry('overview', new Action()))
 .addEntry(new MenuEntry('buildings'))
    .addEntry(new MenuEntry('resources'))
// [..more categories..]
self.toData = function() {
    return {
        id: this.id,
        cat: [generalMenu.toData(), infosMenu.toData(), userMenu.toData()]
    };
};

At the moment View is a compositum with a toData() method to create data for the template parser(selfmade, simple but supporting iteration). And the actions get attached after creation. I use jQuery as framework:

self.show = function(callback) {
    $tpl(this.tpl).parse(this.toData()).lang('main').toHTML(function(html) {
        var el = $(html);
        el.find('a').click(function (e) {
            MenuEntry.actionHandler.execAction(e.target.id);
            return false;
        });
        el.appendTo('#'+self.target);
        callback && callback();
    });
    return this;
};

I have declared an actionhandler to avoid iterating over the links.

I'm not feeling well with this solution, it's not flexible enough. I'd like to treat a view like a real compositum, not with a lot of strange dependencies. Also, I have to reparse the whole View if I change a part. Well, in this example this is not obvious, because the menu wont change while runningtime, but other parts of the interface will.

Now, to finally get to my question: Is there a better solution? Like having dom references spread over the view, each menuentry having it's own reference and directly attached action? If I'm not using templates anymore, what kind of flexiblity am I losing?

A: 

I decided to go without template parser. Each view stores it's node and is able to manipulate it directly if it gets informed to update the data.

Phoscur