[Archetype JavaScript Framework] New Archetype’s components

[Swiip]

Components are what bring Archetype from a JavaScript file loader to a real Web Framework.

Using components in JavaScript makes possible to use all of the necessary concepts for the user interfaces development:

• Development unit: the JavaScript is not going inline in the HTML content but in one file by component (like Classes in most languages).


• One stuff, one component: a component groups the whole cleverness of a functionality.


• MVC: the graphical component is the controller, the associated template is the view, the model is brought from the server, or from a business oriented component through an event.


• Events: allows broadcasting communication and independence between components

But Archetype’s components syntax is still too verbose and has to be enhanced in order to achieve a very usable framework. We have identified several tasks in order to improve and ease use of components:

Remove configuration
Some configurations can be replaced using conventions. Write component name itself and the view name is useless 95% of times because this can be assumed by the framework using a convention.

Component embedding
Component-oriented UI often offers to build “meta” component based on combination of simpler component. Write this kind of components isn’t easy at all. So we need a simple convention to do it.

Manage component rendering and behaviors
A graphical component rendering is always working the same way: evaluate the template with some prepared data (the component itself), then insert content in DOM and eventually register event listeners on new content. The objective is to hide this complexity to the user.
We already worked on the first two steps: the template evaluation process is automatic, using data binding on the whole component, then insertion is done on the “anchor” parameter, however registering events listener kept to be handle manually.
Using the syntax of JavaScript behavior sheet, we could define this last step as an automatic one too.

Manage multi-state components
Web 2.0 is dynamic. Destroying a component and building a new one for each modification on its content is not optimized. So, if server-side frameworks can work without multi-state components, Archetype can’t.
We have to implement an abstract multi-state component which provides tools to manage several templates, several behaviors and solutions to switch from one state to the next easily.

Lazy loading
Configure all dependencies in components is very nice but leads to quickly to load the whole application dependency tree when loading the application first component. We must keep advantage of the dependency configuration, but save performances, by adding some kind of “Lazy loading annotation” which allows loading a dependency only when it’s really needed.

Template store
Archetype handled a store of references to all of the already loaded files in order to avoid loading twice a single file. An exception has been added on templates loading in order to let the browser caching it or not if the content had already been loaded. In fact, high chances are your web server won't to be configurated the good way in order to fully benefit from browser caching.
So, we actually have to implement the template store in order to improve performances and handle templates caching using Archetype itself.

--
Envoyé par Swiip dans Archetype JavaScript Framework le 2/10/2009 06:11:00 PM