Hi,
2008/7/8 Andrew Robinson <[EMAIL PROTECTED]>:
> +1 to subproject
>
> -1 to sandbox.
>
> IMO, Dojo should be separated from Tomahawk
+1 for that, but if i understand Werner correct his current
implementation depends on tomahawk.
Regards,
Volker
> 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)
>>>
>>>
>>>
>>>
>>
>
--
inexso - information exchange solutions GmbH
Bismarckstraße 13 | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX: +49 441 4082 355 | www.inexso.de
