5:12 p.m.
I just ran across this when using the Builder pattern in some Pojos --
each setter returns the current instance of the pojo to allow for
chaining set-statements:
Pojo pojo = pojo.setName("name").setValue(23);
With setters implemented like so:
public Project setName(final String name)
{
this.name = name;
return this;
}
But JSF complains:
javax.servlet.ServletException:
javax.el.PropertyNotFoundException: /faces/page.xhtml @36,20
value="#{pageBean.pojo.name}": Property 'name' not writable on type
java.lang.String
It seems to me that this is a slightly harsh restriction. Is there
anything we can/should do about this? Does anyone else feel it's worth
mentioning?
The obvious answer is to use dumb getter/setter methods, but in some
cases that can be restrictive, and I like the idea of being more
forgiving.
Thoughts?
--Lincoln
6:07 a.m.
New subject: [jsr-314-open] EL property accessor name Forgiveness / Flexibility
I'm with Lincoln here - sounds like an obvious, easy, improvement can
be made to EL here...
On 21 Jul 2009, at 23:12, Lincoln Baxter, III wrote:
I just ran across this when using the Builder pattern in some Pojos
-- each setter returns the current instance of the pojo to allow for
chaining set-statements:
Pojo pojo = pojo.setName("name").setValue(23);
With setters implemented like so:
public Project setName(final String name)
{
this.name = name;
return this;
}
But JSF complains:
javax.servlet.ServletException: javax.el.PropertyNotFoundException: /
faces/page.xhtml @36,20 value="#{pageBean.pojo.name}": Property
'name' not writable on type java.lang.String
It seems to me that this is a slightly harsh restriction. Is there
anything we can/should do about this? Does anyone else feel it's
worth mentioning?
The obvious answer is to use dumb getter/setter methods, but in some
cases that can be restrictive, and I like the idea of being more
forgiving.
Thoughts?
--Lincoln
11:30 p.m.
New subject: [jsr-314-open] EL property accessor name Forgiveness / Flexibility
A setter method 'void' return value is a part of the JavaBean contract.
I guess that modification of the setter method pattern would also
confuse many other Java Bean libraries like apache-beanutils, some EJB
3.x containers and so on. I do not think what an one JSR specification
should violate any other, especially so wide used as JavaBeans are.
On 07/22/2009 04:07 AM, Pete Muir wrote:
I'm with Lincoln here - sounds like an obvious, easy, improvement
can
be made to EL here...
On 21 Jul 2009, at 23:12, Lincoln Baxter, III wrote:
> I just ran across this when using the Builder pattern in some Pojos
> -- each setter returns the current instance of the pojo to allow for
> chaining set-statements:
>
> Pojo pojo = pojo.setName("name").setValue(23);
>
> With setters implemented like so:
>
> public Project setName(final String name)
> {
> this.name = name;
> return this;
> }
>
> But JSF complains:
> javax.servlet.ServletException: javax.el.PropertyNotFoundException:
> /faces/page.xhtml @36,20 value="#{pageBean.pojo.name}": Property
> 'name' not writable on type java.lang.String
>
> It seems to me that this is a slightly harsh restriction. Is there
> anything we can/should do about this? Does anyone else feel it's
> worth mentioning?
>
> The obvious answer is to use dumb getter/setter methods, but in some
> cases that can be restrictive, and I like the idea of being more
> forgiving.
>
> Thoughts?
>
> --Lincoln
10:43 a.m.
New subject: [jsr-314-open] EL property accessor name Forgiveness / Flexibility
On Thu, Jul 23, 2009 at 12:30 AM, Alaxander Smirnov <asmirnov(a)exadel.com>wrote:
A setter method 'void' return value is a part of the JavaBean
contract. I
guess that modification of the setter method pattern would also confuse many
other Java Bean libraries like apache-beanutils, some EJB 3.x containers and
so on. I do not think what an one JSR specification should violate any
other, especially so wide used as JavaBeans are.
I have always objected to the claim that getters and setters come from the
JavaBean contract. That relationship is so loose one can only say that it is
a van der Waals-like relationship. Okay, so we steal this idea of deriving a
property from an object by removing get or set prefixes and lowercase the
following letter, with the exception of a primitive boolean in which the is
prefix is stripped as an alternative to get. The relationship to that
specification then trails off into the ether.
The real spec that we are following is the yet undefined Java properties
specification. What does it take for there to be a property? As Lincoln
suggests, the return type on the setter should not be considered. Maybe even
annotations can be used as an override of these defaults.
So the rules would be:
getter: a no arguments method whose name is formed by captializing the
property name and prepending "get" with a return type equivalent to the
property's type
setter: a single arguments method whose name is formed by captilizing the
property name and prepending "set" and whose argument type is equivalent to
the property's type (no restriction on return type)
Annotations, like in JAX-RS, can be used when these defaults are not
sufficient for the class composition used by the application.
Btw: I think the who idea of the "is" prefix for primitive boolean types is
half-assed and insufficient and should be supported only for backwards
compatibility.
Lincoln, as far as I can tell what you are attempting to do is legal if you
have JBoss EL loaded. JBoss EL is much more flexible about what is allowed
and is hopefully a preview of EL 2.2.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
5399
days inactive
5402
days old
jsr-314-open-mirror@lists.jboss.org
3 comments
4 participants
participants (4)
-
Alaxander Smirnov -
Dan Allen -
Lincoln Baxter, III -
Pete Muir