Adam Winer schrieb:
On 3/29/06, Werner Punz <[EMAIL PROTECTED]> wrote:
Craig McClanahan schrieb:

I was constrained in the stuff so far by what could be accomplished at
runtime -- and there's no way to define a tag library "on the fly" at
that point.  But what you're describing could certainly be done by
processing annotations at compile time instead (using "apt" or
equivalent).  That'd be an interesting area to explore, over and above
the runtime stuff.

Yes I was talking exactly the same issue over with Mario, definitely an
area which as to be explored for the next JSP version, but for now
having artefact codegens, via apt (probably a viable choice since it
will be in 1.6 officially anyway) or via xdoclet2 and or velocity would
be a good idea. The main point is just to have something which cuts down
on the number of manual maintain artefacts. If there are codegen
artefacts does not really matter.

Code-gen'd artifacts *do* matter, because they contribute to the
rebuild, redeploy mess that we're in now.  No codegen'd artifact is
better than the absence of that artifact in the first place.

Not that I'm against codegen - the ADF Faces code uses it extensively
- one source of metadata is used to generate the component class,
faces-config, the JSP tag, the TLD, the facelets taglib, and our docs.

Adam we are talking pretty much about the same area where codegens make absolute sense, as you said you applied the adf codegens to the component boilerplate code, which always more or less is the same. Now if we had a mechanism via xdoclet annotations or something else which could generate the taglib tlds, the taglib class and the facelet definitions out of a single component class, this would cut down on component development time at least 30%. To my understanding as John told me a while ago you went the opposite approach you started with a config file to generate the component skeletons, feasable, but I think having the boilerplate jsp code generated is a bigger timesaver, ideally a combination of both (skeleton generation for a kickstart, and optional boilerplate generation for development) probably would be the fastest. Anyway I am talking theoretically here anyway, I just have applied similar techniques several times, and could cut down on development time tremendously (one application had about 50% codegen coverage, pretty much the same amount could be achieved for standard components, in my opinion)

Reply via email to