Don't forget that components are just one of the items generated. It is not wise to make any architectural changes w/o considering all of the artifacts the plug-in generates.
On Jan 30, 2008 12:34 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > To summarize: > > The objective is to look if we can generate component, tag, > faces-config and facelets files using > a better approach than the actual behavior of myfaces-faces plugin. > > > The full idea could be this: > > > > - Create an abstract component class that contains all info. > > - Create some files where we can get the additional info. > > - Generate a component class that extends from this abstract class. > > - Generate tag, add info to faces-config and tld based on this info. > > > > This suppose a hard work but this approach could be easier than the > > actual behavior. > > This idea could be a possible way to avoid xml files and use abstract > component classes > and annotations like Mario suggested. > > > For sure, I thought we can generate the stuff and then commit the > > generated files, so no need to regenerate for each build, just when > > something in the component config changed. > > > Yep, this just works nicely if we go the abstract component route, no? > else you'll lose all changes you applied on the generated code. > > If we can use abstract component classes with annotations, It is > possible that we can > avoid template classes, because all custom code should be on the > abstract component class. > > > > > IMO, the best solution is where the code checked in to svn > *compiles*. > > IDE auto-completion, refactoring, all the other tools that work only > with > > *real* code will then be usable again. > > > > > > Ok, why not have the generated base-classes in the source of your > compiler? > > If you redirect the generated classes to src/main/java, you have this. > > regards > > Leonardo Uribe >
