Hi Zdenek, *saved=solved
regards, Martin On 3/18/08, Martin Marinschek <[EMAIL PROTECTED]> wrote: > 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 > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
