FYI, to parse java source, it looks like there are many utils:
http://java-source.net/open-source/parser-generators
On Jan 30, 2008 3:41 PM, Andrew Robinson <[EMAIL PROTECTED]>
wrote:
> 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
> >
>
>
