Hi Martin,
Martin Marinschek napsal(a):
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?
Sorry, just one misinterpretation.
The talk in use-case 1 was about *new* property.
I wasn't talking about spec's defined *properties* (and in spec only),
they are set in stone as value/setter/getter, but all other "things" are
up to developers:
they can either define them as *properties* or *attributes*.
Even html renderkit defines *attributes*, not *properties*.
IMO distinction between *property* and *attribute* lays in this -
property is needed for component's basic functioning, attribute is to
extend behavior or look.
This means that writing all *properties* in components is done only once
(they don't and can't change), everything else should be *attribute* in
map. (that way all saving/restoring is done by default).
The only drawback in this is to rewrite renderers and user's custom code
to access values from map, not directly by calling getters.
Anyway, why should i provide setter for *attribute*?
For this i can use jsp tag or facelet taghandler to access map as well
(if it's accessing *property*, respective setter will be called from
map's implementation by default)
And regarding component-binding - it's *property* per spec.
BTW, why should i ignore constructive and inspiring comments??
Regards,
Zdenek
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
