Hello Simon,
simon schrieb: > Hi Bernd, > > On Thu, 2008-03-13 at 03:31 -0700, Bernd Bohmann (JIRA) wrote: >> Generate Components, JSP Tags from annotations > > Well, it seems like rewriting build systems is the trendy topic this > month :-) I wondered why you were smiling this afternoon while tapping > away on your keyboard; now I know. I'm smiling everytime :-) > > As there are now several people (you, myself, leonardo) working on new > build ideas, perhaps we (and anyone else interested) should pool our > ideas together? Yes, we should pool the ideas together. But I think let speek the code. > > Do you perhaps have any design documents describing how your new build > system works? I have had an initial look at the code, but am not > currently completely clear how things fit together. Of course I haven't > had any time to write up docs either; and I'm still experimenting > (committing on a branch, rather than committing to trunk as you are > doing). The build system is not new. I just extend the build system to generate the UIComponents, Tags and RendererWrapper. The former version generates the faces-config.xml and the tlds and Facelets configuration. > > The commits you made touch a lot of code; it seems to me that they > include patches for several unrelated things including adding ajax > support, making UIPanel a NamingContainer, etc. Is this right? For the faces-config and tld we don't need this kind of information. But for generating the components I need more metadata. > > I see some of the patch is removing saveState/restoreState methods, > which I presume is because these methods will be auto-generated later. > But I don't see removal of any Tag classes, which I would have expected > given the title of this commit. Is this coming later or have I > misunderstood something? I would like to ensure that it's save to delete the old code. > > Here's some points/questions I have after reading the code: > > (1) > You appear to be using ".stg" files as templates for code generation. > Does this stand for "org.antlr.stringtemplate.StringTemplateGroup"? > > http://www.stringtemplate.org/doc/api/org/antlr/stringtemplate/StringTemplateGroup.html > > Why did you choose this as a templating engine? Is it better than > Velocity or xslt for this task, or because you are more familiar with > it? The only reason is I don't like velocity. I think we can choose a different templating engine. > > (2) > The CreateComponentAnnotationVisitor class appears to be using the > StringTemplateGroup files to generate output. > > The CreateComponentAnnotationProcessor class first "visits" each > annotated object, effectively gathering needed metadata. > > Then CreateComponentAnnotationVisitor.process is then invoked to iterate > over the gathered data and apply it to the template. The createRenderer > method generates a renderer java file, and the createTag method > generates a tag java file. > Yes > (3) > You appear to be using the info from the annotations pretty directly to > generate the artifacts. Tag annotations contain the information used to > generate Tag classes etc. > > Yes > > > This is really not very different from what I would like to achieve with > the work I am doing. And really not too different from what the current > trinidad-derived build process currently does either. > yes > The issue I have is that the trinidad-based approach is very tightly > coupled to the concept that the input is an xml file in > almost-faces-config.xml format. Sadly, I just cannot plug into it to > provide an alternative way of building metadata. > > And it looks to me like your code is also very tightly coupled to the > concepts of the sun APT processor, and again cannot be extended to allow > other ways of building the metadata. > > What I would like to see (and am working towards) is a neutral format in > the middle (see ComponentModel, RendererModel, etc classes). Then > anything can populate this model (apt annotations, xml or doclet-tags). > The code just implements ModelBuilder and then fetches the data however > it wants. A Common Model would be nice, but I think it's not a easy step. > > And equally I hope to have a simple ModelProcessor interface. Then > multiple different implementations of that can exist, eg one that > uses .stg files to generate classes, or one that uses velocity to > generate facelets-taglib.xml files, or ... Yes > > Of course the common metadata representation would need to be carefully > chosen. For example, I would hope to avoid explicitly modelling "tag" > information; I regard that as something that can be derived from > information about the hand-written classes rather than something that > classes should explicitly declare. Therefore I would not personally have > a TagModel class. However that can certainly be debated, and there is > room for compromise I'm sure. > > Unfortunately, I cannot see how to apply the Tobago approach to myfaces > core, tomahawk, trinidad etc. The newly committed tobago code is very > tightly tuned to the needs of tobago at the moment. And in addition, I'm > really not convinced about the use of APT. But with the architecture I > described above, that doesn't matter. Different front-ends (apt, qdox, > xml) can be used while still the rest. > > Is this an approach that you think would be beneficial to Tobago, or > would you prefer to keep tobago's build solution separate and tuned > exclusively for Tobago? Yes, this would be benefical for Tobago. > > Regards, > Simon > > Regards Bernd
