Archetype JavaScript Framework

Container embeded in Compiler Maven Plugin

2009-05-27T15:12:00.003+02:00

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

2009-05-12T09:42:00.005+02:00

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

2009-04-29T10:51:00.003+02:00

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 !!!

2009-04-08T17:52:00.006+02:00

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

2009-04-01T11:44:00.004+02:00

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

2009-03-09T12:38:00.008+02:00

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 !

2009-03-01T02:29:00.003+02:00

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

2009-02-18T16:17:00.013+02:00

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

2009-02-10T18:11:00.004+02:00

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 !

2009-02-09T12:06:00.004+02:00

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

2009-02-07T14:22:00.005+02:00

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 !

2009-02-06T14:30:00.007+02:00

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

2009-02-04T16:42:00.004+02:00

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 ?

2009-02-03T23:21:00.005+02:00

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.

0.9.2 is out, what's going on next ?

2009-01-28T02:34:00.006+02:00

Yes 0.9.2 is out there, here's the changelog :
--
- Fixed synchronous require, however please don't use it, it's 99.99% of the time
a bad idea (it's freezing the browser)
- I18n fix for Internet Explorer
- Added a configuration for script charset. Don't forget that, in IE, script
charset should be the same as the page one!
- More Unit Tests, including script charset

Fixed:
** Bug
* [AJF-62] - synchronous require isn't ok

** New Feature
* [AJF-61] - CLONE -extended i18n support (number format, translating etc) (PARTIAL)
--

Besides this release, the 0.10.0 is on the rails (I know, rubysh joke ! ). It is focusing on engine abstraction between Prototype 1.6 and jQuery 1.3. Meanwhile, Francois seems working on an i18n patch and this may lead to a 0.9.3 :)

0.10 is now almost ready but we're trying to find a good way to handle Slidy, which makes use of Scriptaculous too. We have mainly 2 ways to support Slidy with both engine: writing a compatibility wrapper mapping Scriptaculous when using Prototype, and jQuery UI when using jQuery, or work on an advanced CSS Transition/Transform Shimmering like the one we saw on Ajaxian a few days ago ( http://ajaxian.com/archives/css-transitions-shim-getting-transition-support-into-other-browsers ) or other shims like transformie ( http://paulbakaus.com/2008/08/16/bringing-css-transform-to-internet-explorer/ ). Another option would be to check if there is an animation implementation or gracefully degrades to no animation.

I've currently played a bit with css transform on my netbook using Firefox 3.1b2, Crossover Chromium and Midori, and this is just great (and FF 3.1 is blazing fast compared to 3.0 on a netbook), even on a damn small computer!

