RE: OGNL PropertyAccessor and null handling best practices

2007-04-02 Thread Hoogeveen, Erik
What I usually do is to use a method in de page that retrieves the right
value if it's there. That method does the null handling I need for the
value I want to display. If there's a null somewhere it can just return
an empty string or something like that.

Furthermore if I use only an ognl expression I try to keep them rather
shallow, so they don't traverse to deep into de object model. This is
not only because of null checking though, it also makes refactoring
easier (you don't get compiler errors on ognl expressions).
 
--
Water, taken in moderation, cannot hurt anybody.
-- Mark Twain -- 

-Oorspronkelijk bericht-
Van: Martino Piccinato [mailto:[EMAIL PROTECTED] 
Verzonden: vrijdag 30 maart 2007 11:53
Aan: Tapestry users
Onderwerp: OGNL PropertyAccessor and null handling best practices

Hi,

I think this issue has been discussed before on the list, I've read some
message somewhere but wanted to ask about more feedback on best practice
on
this.
The problem is handling nulls with OGNL while navigating the object
graph,
that is: getting bad NPE if one of the object of the navigation chain is
null.


Basically there are two solution to the issue:  add (a lots, in my case
as
we have a quite complex object model) null checking methods to my
components/pages
or just configure tapestry to use a forgiving OGNL PropertyAccessor that
would return null for any method to be invoked on a null (I actually
don't
like NullHandlers that create empty model objects and actually I'd
prefer
not to have public no argument constructors or creating empty objects
just
for this).


I was just wondering how you deal with this and if you have particular
suggestions.

Thanks

Martino
*** Waterschap Aa en Maas, met water in de weer! ***
Kijk voor meer informatie op www.aaenmaas.nl


Disclaimer:
Dit e-mail bericht is slechts bestemd voor de (rechts)persoon aan wie het is 
gericht en 
kan informatie bevatten die persoonlijk of vertrouwelijk is en niet openbaar 
mag worden 
gemaakt krachtens wet- of regelgeving of overeenkomst. Indien een ander dan 
geadresseerde
dit e-mail bericht ontvangt of anderszins in handen krijgt is hij niet 
gerechtigd tot 
kennisneming, verspreiding, openbaar maken of vermenigvuldigen daarvan. Hij 
wordt verzocht
onmiddellijk waterschap Aa en Maas telefonisch (telefoon: +31 (0)73 615) op 
de hoogte 
te stellen en het e-mail bericht te vernietigen. Waterschap Aa en Maas staat 
niet in
voor de juiste en volledige overbrenging van de inhoud van een verzonden 
e-mail, noch voor 
tijdige ontvangst daarvan. Dit e-mail bericht brengt geen enkele contractuele 
gebondenheid 
voor waterschap Aa en Maas tot stand.

Dit e-mail bericht is gecontroleerd op Virussen.
##

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OGNL PropertyAccessor and null handling best practices

2007-04-02 Thread Martino Piccinato

Yes, you are right this is for sure the most correct approach in theory and
the approach I've tried to have until now but I have to admit a couple of
things:

1) 100% of the wrapper page methods just returns nulls on null (what the
null PropertyAccessor would do)
2) due to my relatively complex model this ends up in a lot of boilerplate
code

At the end I think I'll still try to keep the in page null-checking approach
but it's interesting to know how other people are going with this.


On 4/2/07, Hoogeveen, Erik [EMAIL PROTECTED] wrote:


What I usually do is to use a method in de page that retrieves the right
value if it's there. That method does the null handling I need for the
value I want to display. If there's a null somewhere it can just return
an empty string or something like that.

Furthermore if I use only an ognl expression I try to keep them rather
shallow, so they don't traverse to deep into de object model. This is
not only because of null checking though, it also makes refactoring
easier (you don't get compiler errors on ognl expressions).

--
Water, taken in moderation, cannot hurt anybody.
-- Mark Twain --

-Oorspronkelijk bericht-
Van: Martino Piccinato [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 30 maart 2007 11:53
Aan: Tapestry users
Onderwerp: OGNL PropertyAccessor and null handling best practices

Hi,

I think this issue has been discussed before on the list, I've read some
message somewhere but wanted to ask about more feedback on best practice
on
this.
The problem is handling nulls with OGNL while navigating the object
graph,
that is: getting bad NPE if one of the object of the navigation chain is
null.


Basically there are two solution to the issue:  add (a lots, in my case
as
we have a quite complex object model) null checking methods to my
components/pages
or just configure tapestry to use a forgiving OGNL PropertyAccessor that
would return null for any method to be invoked on a null (I actually
don't
like NullHandlers that create empty model objects and actually I'd
prefer
not to have public no argument constructors or creating empty objects
just
for this).


I was just wondering how you deal with this and if you have particular
suggestions.

Thanks

Martino
*** Waterschap Aa en Maas, met water in de weer! ***
Kijk voor meer informatie op www.aaenmaas.nl



Disclaimer:
Dit e-mail bericht is slechts bestemd voor de (rechts)persoon aan wie het
is gericht en
kan informatie bevatten die persoonlijk of vertrouwelijk is en niet
openbaar mag worden
gemaakt krachtens wet- of regelgeving of overeenkomst. Indien een ander
dan geadresseerde
dit e-mail bericht ontvangt of anderszins in handen krijgt is hij niet
gerechtigd tot
kennisneming, verspreiding, openbaar maken of vermenigvuldigen daarvan.
Hij wordt verzocht
onmiddellijk waterschap Aa en Maas telefonisch (telefoon: +31 (0)73
615) op de hoogte
te stellen en het e-mail bericht te vernietigen. Waterschap Aa en Maas
staat niet in
voor de juiste en volledige overbrenging van de inhoud van een verzonden
e-mail, noch voor
tijdige ontvangst daarvan. Dit e-mail bericht brengt geen enkele
contractuele gebondenheid
voor waterschap Aa en Maas tot stand.

Dit e-mail bericht is gecontroleerd op Virussen.

##

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]