On Sat, 2008-03-15 at 15:16 -0500, Leonardo Uribe wrote:
> Ok, so, the big question is how I can help. I have a lot of comments
> and ideas to be taken into account
> about the approach of component generation using annotations.
>
> For example: In trinidad, all components inherits in one way or
> another from UIXComponent, but on
> tomahawk we inherit directly of jsf component classes. We need a way
> to feed this hierarchy of
> properties to be added on the tld. How we can do this using
> annotations on javadoc?
Firstly, I'm not proposing changing trinidad over to a new build system
any time soon, as the current one works for trinidad and it is all set
up for it. I *would* like to make sure that any decision made for
core/tomahawk is something that trinidad *could* use in the future.
I know very little about Trinidad, so am not quite sure what you are
saying here. But if there are "component" classes that should be
generated, but don't inherit from UIComponent then why would there be a
problem?. They can also use annotations, as long as the ComponentModel
class (see plugin code) has suitable properties to store stuff in. Or a
new TrComponentModel could be created to hold that stuff while still
fitting in with the rest of the framework.
>
> What about sandbox (some components inherits from tomahawk
> counterparts), how we can get
> the necessary info for construct the tld?
I added an experimental implementation of exactly this today into the
myfaces-builder-plugin I've added to svn - and documented it :-)
What I'm proposing is that we put a
META-INF/myfaces-metadata.xml
file into each jar built with the custom plugin.
Then when we apply the plugin to some other project, it scans for files
of this name in all the dependency jars; if found then it loads that
data.
So the core-api jar is built with no input myfaces-metadata.xml file,
but the built jar does have one. Then we build core-impl.jar, and the
plugin picks up the metadata file from the core-api.jar as a starting
point. When we build tomahawk, it picks up the metadata file from the
core-impl.jar.
Can you see any scenario where this is not effective?
Note that this file effectively has the same info as the config file
that the build project generates now. We could even use the same
namespaces if necessary, though I don't think the existing plugin's
attempts to half-mimic a faces-config.xml file are helpful. The
differences are:
(a) it is flattened, not full of "xml:include" references
(b) the format of the file isn't tightly coupled to how it was created.
(c) it is part of the jarfile.
The idea is to have a reasonably neutral format that can be created in
different ways, with annotations only being one of them. That allows the
plugin to evolve in the future.
Alternatively, the metadata file could be an extra attached artifact for
builds, rather than embedded in the jarfile. But I like the idea of full
component documentation in the jarfile, rather than the current
situation of partial info scattered across .tld and faces-config.xml
files.
With luck, this might also fit in well with the upcoming JSF spec work
on "metadata for components" which is intended to improve tool support
for JSF. Presumably that will involve a file in META-INF that provides
info to IDEs that the existing .tld or faces-config.xml files are
lacking. I should look into the current drafts..
>
> What happen if we don't want some property inherited be defined on the
> tld? what could be the proper
> syntax?
In the case of the javadoc-comment approach, a class could do:
/**
* @mfp.property exclude=true
*/
public String getStyleClass() {
throw new IllegalAccessError("Unsupported property");
}
or similar. I can't imagine it being very common.
>
> Does the abstract component class be public, or package scope and if
> some properties called by reflection
> are defined on the abstract class public? or if the abstract class is
> public by default better put the generated
> on top and the hand written class on bottom?.
I'm not quite sure what you are asking here. We did a lot of discussion
about this earlier, and I believe your experiments showed that the best
thing to do was to hand-write an abstract package-scope class, then for
a public subclass to be generated.
What I'm proposing will not affect that. I think all the earlier
conclusions still apply.
As I described in an earlier email, annotations can be defined on
methods that are auto-generated via
/**
* @mfp.property .....
*/
public abstract String getStyleClass();
Here we have something that is immediately obvious to normal developers,
rather than having a line in an xml file in some other maven module. The
code-generator then just creates the method in the concrete subclass.
The compiler will even check that it has been done right!
>
> My intentions is do a release of tomahawk with component generation
> and 1.2 modules. I just putting all
> my efforts to to that. I know that this is a community work, so I'm
> open to all suggestions.
Agreed. We both (and many others) want to make building myfaces projects
easier and more consistent. And what eventually gets committed must be
the community consensus, not your decision or mine.
The bit I'm somewhat embarrassed about is that I'm suggesting to the
community to hold off on implementing a solution that is known to work
in order to wait for a solution that is not yet implemented. But I am
working on it, and if others join in then it will go even faster.
Implementing a solution, debugging it, documenting it, then backing it
out and replacing it with something else would be really disappointing
though, so it would be really nice to get this right the first time.
Note that this comment applies equally to my proposal, if people think
that there are flaws in it.
Re how to move forward from here:
Leonardo, the questions you asked above are a great start; if there are
problems with the approach I'm suggesting it would be good to find them
now.
If you could have a look at the code currently in
https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/skitching
and read my recent emails then post any difficult questions you can
find, that would be great. Note that the plugin code has some
introductory design docs in the src/site dir.
And if you have time, you could perhaps help with getting the code I'm
working on running so that we can then really look at which solution is
more elegant to use in practice.
Regards,
Simon
