Leonardo Uribe schrieb:
I would like to see how tomahawk directory looks like after the
modification, only to take this into account. One question is if dojo
components should be 1.1 or 1.2 compatible (the difference is on the
generation of component and tag classes), or both.
Well for now we dont have too much dojo components in tomahawk, the main
one being the dojo initializer i dont think any other tomahawk component
uses it. The sandbox is a different issue, a load of components use it.
As for the source base. Currently I am running my own code generation
but I will streamline it as soon as you guys are done (I skipped the
parsing stage and used direct object definitions via groovy so that I
dont repeat what Simon and you are doing anyway)
and I had to roll my own templates which I had to do to enable
some base frameworks I had to write to make the entire javascript
generation easier and to streamline some dojo attributes, which
I had to add to the components by delegation (simulated multiple
inheritance)
Streamlining it is just a matter of a few hours to adjust the groovy and
template data structures to the ones in the myfaces codegen.
As for the code itself, I am still targetting 1.1 since it is the most
important release. I dont think 1.2 will get that much momentum that
direct 1.2 targetting makes sense.
1.2 should be possible in the long run. Currenly I have this structure
Base Classes for the main control groups (with delegators doing the
actual work)
-> generated classes which do the attribute mapping
-> hand written derived classes mostly renderer ajustments
A shift towards 1.2 is basically adjustment of the base classes and
adding templates to the generators!
2.0 is a different issue however, but for 2.0 we probably wont need
codegens anymore. (At least from what I have seen from some alpha stage
publications on the web, they are definitely on the right track with
this one)
Another off topic thing
Btw. by doing all this I found out that groovy is an excellent
replacement for data descriptions, way more tight than pure xml, and you
can get the benefit of attribute and typechecking if you use it properly.
What I did was to use a base class as defaults and then use closures (or
constructor maps as you wish) as overrides to the default values.
The result is a very compact data definition which can be used straight
as java objects. I did this to get the data model for the codegens as
fast as possible and not to cross Leonardos and Simons work on that part
with duplicate code.
The groovy approach might be an interesting third approach for code
generation in the long run for myfaces.
