On 3/28/06, Werner Punz <[EMAIL PROTECTED]> wrote:
Yep ... good stuff there too.
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.
I'm game to work on that for Shale. There's a couple of other useful things to do at compile time ... like a tool to audit the configuration files that do exist to catch silly mistakes like wrong class names for managed beans.
Craig
Craig, the Shale Tiger extensions are a good startin point, I read the
docs, and liked what I saw. (I also highly recommend Seam which drives
annotations to the extreme)
Yep ... good stuff there too.
Anyway, having had to hack components again for an extende period of
time I still hate the huge mess the whole component API is in (no
offence to the Sun guys they did their best given that they had to
enforce 1.3+ JDKs)
What I would like to see would be a single controller and view object
with all the taglib binding exposed via annotations instead of having to
drag around an extra tag class, an extra tld and an extra faces-config
entry.
Components for instance are the perfect place to get rid of the xml
defintions totally (which then can be overridden with application level
xml definitions if someone wants to use his own renderer)
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.
I'm game to work on that for Shale. There's a couple of other useful things to do at compile time ... like a tool to audit the configuration files that do exist to catch silly mistakes like wrong class names for managed beans.
With a good use of annotations we could cut down from two xml
definitions and 3 classes, to two classes and 1-2 annotations in the
controller and view.
Which means a total cut down of the code of at least 30% average and a
total cutdown of artefacts from 5 to 2.
Craig
