Simplify??? This code generation stuff does make code more *consistent* between the various bits (taglib, faces-config, java) but definitely does not make it simpler to work with. IMO, it introduces a whole new set of concepts that will make it harder for new developers to get into this code.
I wouldn't want to start a whole new jsf widget library with the old approach of manually synchronizing everything, but as Tomahawk is already set up that way I don't see any benefit in tearing it all down and rebuilding. In the existing way, anyone who knows jsp taglibs can add a new attribute to a component. It's a lot of typing but fairly simple. With the new code generation, they have to learn the custom myfaces build tools... Regards, Simon ---- Bruno Aranda <[EMAIL PROTECTED]> schrieb: > I think if something simplifies the maintenance of tomahawk I welcome > it. Moving stuff to commons and all that is an early idea and I have > not read specific plans about how we could do that, who could do that, > so I guess it will take a while to go. In the meanwhile, if we can > just remove some of the complexity of tomahawk, that is great, and a > simpler thing will motivate component authors as well. > Using the component generator may facilitate as well to bring the > tomahawk components closer to trinidad and viceversa, > > Cheers, > > Bruno > > On 30/01/2008, Simon Kitching <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Well, the first question to ask is: what do we want to release in the near > > future? > > > > I think the next Tomahawk release should be 1.1.7, containing bugfixes and > > a few promotions from sandbox. It should not contain radical refactoring of > > the build process. > > > > In the longer term, I believe we are planning to move a bunch of existing > > code out of Tomahawk into commons. So then Tomahawk will not be a drop-in > > replacement for the old one, as pages referencing t:foo will then have to > > reference some new commons tag that provides the equivalent functionality. > > > > There is also stuff in tomahawk that needs cleaning up. For example, IMO > > the inputCalendar should be two tags; one for popup and one not. Having > > them as a single component is a major headache. > > > > And there are lots of other cleanups that could be made, eg removing bad > > ideas (I think forceId is one thing that should go completely, replaced by > > a more generic solution). > > > > So if we are going to make a non-backwards-compatible release of Tomahawk > > code, then it seems to me that we should look at whether what is left would > > cause confusion by inheriting the tomahawk name. If we only factor out 10% > > into commons, and only make significant changes to another 10% of tags, > > then yes the existing name might be reasonable. But if major changes are to > > be made, then we must change the taglib namespace and java package-name > > otherwise the new code and the old code cannot live together in the same > > app. And the easiest solution to that would be to call this significantly > > new lib something else - eg "commons ui widgets". > > > > I *do* like much of what is currently in tomahawk, and am not suggesting > > throwing the code away. But if a major refactor is applied, then we > > probably need a new name. > > > > And re the code-generation stuff: personally I don't like it at all. Agreed > > it does suck less than the old approach, but it still is ugly. I'm hoping > > to find time to experiment with some alternatives. Now of course I'm not > > suggesting that everything stop until I deliver a wonderful new solution > > :-). However given that 1.1.7 is the short-term goal, and 1.2 is > > questionable it doesn't seem a good time to be doing all that work on a > > Tomahawk 1.2 build system. > > > > Regards, > > Simon > > > > > > ---- Martin Marinschek <[EMAIL PROTECTED]> schrieb: > > > Simon, > > > > > > is your conclusion then that Tomahawk should die? > > > > > > To be honest, my perception is quite different from this. > > > > > > We have a large user-base, and I'm certainly all for keeping Tomahawk > > > up-to-date as much as possible and still improve it where we can. > > > > > > And, I generally don't see the use of having 10 different ways of > > > maintaining components in MyFaces, the first step to a more > > > maintainable Tomahawk-component-set must therefore be to change the > > > build-system to the one used by MyFaces 1.2, Trinidad and (hopefully > > > also) the new commons library! > > > > > > regards, > > > > > > Martin > > > > > > On 1/30/08, Cagatay Civici <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > > > > > As being the guy who has created the tomahawk 1.2 branch and spent a > > > > lot of > > > > time with it, upgrading to 1.2 is not an easy task because as Simon > > > > mentioned the code is old and crusty. > > > > > > > > I agree that non rendering stuff should be moved to commons, I've some > > > > candidates on my own from sandbox and tomahawk for commons. > > > > > > > > For autogeneration, one must generate all the component metadata, this > > > > all > > > > has been discussed on ML by the way. > > > > > > > > I still think tomahawk 1.2 makes sense. > > > > > > > > Cagatay > > > > > > > > On Jan 30, 2008 11:02 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi, > > > > > > > > > > On Jan 30, 2008 9:53 AM, Simon Kitching <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > > > > > > > I see Leonard is currently doing a lot of work on something called > > > > > "tomahawk 1.2", which surprised me a little. > > > > > > > > > > > > I have checked the mail archives, and see some discussions happening > > > > > around june 2007 regarding having a version of tomahawk specifically > > > > > for > > > > > JSF1.2. > > > > > > > > > > I saw the activity on tomahawk 1.2 as well, and was also a little > > > > > surprised, since nothing regarding that has been discussed here on the > > > > > ML. > > > > > > > > > > > > > > > > > But since then, we have started "apache commons". I think therefore > > > > > > that > > > > > rather than have a tomahawk 1.2, it would be better to split tomahawk > > > > > up > > > > > into pieces that live in "commons" modules, or at least extract all > > > > > the > > > > bits > > > > > we can, then call the remaining bits something other than "tomahawk". > > > > > > > > > > +1 that sounds good; > > > > > > > > > > commons can be used in a wider range (like in tobago, trinidad, > > > > > ice-faces, > > > > > ...) > > > > > the additional UI comps (like nice (dojo-based) tables etc can become > > > > > Tomahawk) > > > > > also worth to check for promotions of the sandbox (was recently > > > > > already discussed), like > > > > > the PPR stuff. > > > > > > > > > > > > > > > > > Tomahawk code is really rather old and crusty and I don't see a lot > > > > > > of > > > > > point moving it as-is to JSF1.2. > > > > > > > > > > > > Getting a release of tomahawk 1.1.7 out, however, would be a very > > > > > > good > > > > > idea. > > > > > > > > > > +1 here as well > > > > > > > > > > -Matthias > > > > > > > > > > > > > > > > > Regards, > > > > > > Simon > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Matthias Wessendorf > > > > > > > > > > further stuff: > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > > sessions: http://www.slideshare.net/mwessendorf > > > > > mail: matzew-at-apache-dot-org > > > > > > > > > > > > > > > > > > -- > > > > > > http://www.irian.at > > > > > > Your JSF powerhouse - > > > JSF Consulting, Development and > > > Courses in English and German > > > > > > Professional Support for Apache MyFaces > > > >
