Hi, I like the approach. I am not very keen in "annotated" javadocs (which is error prone IMO) but that is just fine and I would say a better alternative to the XMLs (which are rather error prone too). However, it would be nice to have the builder library generic enough so we could use javadocs now and later have an alternative that uses real JDK5 annotations for whoever prefers that approach.
Thanks for the good work! Bruno On 18/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Leonardo Uribe schrieb: > > > > > On Mon, Mar 17, 2008 at 6:05 PM, Andrew Robinson > <[EMAIL PROTECTED]> wrote: > > > > > http://wiki.apache.org/myfaces/MyfacesBuilderPlugin > > > > Is this supposed to be a solution to the code replacement? I don't > > recall any vote to achieve a resolution on how to go about the code > > generation. From what this looks like, it looks worse than the > current > > trinidad plugin. Embedding data in javadoc is really awful IMO. > > > > Or am I mistaken and this is just the tomahawk code builder? > > > > > > This wiki is the idea that Simon proposed for code generation in a > more concrete presentation based on the comments on the mailing list and > the starting code proposed on. > > > > > > https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/skitching > > > > Actually, I have worked a lot with myfaces-faces-plugin (older > trinidad build), I have full component generation for tomahawk 1.1 and > 1.2 ready for commit, and really I think that myfaces-faces-plugin is a > great tool (clear wiki, easy to understand and make it work, but > sometimes a little bit complex doing uncommon tasks). If it was my > decision, I will continue using myfaces-faces-plugin, commit tomahawk, > upgrade components from sandbox and release. > > > > It's clear that all solutions proposed for this issue (Code > Generation) sucks more or less. You're right. There is not a vote about > what should be the direction to take yet, but it's unclear how to manage > this (at least I don't know what to do in this case when some developers > thinks very different). > > > > suggestions about what to do are most welcome > > > The myfaces-builder-plugin stuff is an experiment/proof-of-concept at > the current time, That's why the code is in a "branches" directory. No > vote has been taken on using this approach; it was necessary to show > that this would work before calling a vote to make a choice between this > and the myfaces-faces-plugin (formerly trinidad-faces-plugin) approach. > > But there is enough concrete info there now (particularly thanks to > Leonardo's new wiki pages) for us to have a discussion. It's clear that > the approach will work; now the community needs to say which approach > they think is the most productive for the future. > > I would personally like to see this used for all projects: core1.1, > core1.2, tomahawk, commons and eventually trinidad too. I certainly see > no reason why the myfaces-builder-plugin approach cannot be used for > trinidad. It's just a matter of extending the "model" classes that hold > the metadata. And I see no theoretical reason why the existing .xml > files in the build project could not even be used as input to the > myfaces-builder-plugin (ie as an alternative to doc comments). Note that > the reverse is not true: there is no easy way to use doc comments to > feed metadata into the myfaces-faces-plugin, because that is really > seriously hard-wired to assume that xml files are its input. > > But the most important thing to me *is* getting away from the "build > project with lots of xml files" approach. > > == > > * Use case 1: > > I want to extend the t:inputDate component to add a property to a > component, and alter the renderer to use that property. > > With the xml-files approach (myfaces-faces-plugin), I open the build > project and modify an xml file to add the info using the special xml > tags. I then run the plugin. I then refresh my eclipse project. I then > alter the renderer to access the new property on the generated component > class. Note that just looking at the base component class gives *no* > info about what properties that component has. > > With the doc-annotation approach (myfaces-builder-plugin), I open the > normal tomahawk project, and add an abstract getter method (perfectly > normal java coding). I then add the appropriate annotation as a > doc-annotation. I then modify my renderer (no need to run the code > generator; I can write calls to the abstract method fine). > > And with the doc-annotation approach, looking at the component class > shows clearly that it has that property. In addition: > (a) the amount of info I need in the annotation is much less than I > needed to add to the xml file because the plugin can use introspection > on the abstract method declaration > (b) javadoc comments attached to the method are used automatically in > the .tld etc. > > * Use case 2: > > I create a new tomahawk converter class. > > With the xml-files approach, I open the build project and create some > new xml files. Then I write the converter class in the main code project. > > With the myfaces-builder-plugin approach, I open the main code project, > add the class and add a couple of doc-annotations. > > * Use case 3: > > I create a new project (eg commons widgets) > > With the xml-files approach, I need to create two maven modules, one for > the code and one for the builder stuff. Somehow I need to get access to > all the metadata defined by the core build project (??). I then need to > create metadata files for my project that (somehow) add info about my > new components. > > With the doc-annotation approach, I just create a project for my code, > add the builder plugin to my pom, and add annotations to any of my > converters/validators/components. Done. > > * Use case 4: > > A JSF newbie browses the myfaces-impl code. > > With the xml-files approach, he needs to also browse the xml files in > the build project or alternatively browse the generated code to get any > idea of how things work. > > With the doc-annotation approach, the annotations are there for him to > see on the checked-in classes. > > == > > It looks to me like doc-annotations are more user-friendly in all of the > above use-cases. > > One last note: the Tobago project currently uses real java15 annotations > to gather the data it needs to generate stuff. The > myfaces-builder-plugin can be extended to use APT to gather metadata, > meaning that Tobago could *potentially* use the same plugin if they > wanted. But unless they convert to using xml metadata files, there is no > way for them to use the myfaces-faces-plugin. > > All comments/corrections for the above use-cases or new use-cases are > welcome. > > Regards, Simon > >
