News from Archetype's compiler

Hi,

As you may already know, I'm currently working on a script which is able to build an Archetype's configuration file, actually a kind of compiler. In order to do this, I'm working with JRuby : a JVM running implementation of the ruby programming language (probably the best implementation of Ruby right now).

The development progresses and the script is nearly up. It's an executable which gives you quite a lot of parameters related to your application : the destination's directory of your project, the engine you use, the template and the logger you need, and so on. For all of theses parameters, you've got to specify the absolute path for files and libs, then the script makes some merge between the original files and then, everything you need is available in your new project's directory.

I generated an help and a documentation to allow user to get started on a easy way.
I think there are clearly many bugs left yet and I work hard to eradicate them. Don't forget the script is in a beta version.

If you want to try it out, feel free to check it out using mercurial at :
http://freehg.org/u/Zed42/compiler/
The script names compiler.rb

New Archetype’s components

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.

0.9.3 is available !

Download it !

Changelog:

- Removed Prototype 1.5 from the tree (Archetype won't work without special fixes for it, maybe available again since 0.10 series)
- Removed regextemplate (compatibility break ! Please use Trimpath, EJS or Domtal instead)
- Passed addJS logging from debug to log level
- Removed some backward compatibility aliases (may lead to a compatibility break if you use deprecated aliases)
- Now handles aPath as plain url by default rather than module (=no more need to escape "." in aPath URLs)
- Corrected some loading bug with a default option to asynchronous=true (synchronous is evil here :P)
- Now get templates from server using "get" method (see AJF-66)
- Updated the tutorial

** Bug
* [AJF-65] - Recursive rPath redirection infinite loop
* [AJF-67] - Tutorial is not accurate and doesn't work

** Improvement
* [AJF-66] - Archetype doesn't respect REST architecture for downloading templates

Futur release

We are now in the documenting & site improving phase for the 0.10.0. This release is scheduled for next week :)

Tips for quickly add a librarie to a website to do some tests with Firebug

As I'm currently working on an Archetype based Maven site for the next archetypejs.org, I had to check some features of EJS template.

I wanted to check that Prototype or jQuery "each" syntax would be available in my template. So I decided to use a bookmarklet to insert one of them dynamically in the embeddedjs.org :

- Prototypize

The code : "javascript:(function(){var head,script; if(!document.getElementById('prototype.js')){head=document.getElementsByTagName('head')[0]; script=document.createElement('script'); script.type='text/javascript'; script.src='http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.3/prototype.js'; script.id='prototype.js'; head.appendChild(script);}})(); void(0);"

- jQuerize :

the code : "javascript:(function(){var head,script; if(!document.getElementById('jquery.js')){head=document.getElementsByTagName('head')[0]; script=document.createElement('script'); script.type='text/javascript'; script.src='http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.js'; script.id='jquery.js'; head.appendChild(script);}})(); void(0);"

How to use these bookmarklets ? Just drag and drop them into your bookmarks, then when you need to add Prototype or jQuery on a site, click on the corresponding "Prototypize" or "jQuerize" in your bookmarks, then open you Firebug console and you can use them :)

There's a new kid on the block !

Hello, i would like to introduce myself : i'm Arnaud aka Zed, the new intern working on Archetype with Temsa and Swiip.

As you known, our goal is to reach a stable version 1.0, so I try to fully integrate the framework and improve a bit my JavaScript knowledge.

We discuss that it can be nice to be able to reduce the number of server request for production use. In this goal, a good approach is to merge some files. So, I'm doing tests and I'm trying to determine what can be merge or not (and what has to be done in order to make it mergeable). I have such an idea about the different way to do that : may be, in a first step, we have to offer to the developer, via a script, a choice of files that have to be merged in order to optimise he's application, and in a second time we will suggest an automatic configuration.

I keep you posted about my future achievements.

Archetype engine abstraction

As Temsa has already announced, the main feature of the next 0.10.0 version is not focused on new features for user, but a huge core enhancement which allows Archetype to run on top of either Prototype or jQuery.

We consider Archetype as a real JavaScript Web Framework based on existing and optimized JavaScript libraries. Our objective is not to replace these JavaScript libraries but to build a new solution on top of it. So, Archetype needs a base library (or a set of base libraries) to work on, and we call this library: Archetype’s engine.

We both, Temsa and I, are some kind of “children” of Prototype (that explain the name of Archetype), but our project has grown up and the direct dependency of Archetype to Prototype is not anymore exclusively needed, neither mandatory. So Archetype needs an engine yes, but it doesn’t have to be Prototype.

For the 0.10.0 release, we worked on an abstraction layer between Archetype’s core and the engine used. With it, we can write a wrapper to any JavaScript library which implements the required functionalities.

As jQuery is really active this last month, we have considered this should be our second wrapper (Prototype was of course the first one). With this new enhancement you will be able to use the whole Archetypes’ functionalities without requiring Prototype and rely instead on jQuery.

We wonder if next engine implementation would not be a Dojo wrapper (however this isn’t planned at the moment) in order to cover the main libraries of the JavaScript world. Of course, the best should be to implements a wrapper for all libraries, but that represent a huge work.

Just two precisions:

• If you already implemented an application with Archetype and Prototype, this upgrade will not allow you to switch on jQuery. If the Archetype’s core will work, all the Prototype’s functionalities you use on your application will not work (we didn’t map the whole Prototype’s API with jQuery!).


• We’re not going to remove Prototype from our framework in favour of jQuery! We still enjoy Prototype (and I still choose it if I can have only one) but we think that the possibility of choosing your prefered engine can please more users and ease integration of Archetype on rich and already existing JavaScript environments.

Slidy wasn't working on archetypejs.org, why ?

Thanks to our new intern, Arnaud, aka Zed, which is starting to work on Archetype in order to help us reaching the 1.0, has found that something was wrong on the Archetype website.

When we moved our server, about 2 weeks ago, and changed from Apache to Nginx to serve static content, It seems I didn't checked enought pages of the site.

In fact, Slidy (the old Archetype 0.1.5pre based one, made for Fosdem presentation) wasn't working anymore and I first didn't noticed it.

I didn't find out why this is happening until I checked my "network" tab of Firebug, indicating it encountered an HTTP 405 error during a template load, send by Nginx. According to this post, this is due to Nginx will to respect the REST style software architecture.

We were using the default prototype Ajax method : 'post'... But in REST, this means that we want to create a resource on the server. As Nginx is configured to serve static content, it can't create a new resource, so, it returns a 405 error. So we have to simply use the 'get' method for our Ajax retrieval.

I currently have patched the served archetype.js in order to force the get method for template loading, and have also patched the tip (the 0.9.3 isn't far) in order to solve this and throw an exception in case of any loading problem concerning the template loading. I think we'll update this Slidy example when we will release the 0.10 version which is almost ready.