Well, meanwhile this Slidy focus (I'll try to implement at least a temporary solution for the end of the week) Swiip has started a new branch (http://bitbucket.org/Swiip/archetype-components/) in order to enhance components to prepare them for the 1.0.

Multiple objectives for this branch:

- improve component loading, in order to be able to bundle them in one file

- if possible, do what is needed in order for the name attribute to be optional

- implement behaviors ( see AJF-18 : http://bug.archetypejs.org/jira/browse/AJF-18 ). we'll probably map around the dojo.behavior ( http://docs.dojocampus.org/dojo/behavior ) spec, but in a total declarative way: simple, and already bound to the component ( main drawback of this approach without a component, as supported by Joeri on Ajaxian : http://ajaxian.com/archives/javascript-behavior-sheet ).

- component cascading : auto-adding, instanciating and anchoring a component referenced in a template (may just be auto-anchoring a already referenced component in the dependencies). May be done as a default behavior when defining a "archetype:component" attribute to an element(what do you think of that ?).

This branch will probably be merged as the 0.11.0 or 1.0, as it may lead to some compatibility break.

It's a while now :)

2009-01-26T18:38:00.003+02:00

Deer blog,

It's a long, long, long time, we've not speaked here... Shame on us !

Some news : 0.9.0 is out ! 0.9.1 too ! 0.9.2 will be released very soon (probably tonight :D )

We've worked hard in order for Archetype to be releasable when we want, and, after a stale in the development for some months due to the amount of work we have to achieve to satisfy our goal for 1.0, we then had a lot of good news :

- in fact, all the people we know IRL that has used Archetype in their development are now real fan

- we'll have a new big contributor (Arnaud) to the project in about a week (an intern that will work on Archetype for several month in order to help us reach the 1.0).

- Cedric, an engineer student (that has done an internship with us and has developped a collaborative bookmark application using arcehtype as the only front)is currently developing a "java on rails" project on top of Maven, using good frameworks (Hibernate/Spring/DWR), and wether a Flex, an Archetype or a Tapestry 5 front.

- Francois De Metz is our first external contributor, he has improved Unit Tests and some of our code, but also created some new unit tests :)

Besides all of this, we are working hard on a jQuery compatible version of Archetype, including a basic layer abstraction in order to use the same code in Archetype using Prototype or jQuery for it's base. This will lead certainly to a next major version, which will probably be 0.10.0

The 1.0 will have a lot of feature including a lot of tools in order to optimize file loading in production, using bundling and css sprite on top of archetype to achieve better loading times.

Enjoy !

See you soon for the 0.9.2 release :D

Archetype used in www.meteofrance.com !

2008-09-11T17:14:00.002+02:00

Archetype needed a real reference in order to clearly demonstrate its ability to work on huge Web 2.0 applications. Now it’s done!

Météo France, the official French meteorological Agency, uses Archetype on its brand new web site. www.meteofrance.com is one of the most visited French web sites with several millions of clients a day.

Florian, Loïc and I work for a French IT services company: Atos Worldline. The company provides us time to work on our framework as well - it’s good to remind it, thank you Atos Worldline. Actually, our company was chosen to realise this new Météo France web site. I’ve been working myself on this project for months; I proposed our framework for the client development sites, and it all started this way.

The use of the framework is a total success. JavaScript developments are well structured; using the framework was easy for developers, notably for developers new to JavaScript and the frameworks functionalities were indeed appreciated. Web performances are pretty good and compatibility is assured on a large portion of the browser marketplace.

It’s the current Mercurial “tip” version which is used on this project. As this is very stable, we will tag it very soon as of 0.8.0 final !

Hope this is only the first reference using so many Archetype features ;)

Yes, Archetype is ready for a heavy usage on large websites!

Note: The Geoportal API (http://api.ign.fr/geoportail/) and some parts of the Geoportal website itself (http://geoportail.fr), another institutional French web site, receiving several millions hits a day, both use Archetype as their JS loader ;D

"La rentrée" !

2008-09-06T02:02:00.004+02:00

We have passed some busy summer holidays, and some announcement will come in the next few days. No comment, the content is a surprise :)

As 0.8.0 beta was based upon the (quite deprecated now) Prototype 1.5, the current "tip" works perfectly using now Prototype 1.6.

We originally made a branch in order to implement Prototype 1.6 compatibility as an experiment for the 0.9.0... But I've "mis-committed" (I've stupidly clicked on the bad repository when pushing the main changes) it on the current tip and continued with it.

The 0.8.0 was at this moment quite ready for a release, but we wanted to document a lot more the use of the framework itself. However, my job is to read and correct the documentation and I prefer a lor more coding than correcting a documentation, so... We did not release during the summer.

However a release is yet ready to go out, but based on Prototype 1.6. It has been quite heavily tested, even on the brand new Chrome, and we are hapopy with the result yet. But yet again we lack of documentation for this new release.

So, I think we will release the 0.9.0 before the 0.8.0 final(!!), because getting the 0.8.0 back from the history, test it, etc. will just be a pain compared to the 0.9.0 release.

Between the 2 releases, the main change is jumping from Prototype 1.5 to Prototype 1.6, we have added some handy tools in the 0.9.0, notably for playing easily with URLs.

Now what do we plan for 1.0 ? It depends. We have purposed an internship in our company focused on working on Archetype, in order to give it some cool tools to help for high trafic website, notably to minify the number of hits for loading the page (so mostly helping for bundling JavaScripts, and maybe help for CSS Sprites).

