https://github.com/twitter/bower

convert the documentation to JSDoc3 format

The ES6 Set draft is different than the ObjectSet class used in hormigas.ObjectSet. Matching the ES6 Set draft more closely would likely mean breaking changes to Maria. I've started a discussion on the es-discuss mailing list to find out more about the ES6 Set spec which seems incomplete.

The JSDoc-generated pages have the generic JSDoc3 appearance. They should look like the rest of the Maria website.

Follow the instructions and ensure everything works. [completed]

Need more screenshots of the UI near the end of the tutorial or at least reuse the one from the start of the tutorial. [completed]

Use the resulting app as the eg/checkit app in the git repository. [completed]

I need to introduce the composite pattern at the end of the tutorial. [completed]

There is one missing version of index.html in the tutorial. The step is explained but the updated version of the file is not shown. [completed]

Can I remove the dependency on features of ObjectSet that are currently in question? See #10 [completed]

Perform a full code and documentation review of the Evento library upon which Maria depends.

convert the documentation to JSDoc3 format

It may just be me but I think this entity could be named better. How about 'ModelList'?

For me it sounds like a setter.

convert the documentation to JSDoc3 format

The dependency libraries are hidden inside the IIFE that surrounds the entire build maria.js and maria-amd.js files. Since these dependency libraries are hidden, there is no need for them to be in their own namespaces. Instead of borrowing those libraries into the maria namespace object, the namespaces of those other libraries can be replaced with maria. For example just replace every occurance of hijos with maria, etc. This will make the documentation of Maria read much better and make maria.js read much better also.

This may require a build step before running Maria tests or opening the example applications.

Currently, controllers and views are bound through naming convention - is there a way to bind them explicitly if I was not to follow that convention?

Hey @petermichaux!

First of all congratulations for maria. It's an amazing project. Small, clean and supper easy to learn. I simply love it.

This issue is just a simple suggestion for improvement: Shall the final build of maria.js be wrapped in a Immediately-Invoked Function Expression (IIFE), exporting only the maria namespace and hiding all the other libraries from the global namespace? That would make for a cleaner implementation (in my opinion anyways).

Cheers!

Events bubble. A set model can observe itself for bubbling destroy events. Then check if the original target is a member of the set (not bubbling from deeper in the tree) and remove the item. This will be much simpler than adding and removing destroy listeners on each element in the set.

Same for maria-NodModel plugin.

There should be a scrollit.escapeHTML function and it should be used instead of inline replace calls.

https://ci.testling.com/

Testling is like a CI in the cloud for frontend javascript libraries!

I use it for my libraries ( https://github.com/Raynos/immutable-hash ) and it's a solid indicator of browser support at a glance!

Occasionally, views need more fine-grained notification than the coarse-grained change event that usually causes the view to make a complete refresh. For example, a PersonView might want to know only when the PersonModel's name changes and only update the visible name in the display.

The plugin implementation would be

(function() {
    var original = maria.Model.prototype.dispatchEvent;
    return function(evt) {
        var type = evt.type;
        while (type) {
            evt.type = type;
            original.call(this, evt);
            type = type.replace(/\:?[^\:]+$/, '');
        }
    };
}());

With this plugin, a model can have just

setName: function(name) {
    name = '' + name;
    if (this._name !== name) {
        this.name = name;
        this.dispatchEvent({type:'change:name'});
    }
}

which is equivalent to the following without the plugin

setName: function(name) {
    name = '' + name;
    if (this._name !== name) {
        this.name = name;
        this.dispatchEvent({type:'change:name'});
        this.dispatchEvent({type:'change'});
    }
}

When using the plugin, a view that needs fine-grained control will use different modelActions object, for example,

maria.ElementView.subclass(app, 'PersonView', {
    modelActions: {
        'change:name': 'updateName',
        'change:height': 'updateHeight'
    },
    properties: {
        updateName: function() {/* ... */},
        updateHeight: function() {/* ... */}
    }
});

Include the example applications as part of the Maria website.

We have a Set and a SetView.

When we update an element in the Set it can change the order in which it should be displayed in the SetView.

The simple way we achieve this right now is to clear the Set and add the elements back in the order we require. However, this causes the SetView to 'flash' (View draws empty list, then draws list w entries).

How can we redraw / refresh the SetView without a 'flash' ?

Could more development debugging statements be inserted in the Maria code to help developers? This code would be included in a built maria-debug.js but removed from maria.js and maria-min.js.

For example

/* DEBUG BEGIN */
    console.warn('are you sure you are doing the right thing here?');
/* DEBUG END */

Or embedded in another line

x=1; /* DEBUG BEGIN */console.info('hello');/* DEBUG END */ y=2;

The build process in the Makefile will need to strip these debugging statements.

Perform a full code and documentation review of the Hormigas library upon which Maria depends.

Depends on #10

There is plenty of looping in maria.SetView.prototype.handleDelete. The "j" loop could be removed if a tag property like "_maria_SetView_id" was added to each item model object and then a mapping from these ids to view objects was kept.

maria.SetView.prototype.handleDelete = function(evt) {
    var childModels = evt.relatedTargets;
    for (var i = 0, ilen = childModels.length; i < ilen; i++) {
        var key = childModels[i]._maria_SetListView_id;
        this.removeChild(this._mapping[key]);
        delete this._mapping[key];
    }
};

Need initialize and keep this mapping up-to-date throughout SetView's implementation and ensure it is destroyed correctly.

This is an optimization to consider when SetView proves itself as something useful that will stay around permanently.

Sure could use ES.next Map right about now.

convert the documentation to JSDoc3 format

The documentation in the doc directory needs to be completed.

I have the following:

uiActions: {
'click .create-open' : 'onClickCreateOpen',
'click .create-close' : 'onClickCreateClose',
'click .save' : 'onSave',
'click #inputOccursAtYear' : 'onYearSelected',
'click #inputOccursAtMonth' : 'onMonthSelected',
'focus #inputName' : 'onNameInput',
'blur #inputName' : 'onNameInput',
'keyup #inputName' : 'onNameInput',
'keypress #inputName' : 'onNameInput'
},

All works fine on Chrome on Linux (Ubuntu) and Firefox (Ubuntu) and Mac Firefox.

However - the controller method is not called for click events on select lists under Chrome on the Mac (Chrome V26).

Please could this be fixed?

Perform a full code and documentation review of the Arbutus library upon which Maria depends.

Maria is great but having to download the whole repository, install dependencies and build the solution in order to get started with Maria can be a bit time consuming and discourage people to start playing around with the project.

Just a suggestion, but having a dist directory containing the built Maria both in dev version (pretty with comments) and the minified version would be great to offer the community a quick starting point. The example applications within eg could even use this minified version as a way to show off how it'd do in production...

Again, food for thought ;)

