> the interesting question (which you're posing) is how to make
> JSF better tomorrow than it is today.
Exactly! Simplifying some action-style interactions just makes the framework richer and expands its usefulness.
Adam Brod
Product Development Team
| "Adam Winer"
<[EMAIL PROTECTED]>
04/14/2006 06:10 PM
|
|
On 4/14/06, Adam Brod <[EMAIL PROTECTED]> wrote:
>
> Adam-
>
> I don't think your response is quite what I was getting at. In Struts
> world, I have lots of ugly code sprinkled everywhere that converts request
> params to very low-level custom objects in our system (for example, Enums
> for statuses, types, and flags as well as other objects like Identifiers,
> Credit Card Numbers, EmailAddresses, etc.), When using JSF post-backs, we
> can use Converters to handle all that boiler-plate request param -> object
> mapping. If using JSF with GET requests, we cannot use converters, can we?
For JSF 1.2, you'll have type coercion - but that only gets you
to primitive types. There's no direct support in the EL APIs for
extending the type coercion semantics. I think you could do so with
a particularly clever AOP layer on top of a managed bean.
Or, more elegantly, use an ELResolver (or PropertyResolver in 1.1)
that knows how to go from a String to a particular type of object;
make that resolver dynamically hooked up to metadata that
is per-page specific (or annotation-based), and you can cleanly
automate a lot of this.
So, for instance, you could work towards a system like;
/**
* @requestParameter mailto
* @convertOnSet mypackage.foo.EmailConverter
public void setEmail(EmailBean bean)
... that would automate all of that conversion.
> If my understanding is correct, that is a definitely limitation of using GET
> with JSF.
True. The question on our plate was whether JSF is worse
than other frameworks, and based on your description above of
all the nastiness in Struts, we definitely have one counterexample.
But the issue of whether JSF is worse or better is basically
a question most suited for another pointless "smackdown", and
the interesting question (which you're posing) is how to make
JSF better tomorrow than it is today.
-- Adam