We have started in 0.8.0, the ability to choose what you want for specific part as a backend. We would like in the future version not to rely just on Prototype, but on any good framework we can use as a backend. We have just started a "secret" JQuery branch in order to see what is possible.

Other good news : a cool new open source project about social bookmarks relying only on Archetype to render the application should be there in some months. We've got a cool working beta version of it at Atos Worldline, but we have to do some work in order to release it as a free software ( we mainly have to avoid the use of our SSO for login). The main author of this project has written a very cool JS Code and I hope to convince him joining the Archetype Team :)

Again using Archetype, I've made a "plug&play" (call it widget if you want, but it's not exactly a widget) system in order to use a Solr ( http://lucene.apache.org/solr/ ) as a cross-domain search tool, that you can use on any web page that has a little form with an input and a submit event. I am working now on integrating Opensearch with it if it's possible.

We are very happy with Archetype can do yet, and we hope it's the same for you!

Archetype, "promising" ? :)

2008-09-06T01:57:00.004+02:00

If you particularly follow the JS/Ajax world, you must (or should!) follow Ajaxian ( http://ajaxian.com ).

So let's check some news from Ajaxian today... Hey, but what's new? An article on 10 promising JS frameworks. And you know what? Archetype is here ! :)

The article : http://sixrevisions.com/javascript/promising_javascript_frameworks/

Prototype 1.6 compatible :)

2008-07-11T00:44:00.002+02:00

The new branch for prototype 1.6 is now ok and runs Slidy smoothly, which is a good test application !

I think the patch will be integrated for the 0.9.0 but we still have to do some work for 0.8.0 release before :)

After the 0.9.0 release, I may maintain a Prototype 1.5 compatible version, thanks to Mercurial :D

P.S.: I've mis-pushed the prototype 1.6 patch on the current official tip... will remove it ASAP !

Much more documentation and Prototype 1.6 coming

2008-07-08T21:56:00.003+02:00

Ok, it's a while I've not posted here (again !) but we're still working on Archetype, don't worry :)

Swiip has made so much documentation for 0.8.0 (you can have a look at http://archetypejs.org/snapshot ) that we had to push the 0.8.0 release to some other day in order to do all the checks and reviews needed.

Have you ever wanted a Prototype 1.6 compatibility ? It's almost available on one of my test repo, just pull http://freehg.org/u/temsa/archetype-p16/ with your Mercurial client and try to help me (Slidy is not working right now, and I don't understand why) ;)

Bye bye SVN, hello Hg !

2008-06-16T23:10:00.003+02:00

It's about months I was looking for a better source control manager for coding, experimenting, and hacking Archetype, and we found it !

Our new hero is Mercurial, which will ensure more flexibility and easy cross OS handling with quite good graphical tools for any OS. This is a distributed VCS. So now you can easily start to hack Archetype in your corner and push the result when you want, or do your own patch and maintain it easily. Do whatever you want, you're free :)

Better, Faster, Stronger, we have followed what Mozilla, OpenSolaris, Netbeans and OpenJDK have done some months ago.

Official repository is no more SVN on Sourceforge, but now Mercurial on Assembla . Of course then, we have almost no more interest to keep on staying on sourceforge.net, so we'll probably almost totally move to Assembla.

Archetype 0.8 beta

2008-06-16T22:58:00.003+02:00

After months of work, Archetype 0.8 beta is available, and the stable version is targeted for next week (or at least before the end of june).

Change log includes a lot of rewrites, more modularization, better loading system which ables to go from development to wide band production sites with almost nothing to change to get from one to the other, a proof of concept of Log4J like logging system, multiple template system handling( Basic, EJS, DOMTAL, ...) , heterogeneous template system handling for components, and I think I forget almost half of the feature we've done.

Swiip is focusing right now on giving more documentation for the 0.8 release, including a FAQ, more about Graphical Components, and so on.

Have fun !

Using Archetype as a dependency manager only

2008-03-27T21:15:00.005+02:00

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

2008-03-17T00:18:00.004+02:00

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.