Change the build process to use Closure Compiler for minification. Download this file automatically if it had not been previously downloaded.

http://peter.michaux.ca/maria/

Only the top link goes anywhere. Either get rid of the rest or document them.

Perform a full code and documentation review of the Grail library upon which Maria depends.

When I add the below to my view:

modelActions: {
    'edit'  : 'onEdit'
},

The view stops working because I didn't include the { 'change': 'update' } entry.
The modelActions work when I change to:

modelActions: {
    'change': 'update',
    'edit'  : 'onEdit'
},

Could this GOTCHA be added to the doco (I looked but didn't see it).

A useful model class to have.

JSDoc3 is having issues building the docs locally which stops me from updating the site.

Before releasing v1.0.0 test in all browsers.

It seems like we are ready for the big release.

Update the version number in header.js, CHANGES file, and push.

Tag and push.

Release to my downloads site and update current link.

Rebuild maria-bower with only one tag for 1.0.0 (need to do this because node-semver is buggy and causing Bower to have problems.)

convert the documentation to JSDoc3 format

I have two elements in my DOM, one classed "detail" and one classed "details".
When I use this.find('.detail') it matches on '.details'.

Is it possible it also needs to use the size of the word in the match?

http://yeoman.io/

I found your MVC library and thought it might be the ideal place to play about with client-side MVC models. I was trying to make the maria work with require.js and jQuery since I had a working example already with jQuery and require.js but it seems that the namespacing requirement and the way that models get created clash with the assumptions made by require.js. This is a bit new to me so I may just need to dig in for a bit. Could you give me any tips for using maria with require.js?

Marias set allows me to say set.has(element) and it returns true/false.
However, how can I get the existing element?

The situation I'm trying to deal with is a refresh of data from the server.
If the element is new I add it but if it exists then I want to update it.

Rebuild the maria-script-template-bower repository to depend on Maria 1.0.0. Too many Bower problems thanks to node-semver bugs.

Code comments should conform to JSDoc3

https://github.com/jsdoc3/jsdoc

Port very nice infinite scroll example that shows off JSONP communication.

https://github.com/Atinux/backbone-books

Developing a full-blown, single-page, web application is a primary target use case for the Maria framework.

Implementing such an application requires creating many models, views, templates, and controllers. The process of creating these files and including a few lines of boilerplate is tedious.

A production-ready, single-page, web application should be built before deploying to the web servers. This involves minifying, concatenating, and gzipping files that have time or checksum stamped file names that are used both for the files and in the references to those files. Yet in a development mode we do not want a build process to slow down our workflow or to deal with error line numbers not matching the source code.

Most of this will seem familiar to folks accustomed to the server-side Ruby on Rails framework with its rails command line tool that generates files and runs a development web server and the Rails asset pipeline. Jammit is a Rails plugin worth looking at also.

I think all of these features should be built into a maria command line tool.

~/src/ $ maria new checkit
    create
    create README
    create src
    create src/index.html
    create src/js
    create src/js/models
    create src/js/views
    create src/js/controllers
    create src/css
    create src/img
    create tst
    create lib
    create lib/maria
    create lib/maria.js
...

I'm not completely sure where templates should go. They need to be written in HTML files that end in the suffix .html and be compiled to the necessary JavaScript template objects that Maria expects (as shown in the examples.)

~/src/checkit/ $ maria generate model Todo
    create src/js/models/TodoModel.js
    create tst/models/TodoModel.js

How will these files be included in the served page? That should be done automatically. Manifest files, require comments, and require AMD are all possibilities.

~/src/checkit/ $ maria generate view Todo
    create src/js/views/TodoView.js
    create src/js/controllers/TodoController.js
    create src/path/to/TodoTemplate.html

~/src/checkit/ $ maria server
application starting in development on http://0.0.0.0:3000

~/src/checkit/ $ maria build

Bower, Yeoman, and Grunt could possibly be used behind the maria command line tool without the developer even knowing.

I'm trying to open the example applications, but getting an error in View.js:140.

Am I missing a step? It looks like the hijos library not being attached to the maria namespace.

Perform a full code and documentation review of the Hijos library upon which Maria depends.

Pretty websites impress.

Rebuild the maria-emphasize-bower repository to depend on maria 1.0.0. Too many problems with Bower thanks to node-semver bugs.

The destructors and destruction process in all classes needs review.

When building maria-min.js build a source map file.