Using Archetype as a dependency manager only

After a whole day work, I've modularised Archetype bootstrap dependencies in order to load just what is needed to use Archetype as a "Script Loader" only.

It has been tested this evening on a big project using about hundred of interdependent files successfully without any modification of the framework itself! It's available in the SVN trunk right now :)

This project based upon OpenLayers, with a lot of enhancement using multiple overloading classes files). This project does not use Joiners, nor the Event system, not the Archetype.Class enhancement.

There are now some "expert settings" in the configuration, giving you the ability to load and use only what you need.

This is a great news as Archetype starts to be very very strong on the dependency management side and can be easily used now on any Prototype 1.5.x based application (or not, but it just relies on Prototype 1.5.x).

In a script loading only configuration, the framework takes about 34kb totally uncompressed (with a lot of comments for JsDoc).
Using a JSmin(a basic JavaScript compressor) pass, it shrinks down to 15kb, and if your using the HTTP1.1 GZip compression on your web server, it's no more than a 4.8kb that will be used to go on the client!

Awesome, isn't it ? ;)

Archetype's resolver

We've found that we needed a real brain storm about how we'll resolve modules URL and dependencies through configuration file.

Archetype.require is one of the oldest methods of Archetype. Many functionnalities have been added. To manage all configurations like "submodules", "needs", "aPath" and "rPath" we completed and complexified this method. It made it become a real mess and it's pretty hard to understand and maintain.

Configurations need a real recursive analysis but old require was not completely recursive (however you had to do a complex configuration to encounter any problem) and that's why we had that famous first bug on our JIRA: AJF-1.

I have extracted the resolution of modules names in the require parameter to correctly handle a recursive configuration and manage layers to order dependency loading.
Require is now really much more complete and robust and can handle any exotic configurations.

In the same evolution, I've seen that our UMN (Unique Module Name) object was used every time we needed to extract realPath or URL of the module. I transformed the $U function from returning UMN object to the URL String to simplify coding. It causes many internal refactoring but any changes for final user.

I've just committed these new functionality. It implies many changes like variables refactoring and jsdocs comment review but it's fully working.

What's up doc ?

Just a little news to say I've moved the blog to http://blog.archetypejs.org.

Besides that, I'm working on the next tutorials part, and Swiip is achieving a major internal move to split UMN resolving & files downloading. It will ease Unit Tests, be stronger, be cleaner and will solve the AJF-1 bug (great job Swiip !).

Countries interested in Archetype since 0.1.5

Countries interested in Archetype (http://archetypejs.org) since 0.1.5
Mise en ligne par temsa

Since latest release, Archetype has received on it's official website almost half of the earth countries :) !

Some detailed view about France and the USA :

Details for France
Mise en ligne par temsa

Details for the USA
Mise en ligne par temsa

FOSDEM Video

Ok, definitively not my best performance at all (too tired, too stressed, or whatever other excuse can be invoked ;D ), but here's my FOSDEM 2008 Lightning talk about Archetype.

As FOSDEM is for developers, I've shortened the presentation part in order to show a bit some part of the code behind the presentation itself : Slidy, this little app, made in about 2-3 hours (not including the CSS Adaptation for the FOSDEM and images around it) that just handle slide changes without any effect but a page counter.

I promise to do better next time, it was my first presentation in English with around 100 people in the room ;)

archetypejs.org update

I've spent my whole day working on images, Maven site template, and CSS of archetypejs.org.

Hope you'll find it cool !

Better late than never: the 0.1.0 -0.1.5 Changelog

History:

02/23/2008 - 0.1.5 : More compatibility, industrialised with Maven,
improvements :

- Enhanced the bodyLogger to take more than one argument
- Enhanced Slidy to handle (at least on FF) previous/next slide via left/right key
- Added a namespace for Archetype Classes : ComponentManager, Components, Class etc. are now in Archetype.ComponentManager, etc. (this was the only solution for Archetype to work with Firefox3, as Components is defined by the browser itself)
- Added a new alias : $C for Achetype.Component
- Avoided any share of "_private" between same prototyped components (was a bug)
- Added the _ alias to Prototype.emptyFunction
- Added a default rootEquivalence in order not to have to define it always (keeped it configurable though)
- Added absolute path management for modules
- Added options by url loading (scriptaculous like) notably to be able to force a particular page controller
- Bug corrected : loading with many file with the same "module" name
- Refactored the tree to use default maven organisation
- Completly "Mavenised" the project in order to get something more industrial.
- Improved Unittests page (However, we will have to move to a better UnitTest framework)
- Embedded Prototype window Class 1.3. Not use at the moment but could do a great cross browser Logger.
- Improved Templates (Comments, etc.)
- Improved Archetype loading: no more synchronous Ajax (Sjaj if you prefer ^_^) during loading
- Bug corrected: you can now use multiple file with the same name and different extension safely
- Did some work to prepare managed i18n possibilities
- Added the $exist() helper in order to test if what is check is not undfined nor null.
- Created a Maven site with Presentation, documentation, JsDoc and Jslint coverage.
- Improved the JsDoc contained in the code
- Generated some JsDoc with jsDoc toolkit 2.0 SVN
- Prepared the FOSDEM using Slidy. Removed the original Slidy tutorial and moved to the FOSDEM presentation.
- Moved the different libraries used in "libs" directories.

10/18/2007 - 0.1.0 : initial release

Little update

I've updated archetypejs.org with a getting started with Archetype.

It's not complete (I hope to finish it until tomorrow or saturday), however, as half of the people visiting archetypejs.org are looking at this page, and just get a "coming soon", I have deployed a part of what has been written right now :)

Component destruction

It was long ago that we see that we can't destroy a component.

We don't see real memory leaks but for event listening it is more important. It was very difficult to stop all listeners that we create in a component. But in a big RIA application, we were forced to manually handle persistence of a component which had disappeared a long time before (and continue to receive all events...).

Trunk version adds now a new inherited method in all components (method is present in the abstract component) which offer to disconnect all event listening in the component.

There was a difficulty for creating this method : disconnect a listening must be done with the good pointer of exactly the same function than where it was created. This function was not easily accessible at all. In most case, the pointer was lost.

There are two types of event listening in a components : Archetype events and DOM elements events.
For Archetype events it was much simple, we managed listening, so I added a storing of the function in order to use it for disconnecting.
For DOM elements events we didn't managed listening so I have created a new MethodBuilder which overload the "observe" method. It has now the same structure than Event.observe of Prototype but we store listening function and we are able to disconnect it on component destruction.

You must just remember using "this.observe" for DOM element listening in order to disconnect this listening too on destruction.

In the future, it can be interesting to study a more complete destruction which can be able to free some memory.

Using "this.observe" is a bit fastidious for the moment but we start reflection on an much easy way to configure DOM event listening (much easier than Prototype if it's possible!). You can follow this work on JIRA.