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
