My proposal:
To simplify let me use <my:foo> that should be used to create
MyFooComponent.java. I want to customize the broadcast method of this
component.
One alternative (my choice), as already mentioned is to have the plugin add
code to the class. Instead of using something like:
/* START AUTOGENERATED CODE */
/* END AUTOGENERATED CODE */
The code could produce:
@Generated
private boolean _foo;
@Generated
public boolean isFooSet() { retun _foo; }
Then the plugin simply removes any artifact annotated with "@Generated" and
inserts the new code. If you wanted to preserve the layout of the file, new
items could replace old items when found, and append all new items that were
not there before (or if the signature changed) and delete any old methods
that no longer should be there.
Honestly, this is not that hard to do. Writing linux shell scrips in perl
and python can be a lot more challenging that this. Yes it may require some
java syntax parsing.
Another choice is to use the current method but with some cleanup:
Current method:
File:
my-api/src/main/java-templates/com/mycompany/faces/component/MyFooComponentTemplate.java
Code:
package com.mycompany.faces.component;
/* imports */
public abstract class MyFooComponentTemplate
extends UIXComponentBase
{
/**/ abstract public boolean isFooSet();
@Override
public void broadcastEvent(FacesEvent event)
{
super.broadcastEvent(event);
if (isFooSet())
{
// custom code
}
}
Maybe this instead?
File:
my-api/src/main/java-templates/com/mycompany/faces/component/MyFooComponent.java
Code:
package com.mycompany.faces.component;
/* imports */
public abstract class MyFooComponent
extends UIXComponentBase
{
@FacesPluginIgnore
abstract public boolean isFooSet();
@Override
public void broadcastEvent(FacesEvent event)
{
super.broadcastEvent(event);
if (isFooSet())
{
// custom code
}
}
I don't see a good reason for adding "Template" to the end, it makes inner
classes worse (ie MyFooComponent.this.queueEvent()) and makes the code
harder to find.
The annotation would be a dummy annotation, but would be a bit clearer. As
long as an IDE doesn't complain about 2 instances of MyFooComponent (one
generated, on in the templates folder) then this would work. All the plugin
would have to do is append to the class (inside the last curly brace) and
remove abstract from the class definition.
On Jan 30, 2008 1:12 PM, Martin Marinschek <[EMAIL PROTECTED]>
wrote:
> Hi Andrew,
>
> On 1/30/08, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> > -1 for a dummy abstract parent class. The resultant OO structure is not
> > clean. I would rather see a cleaner way to merge the "template" with the
> > generated code.
>
> ok - then please suggest one. This is all about finding a clean way,
> and we are at this point as we haven't found another clean way to do
> it so far.
>
> we do not have mix-ins in Java!
>
> regards,
>
> Martin
>
