+1 to subproject -1 to sandbox.
IMO, Dojo should be separated from Tomahawk and the sandbox is part of Tomahawk, not a play ground for all the different MyFaces libraries. On Mon, Jul 7, 2008 at 2:47 AM, Ernst Fastl <[EMAIL PROTECTED]> wrote: > Hi Werner, > > I think it would be good to have it in MyFaces either as a subproject > or for starter > if anyone feels it might not be mature enough yet in the sandbox. It > would be great > to have it around in tomahawk seeing we could really use some "new fancy" > Web 2.0 components to make tomahawk again more attractive for the end user > in times of RichFaces, ICEFaces, ... > > just my 2 cents > > Ernst > > > On 7/7/08, Werner Punz <[EMAIL PROTECTED]> wrote: >> Hello everyone >> >> as some know, I have been working semi silently the last months in my >> opensource time on a jsf dojo layer which is rather extensive, it is a >> thin layer on top of dojo currently encapsulating around 23-25 of the >> existing dijit components >> (around 98% of the dijit components) >> >> I am reaching the state of being able to opensource the codebase, it >> still is not done yet, but the core is rather stable and a lot of >> components work well enough already so that I am not ashamed of it >> anymore showing it publicly although it is still major road ahead till beta. >> >> One thing, it was planned as tomahawk extension to get dojo out of >> tomahawk, but it is very extensive and the tomahawk dependencies are not >> that much so getting tomahawk out entirely would be possible. >> >> Following: >> >> a) It uses weblets and tomahawk for resource loading and relocation >> (weblets for resource loading, tomahawk for resource relocation) >> >> b) It has its own codegen, which was derived out of the need of having >> to have something fast, and the old ones were very undocumented and the >> new ones not ready. The codegens basically build up a data structure in >> groovy with the component descriptors and then send the data structures >> down into specialized velocity templates. I know we now have a working >> codegen infrastructure, but moving all this over is not my biggest >> priority since my own self rolled parserless solution works very well >> for the scope of the complib and the component descriptors are very tight. >> >> As for jsf currently JSF 1.1 is still the sourcebase, although I test it >> with JSF 1.2, a direct adjustment towards JSF 1.2 can be done thanks to >> the codegens. >> >> Have in mind the codebase I am dropping down is rather huge, with around >> 30.000 - 40.000 locs (Excluding the table) of the components alone most >> of the code being generated, and for now also 1-2 dojo versions in the >> sourcebase until we can move the dojo builds into a separate maven repo >> and load it during the build process. >> >> Also have in mind that currently I drop all generated code into the >> java/src hierarchy in its own dirs with clear comments in the files >> that they should not be added! An approach which would make sense in my >> opinion but others have opposed in the past (I simply love to have the >> sources in one place as much as possible) >> >> Also the table which will be added also will have a large codebase, the >> customer we have developed the table for, has cleared all the apache >> legal stuff, and it is just a matter of getting clearance of the code >> from the legal departement to be able to add it. >> >> A demo of the components will be shown in 1-2 weeks, some people in the >> list have seen some of the components in action already last week. >> >> So my question is, are we going to host it inside of myfaces as its own >> subproject or as part of the sandbox or maybe I can move the codebase >> over to its own project outside of apache (jsfcomp for instance might be >> a perfect place until the entire complib is matured enough) >> >> >> >> >
