Here is another: http://ws.apache.org/jaxme/js/jparser.html
I think you get the drift... On Jan 30, 2008 4:00 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > >
