Container embeded in Compiler Maven Plugin

Hi !

A new feature is now available in Archetype Compiler Maven Plugin. It is able to embeded a container, like a Tomcat or a Jetty for instance , to execute your application behind it. To reach this goal, the plugin uses Cargo (http://cargo.codehaus.org).
So, you just need to specify a WAR file (or an expanded WAR directory) and your apllication is directly executed and compiled. Moreover, a WAR file resulting from your web project compiled is now created, ready to be deployed.
Documentation of how doing all theses things is available on the Archetype Compiler web site.

Compiler is done, embed in a Maven Plugin

After weeks of work, the compiler is now finished.
I sum up below it list of features :

- Bundle all javascript's files of Archetype Framework
- Bundle all javascript's files of your project
- Merge all stylesheet css and resolve images path with Juicer
- Bundle all html templates
- Compress and minify css and js thanks to YuiCompressor

The compiler is a Jruby script, but it is also embed it in a Maven plugin, so it is such a nice way to use it directly in a Maven project.
Cause I have used archetype 0.11, I'm waiting for the next version to merge my compiler, so it will be available soon.
I'm also writing some documentations and a first beta version of the "Compiler Archetype Framework Maven Plugin" web site can be consult at this url : http://archetypejs.org/compiler. You can find informations of how to use the compiler, what are the options, the RubyDoc and JavaDoc and at last a small FAC to answer common questions.

New diagrams

For a recent presentation of Archetype, we wanted to use new versions of our positioning and architecture diagrams.

Here it's a preview of these up to date representations:

First the Archetype positioning:


The global Archetype application architecture:

Both will be soon added on the website.

Archetype 0.10.0 is out !!!

At first, we thought that the 0.9.3 would be the latest of the 0.x series, but our standard for features and quality are very high. So, we decided to wait for our "compiler" and some major improvement on components to be ready, well tested and with a stable API to throw the 1.0.

So, after some months of development (started around the 1/20/2009) and after more than 200 commits, 0.10.0 is here !

Here is the change log :

- Archetype engine abstraction (aka jQuery support !!!)

- New Maven website enriched with Archetype !

- Complete documentation!

- Switch to Dojo unit test engine: Dojo objective Harness

- Archetype.charset now defines the script charset (in order to ensure there is no bug with IE6,
if you want to change this, please add the charset variable in the Archetype namespace in archetype.js itself)

** Bug

* [AJF-69] - Make script charset configurable
* [AJF-72] - Event with null data doesn't work with Prototype engine

** Improvement

* [AJF-13] - Switch to another JS Unit Test framework
* [AJF-70] - Improve Maven website
* [AJF-73] - Replace custom event library by engine native implementations

** New Feature

* [AJF-10] - A real Documentation
* [AJF-63] - Run Archetype on top of jQuery


Known bugs:

- You may experience some troubles using firebugLogger and IE 8 developer tools or Opera Dragonfly
- Due to a bug in Dojo objective Harness, unit tests for Safari 4 aren't conclusive

Parallel works

There is a lot going on right now on our project! (Thanks to Mercurial for keeping up with all the merges we have been doing.)

Temsa is working on the new skin and home page of our next web site. We’re working particularly hard on it for release 0.10 in order to give visitors a better first impression.

Meanwhile, I will soon be done writing the documentation. Archetype release 0.10 will be the first one to be fully documented, even though we still have a few additional ideas to complete the documentation, by describing different use cases for Archetype for example.

Caroline joined Archetype recently to help us improve our English expression (and maybe for development some day? :D). All of us are French and Archetype is fully written in English so we are trying our best to have error-free English pages.

As you can see, Zed is now able to concatenate all of Archetype’s files: JavaScript, components, templates and CSS, using a smart trick of emulating Archetype with HtmlUnit to obtain the sorted file list. He’s already starting to look at more powerful features like compression, code coverage or image bundling.

Finally, most of 0.11’s features (explained in the "New Components" post) are already developed. Branch 0.11 also contains needed improvements to work with the compiler (like the ability to insert templates in JavaScript without using an XHR request).

Stay tuned for more on release 0.10 which will soon be out!

A new way for the compiler

I have some good news about the archetype's compiler : I've decided to totally changed my way. Like the archetype's core is able to resolve dependencies itself, it's a good idea to use it in the compiler.

I look at HtmlUnit (http://htmlunit.sourceforge.net) which models a browser in a Java programs. With it, I can execute archetype and get back variables of the configuration from the browser's memory. I also use a system of javascript's alert, present only in the compiler, in order to obtain the good sequences of modules and components.

So, the bundle of the modules is done and I currently work on components. I also think about some solutions to merge css and templates.

I change my mercurial hosting and you can get a development version here : http://bitbucket.org/Zed/archetype/. This one is able to bundle modules, components and soon templates.

Fraking Doxia !

Since the early start of archetypejs.org, we use maven to generate the static main website.

While we're in the documenting phase of the 0.10 (don't wait to try it ! I think we'll release a beta this week as the main code has been almost freezed weeks ago), we're also reshaping the website and reviewing our documentation.

My goal today was to achieve a carroussel for the main Archetype features on the home page giving more space to other informations like who uses Archetype, and so on. However, Doxia, the system under the hood of our website has just some particularly annoying behaviors regarding our xdoc documents. In fact, it just removes our "class" attributes of at least most of the interesting html elements.

Why adding class to html elements is so important to us now ? Beacause we want to do a "web 1.5" website (before a full "web2.0", for one of the next site release), and we were planning to use an element class based strategy to retrieve graphical components to load dynamically for the current page... for example, a Carroussel ! This strategy has been successfully used on http://france.meteofrance.com and is easy to use, while not very intrusive and quite clean.

Here is a snippet to retrieve components that have to be loaded on a particular page, in the page controller, that work both using Jquery or Prototype as Archetype engine :

Archetype.requireComponent($$(".archetype-component").collect(
        function(o){
            return $A(o.className.split(" ")).findAll(
            function(c){
                if(arguments.callee.c=="archetype-component")
                    return true;
                arguments.callee.c=c;
                return false;
            })[0];
        }));

And here's an example how to load a component(component name has to follow directly "archetype-component" to work):

[...]class="archetype-component ArchetypejsOrg.component.Carroussel"[...]

I still have to check that it works for multiple components because of the fun "arguments.callee" use for storing the latest class used, and that it doesn't break in any browser as using "." is quite bad (meteo's version was using "-" instead, could be a neater solution).

So what will we do to circumvent the problem ? We'll probably get the xdoc document as html documents and use doxia only for the dynamic parts of the website and some particular pages... but it will be a little longer to move rather than keep it like this. The solution will probably be to make a beta or RC of the 0.10, without the whole new website, but with a website containing almost the same thing :)

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 :)