Hi Zdenek, you seem to ignore my comments - you will need to provide the setters, this is in the spec - and there is component-binding, so you need to provide them?
The issue with state-saving will need to be saved another way. regards, Martin On 3/18/08, Sochor Zdeněk <[EMAIL PROTECTED]> wrote: > Hi all, > comments inline. > > [EMAIL PROTECTED] napsal(a): > > > > 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. > > > Generally extending components by adding whole bucket of local > property/getter/setter seems not right for me because > it's meant to provide just another feature not used by many people. > Wouldn't it be more cleaner to just use that property as attribute (in > JSF api's speach): > storing/using it from getAttributes() map? > This way it would just be needed to generate TLD/Tag entries, no > customization of component's code needed. > Also renderer has full access to attributes map by default ;) > Nice side-effect to this approach is eventual speeding-up processing by > adding cache to getAttributes() MyFaces map: > storing already resolved values in transient map to avoid multiple > resolving during lifecycle. > > * 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. > > > > > Clearly 2nd option rules :D > > * 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. > > > > > A question about properties inheritance accross components arise: > i really think that having the same propetry handled by multiple > components in hiearchy is bad (quite common in Tomahawk). > Also the Tomahawk code should use consistent way in components and tags > inheritances. > There should be a way to filter already defined properties in either > approach. > > * 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. > > > > > This use-case is not clear - it's quite different to look at code to see > how components work and to look at renderers' stuff. > IMO more people are interested in renderers, so both approaches are > almost the same for them. > > == > > > > 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 > > > > > > > Regards, > Zdenek > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
