For what it's worth, I've found Shale-Tiger to be quite stable. There are
a few features missing, but it is working well for me. To me, it would
certainly not be worth the effort to re-implement the same functionality
just because the rest of shale isn't stable.
If you don't feel comfortable adopting Shale-Tiger, then you might want to
at least takea look at their code because they have all or most of that
functionality already working.
http://struts.apache.org/struts-shale/shale-tiger/apidocs/index.html
Adam Brod
Product Development Team
Mik Lernout <mik_at_futurestreet.org>
06/20/2006 10:47 AM
Please respond to
users_at_javaserverfaces.dev.java.net
To
users_at_javaserverfaces.dev.java.net
cc
Subject
Adding an annotation based managed bean creator for JSF 1.2
Hi there,
I would like to create a very simple annotation based ELResolver to
be deployed on the JSF 1.2 RI and using the unified EL. I want to
support just the following features at this stage:
* Annotate java classes with @ManagedBean(name, scope) and
properties with @ManagedProperty(value)
* Satisfy the requirements denoted by the annotations at runtime
* <Optional> Be able to override the annotated annotation for a
managed bean name, with a traditionale faces-config one
This kind of overlaps with the Shale Tiger support library, but I do
not want to use something that is that bound to Shale and/or so early
in development: I'd rather reduce the functionality until it is
controllable. I was wondering if any of you guys have an idea on how
I should best approach this.
While I did have a good grip on the VariableHandler /
PropertyHandler, I am a bit confused by ELResolvers,
ManagedBeanELResolvers and ManagedBeanFactoryWrappers of the unified
world :-). Note that I would like to reuse as much of the code that
exists, and I definitly want to avoid writing yet another big if-else-
if block to put the managed beans in the correct scope or to get them
out again. There must be a better way!
To recap: I know how to do this, I am just wondering what would be
the cleanest, most reusing way of implementing this.
BW: I would also love to share it on java.net when it is ready and
even commit to improving it. I think a lot of people would kind of
like it :-)
Kind regards,
Mik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: users-help_at_javaserverfaces.dev.java.net
Disclaimer: This electronic mail and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify the sender immediately by replying to this email, and destroy all copies of this email and any attachments. Thank you.