Okay, feel free to flame.
Possibility of merging annotations w/ code generation:
@Component(
type = "...",
family = "...",
rendererType = "...",
tagClass = "...",
events = {
@ComponentEvent(
type = "...",
phases = { "...", "..." }),
...
)
public abstract class MyComponent extends UIXComponent
{
@ComponentProperty(
description = "or is this better in javadoc? -- harder to code the
generator, but easier to document",
extensions = {
@PropertyExtension(name = "preferred", value = Boolean.TRUE),
@PropertyExtension(name = "...", value = "...")
})
private String _foo;
@ComponentPropertySkel
public abstract String getFoo();
public void broadcast(FacesEvent event)
{
// custom code
}
}
This would be in a pre-processing folder of maven (not src/main/java). The
plugin can then take this file an build the concrete class from it.
This is basically the same as the trinidad approach but it merges the xml
with the template.
This way you don't get tedious xml like:
<property-extension>
<mfp:method-binding-signature>
<mfp:return-type>java.lang.String</mfp:return-type>
</mfp:method-binding-signature>
Just a thought.
-Andrew
On Jan 31, 2008 3:59 PM, Martin Marinschek <[EMAIL PROTECTED]>
wrote:
> Hi Simon,
>
> Ok, as promised here is the wiki page summarising the recent email
> > thread. I hope I've got everybody's opinions fairly represented, but of
> > course if corrections need to be made - hack away!
>
>
> I've added and clarified where I thought it was appropriate.
>
> Personally I'm keen to try to build something along the lines I was
> > proposing - but first need to help get a new Orchestra release out.
>
>
> If you can solve the problem with restore-state and save-state and your
> solution does not decrease runtime performance, and you show me a compact
> way of including all meta-data in annotations, I'd be very grateful to see
> you hack away! However, we should discuss the options we have for getting
> the restore-state and save-state problem fixed first - I am pretty sure we
> will not find one if we want to extend from the JSF base classes.
>
> There isn't any hurry on getting this tomahawk build process sorted is
> > there? I don't see any reason why tomahawk 1.1.7 cannot go out with the
> > current build process..
>
>
> I do not see a reason why it should - especially as even the
> trinidad-based approach will make it easier for you to work on your
> component-based approach, cause you can then generate your generator
> base-classes with the generator and don't have to go through all
> component-classes. Work that Leonardo has already done for you. We need to
> switch to using a generator - improving the way of generating things is then
> easy. I also need a generator cause I finally want to improve the
> performance in the components - and for checking out several ways of doing
> this, it is necessary to have a generator (except we find a solution along
> your lines with regards to restoreState/saveState).
>
> regards,
>
> Martin
>
