You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Gentry, Michael (Contractor)" <mi...@fanniemae.com> on 2007/01/30 15:03:10 UTC
Tapestry prop: suggestion (or question)
I've downloaded and tried out the prop: prefix extension from HLS. One
thing I was *really* hoping for, compared to OGNL, is that it would
ignore null pointers, at least on reads. I have report-type pages
(read-only) where I can sometimes have thousands of rows with 10-15
columns. Each of those columns currently has bulky cover methods which
do NPE protection in case a relationship is missing (the actual values
almost always come from a dotted path: foo.bar.baz.status, and OGNL will
blow up if "bar" is null). I was hoping the prop: extension would
handle this, but it seems to work just like OGNL if it hits a null. If
something doesn't exist, I'm pretty happy with just getting a null back
and displaying nothing.
I played with the code a bit and this seems to work if you edit
PropertyAccessorBinding.java and change the getObject() method:
public Object getObject()
{
return _accessor.readProperty();
} <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
to:
public Object getObject()
{
try
{
return _accessor.readProperty();
}
catch (NullPointerException exception)
{
// Ignore NPE on reads ...
return null;
}
}
A) Does this seem like a reasonable thing to do?
B) If yes to A, could it maybe be included in the actual prop: package
(would beat maintaining a separate branch).
Thanks!
/dev/mrg
PS. I didn't alter setObject() ... I'd consider that an actual error if
you were trying to set things through nulls.
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
RE: Tapestry prop: suggestion (or question)
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
Please ignore the hyperlink that showed up in the code snippet... It
wasn't there when I was typing the e-mail. Gotta love MS. :-)
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
-----Original Message-----
From: Gentry, Michael (Contractor) [mailto:michael_gentry@fanniemae.com]
Sent: Tuesday, January 30, 2007 9:03 AM
To: Tapestry users
Subject: Tapestry prop: suggestion (or question)
I've downloaded and tried out the prop: prefix extension from HLS. One
thing I was *really* hoping for, compared to OGNL, is that it would
ignore null pointers, at least on reads. I have report-type pages
(read-only) where I can sometimes have thousands of rows with 10-15
columns. Each of those columns currently has bulky cover methods which
do NPE protection in case a relationship is missing (the actual values
almost always come from a dotted path: foo.bar.baz.status, and OGNL will
blow up if "bar" is null). I was hoping the prop: extension would
handle this, but it seems to work just like OGNL if it hits a null. If
something doesn't exist, I'm pretty happy with just getting a null back
and displaying nothing.
I played with the code a bit and this seems to work if you edit
PropertyAccessorBinding.java and change the getObject() method:
public Object getObject()
{
return _accessor.readProperty();
} <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
to:
public Object getObject()
{
try
{
return _accessor.readProperty();
}
catch (NullPointerException exception)
{
// Ignore NPE on reads ...
return null;
}
}
A) Does this seem like a reasonable thing to do?
B) If yes to A, could it maybe be included in the actual prop: package
(would beat maintaining a separate branch).
Thanks!
/dev/mrg
PS. I didn't alter setObject() ... I'd consider that an actual error if
you were trying to set things through nulls.
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapestry prop: suggestion (or question)
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
Good point. They all inherit from CayenneDataObject. I'll try to give
that a test in a bit. Thanks!
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
-----Original Message-----
From: andreas a [mailto:andreoua@gmail.com] On Behalf Of andyhot
Sent: Tuesday, January 30, 2007 12:50 PM
To: Tapestry users
Subject: Re: Tapestry prop: suggestion (or question)
Gentry, Michael (Contractor) wrote:
> I had seen the null handlers before, but was trying to avoid
registering
> 100+ handlers. :-)
>
well, perhaps they all share a common super type...
> Thanks,
>
> /dev/mrg
>
>
>
> The electronic mail message you have received and any files
transmitted
> with it are confidential and solely for the intended addressee(s)'s
> attention. Do not divulge, copy, forward, or use the contents,
> attachments, or information without permission of Fannie Mae.
> Information contained in this message is provided solely for the
purpose
> stated in the message or its attachment(s) and must not be disclosed
to
> any third party or used for any other purpose without consent of
Fannie
> Mae. If you have received this message and/or any files transmitted
with
> it in error, please delete them from your system, destroy any hard
> copies of them, and contact the sender.
>
>
> -----Original Message-----
> From: andreas a [mailto:andreoua@gmail.com] On Behalf Of andyhot
> Sent: Tuesday, January 30, 2007 12:15 PM
> To: Tapestry users
> Subject: Re: Tapestry prop: suggestion (or question)
>
> Gentry, Michael (Contractor) wrote:
>
>> I've downloaded and tried out the prop: prefix extension from HLS.
>>
> One
>
>> thing I was *really* hoping for, compared to OGNL, is that it would
>> ignore null pointers, at least on reads.
>>
>
> OGNL has a feature called NullHandlers
>
> You contribute one to configuration point tapestry.ognl.NullHandlers
> like this
> <null-handler class="class.having.null.properties"
> object="instance:org.MyNullHandler"/>
>
> where MyNullHandler implements
> http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
>
> So, if you have a RegisterPage that contains a path like
> user.department.name you have
> to register null handlers (could be the same one) for the following :
> RegisterPage (cause its user may be null),
> User (cause his department may be null)
>
>
>
>
>
>> I have report-type pages
>> (read-only) where I can sometimes have thousands of rows with 10-15
>> columns. Each of those columns currently has bulky cover methods
>>
> which
>
>> do NPE protection in case a relationship is missing (the actual
values
>> almost always come from a dotted path: foo.bar.baz.status, and OGNL
>>
> will
>
>> blow up if "bar" is null). I was hoping the prop: extension would
>> handle this, but it seems to work just like OGNL if it hits a null.
>>
> If
>
>> something doesn't exist, I'm pretty happy with just getting a null
>>
> back
>
>> and displaying nothing.
>>
>> I played with the code a bit and this seems to work if you edit
>> PropertyAccessorBinding.java and change the getObject() method:
>>
>> public Object getObject()
>> {
>> return _accessor.readProperty();
>> } <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
>>
>> to:
>>
>> public Object getObject()
>> {
>> try
>> {
>> return _accessor.readProperty();
>> }
>> catch (NullPointerException exception)
>> {
>> // Ignore NPE on reads ...
>> return null;
>> }
>> }
>>
>> A) Does this seem like a reasonable thing to do?
>> B) If yes to A, could it maybe be included in the actual prop:
package
>> (would beat maintaining a separate branch).
>>
>> Thanks!
>>
>> /dev/mrg
>>
>> PS. I didn't alter setObject() ... I'd consider that an actual error
>>
> if
>
>> you were trying to set things through nulls.
>>
>>
>> The electronic mail message you have received and any files
>>
> transmitted
>
>> with it are confidential and solely for the intended addressee(s)'s
>> attention. Do not divulge, copy, forward, or use the contents,
>> attachments, or information without permission of Fannie Mae.
>> Information contained in this message is provided solely for the
>>
> purpose
>
>> stated in the message or its attachment(s) and must not be disclosed
>>
> to
>
>> any third party or used for any other purpose without consent of
>>
> Fannie
>
>> Mae. If you have received this message and/or any files transmitted
>>
> with
>
>> it in error, please delete them from your system, destroy any hard
>> copies of them, and contact the sender.
>>
>>
>>
>>
>>
>>
>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry prop: suggestion (or question)
Posted by andyhot <an...@di.uoa.gr>.
Gentry, Michael (Contractor) wrote:
> I had seen the null handlers before, but was trying to avoid registering
> 100+ handlers. :-)
>
well, perhaps they all share a common super type...
> Thanks,
>
> /dev/mrg
>
>
>
> The electronic mail message you have received and any files transmitted
> with it are confidential and solely for the intended addressee(s)'s
> attention. Do not divulge, copy, forward, or use the contents,
> attachments, or information without permission of Fannie Mae.
> Information contained in this message is provided solely for the purpose
> stated in the message or its attachment(s) and must not be disclosed to
> any third party or used for any other purpose without consent of Fannie
> Mae. If you have received this message and/or any files transmitted with
> it in error, please delete them from your system, destroy any hard
> copies of them, and contact the sender.
>
>
> -----Original Message-----
> From: andreas a [mailto:andreoua@gmail.com] On Behalf Of andyhot
> Sent: Tuesday, January 30, 2007 12:15 PM
> To: Tapestry users
> Subject: Re: Tapestry prop: suggestion (or question)
>
> Gentry, Michael (Contractor) wrote:
>
>> I've downloaded and tried out the prop: prefix extension from HLS.
>>
> One
>
>> thing I was *really* hoping for, compared to OGNL, is that it would
>> ignore null pointers, at least on reads.
>>
>
> OGNL has a feature called NullHandlers
>
> You contribute one to configuration point tapestry.ognl.NullHandlers
> like this
> <null-handler class="class.having.null.properties"
> object="instance:org.MyNullHandler"/>
>
> where MyNullHandler implements
> http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
>
> So, if you have a RegisterPage that contains a path like
> user.department.name you have
> to register null handlers (could be the same one) for the following :
> RegisterPage (cause its user may be null),
> User (cause his department may be null)
>
>
>
>
>
>> I have report-type pages
>> (read-only) where I can sometimes have thousands of rows with 10-15
>> columns. Each of those columns currently has bulky cover methods
>>
> which
>
>> do NPE protection in case a relationship is missing (the actual values
>> almost always come from a dotted path: foo.bar.baz.status, and OGNL
>>
> will
>
>> blow up if "bar" is null). I was hoping the prop: extension would
>> handle this, but it seems to work just like OGNL if it hits a null.
>>
> If
>
>> something doesn't exist, I'm pretty happy with just getting a null
>>
> back
>
>> and displaying nothing.
>>
>> I played with the code a bit and this seems to work if you edit
>> PropertyAccessorBinding.java and change the getObject() method:
>>
>> public Object getObject()
>> {
>> return _accessor.readProperty();
>> } <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
>>
>> to:
>>
>> public Object getObject()
>> {
>> try
>> {
>> return _accessor.readProperty();
>> }
>> catch (NullPointerException exception)
>> {
>> // Ignore NPE on reads ...
>> return null;
>> }
>> }
>>
>> A) Does this seem like a reasonable thing to do?
>> B) If yes to A, could it maybe be included in the actual prop: package
>> (would beat maintaining a separate branch).
>>
>> Thanks!
>>
>> /dev/mrg
>>
>> PS. I didn't alter setObject() ... I'd consider that an actual error
>>
> if
>
>> you were trying to set things through nulls.
>>
>>
>> The electronic mail message you have received and any files
>>
> transmitted
>
>> with it are confidential and solely for the intended addressee(s)'s
>> attention. Do not divulge, copy, forward, or use the contents,
>> attachments, or information without permission of Fannie Mae.
>> Information contained in this message is provided solely for the
>>
> purpose
>
>> stated in the message or its attachment(s) and must not be disclosed
>>
> to
>
>> any third party or used for any other purpose without consent of
>>
> Fannie
>
>> Mae. If you have received this message and/or any files transmitted
>>
> with
>
>> it in error, please delete them from your system, destroy any hard
>> copies of them, and contact the sender.
>>
>>
>>
>>
>>
>>
>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapestry prop: suggestion (or question)
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
I had seen the null handlers before, but was trying to avoid registering
100+ handlers. :-)
Thanks,
/dev/mrg
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
-----Original Message-----
From: andreas a [mailto:andreoua@gmail.com] On Behalf Of andyhot
Sent: Tuesday, January 30, 2007 12:15 PM
To: Tapestry users
Subject: Re: Tapestry prop: suggestion (or question)
Gentry, Michael (Contractor) wrote:
> I've downloaded and tried out the prop: prefix extension from HLS.
One
> thing I was *really* hoping for, compared to OGNL, is that it would
> ignore null pointers, at least on reads.
OGNL has a feature called NullHandlers
You contribute one to configuration point tapestry.ognl.NullHandlers
like this
<null-handler class="class.having.null.properties"
object="instance:org.MyNullHandler"/>
where MyNullHandler implements
http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
So, if you have a RegisterPage that contains a path like
user.department.name you have
to register null handlers (could be the same one) for the following :
RegisterPage (cause its user may be null),
User (cause his department may be null)
> I have report-type pages
> (read-only) where I can sometimes have thousands of rows with 10-15
> columns. Each of those columns currently has bulky cover methods
which
> do NPE protection in case a relationship is missing (the actual values
> almost always come from a dotted path: foo.bar.baz.status, and OGNL
will
> blow up if "bar" is null). I was hoping the prop: extension would
> handle this, but it seems to work just like OGNL if it hits a null.
If
> something doesn't exist, I'm pretty happy with just getting a null
back
> and displaying nothing.
>
> I played with the code a bit and this seems to work if you edit
> PropertyAccessorBinding.java and change the getObject() method:
>
> public Object getObject()
> {
> return _accessor.readProperty();
> } <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
>
> to:
>
> public Object getObject()
> {
> try
> {
> return _accessor.readProperty();
> }
> catch (NullPointerException exception)
> {
> // Ignore NPE on reads ...
> return null;
> }
> }
>
> A) Does this seem like a reasonable thing to do?
> B) If yes to A, could it maybe be included in the actual prop: package
> (would beat maintaining a separate branch).
>
> Thanks!
>
> /dev/mrg
>
> PS. I didn't alter setObject() ... I'd consider that an actual error
if
> you were trying to set things through nulls.
>
>
> The electronic mail message you have received and any files
transmitted
> with it are confidential and solely for the intended addressee(s)'s
> attention. Do not divulge, copy, forward, or use the contents,
> attachments, or information without permission of Fannie Mae.
> Information contained in this message is provided solely for the
purpose
> stated in the message or its attachment(s) and must not be disclosed
to
> any third party or used for any other purpose without consent of
Fannie
> Mae. If you have received this message and/or any files transmitted
with
> it in error, please delete them from your system, destroy any hard
> copies of them, and contact the sender.
>
>
>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry prop: suggestion (or question)
Posted by Andreas Andreou <an...@di.uoa.gr>.
Probably dangerous but nice...or,
probably nice but dangerous ;-)
Anyway, perhaps this can find its way in our wiki.
http://wiki.apache.org/tapestry/
On 4/6/07, Drew McAuliffe <dr...@gmail.com> wrote:
>
> You can also do what I did and just contribute a brand new expression
> evaluator:
> public class NullSafeExpressionEvaluator extends ExpressionEvaluatorImpl
> {
> private static Logger log = Logger.getLogger(
> NullSafeExpressionEvaluator.class);
> private static final String START_BRACKET = "{";
> private static final String ESCAPED_BRACKET = START_BRACKET;
> private static final String END_BRACKET = ESCAPED_BRACKET;
> public Object readCompiled(Object target, Object expression){
> Object result = null;
> try{
> result = super.readCompiled(target, expression);
> }
> catch (ApplicationRuntimeException e){
> if (!(e.getRootCause() instanceof NullPointerException))
> result = "";
> // don't do anything!
> }
> return result;
> }
> }
>
> HIVEMIND:
> <!-- override OGNL evaluator to use more null friendly one -->
> <implementation service-id="tapestry.ognl.ExpressionEvaluator">
> <invoke-factory>
> <construct class="com.mypackage.NullSafeExpressionEvaluator">
> <set-object property="applicationSpecification"
> value="infrastructure:applicationSpecification"/>
> <set-configuration property="contributions"
> configuration-id="PropertyAccessors"/>
> <set-configuration property="nullHandlerContributions"
> configuration-id="NullHandlers"/>
> </construct>
> </invoke-factory>
> </implementation>
>
>
> On 1/31/07, andyhot <an...@di.uoa.gr> wrote:
> >
> > Gentry, Michael (Contractor) wrote:
> > > I get an error trying to contribute to tapestry.ognl.NullHandlers ...
> > > Is that available in T4? Thanks!
> > >
> >
> > Damn, that's 4.1 only...
> > If you're on 4.0.x, you can still do this, but you'll have to register
> > the handlers on your own.
> >
> > You just have to call OgnlRuntime's static method at a convenient time,
> > i.e. on app startup
> >
> > OgnlRuntime.setNullHandler(subjectClass, handler);
> >
> > That's exactly what happens in
> >
> >
> http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/services/impl/ExpressionEvaluatorImpl.java?view=markup
> >
> >
> >
> > >
> > > The electronic mail message you have received and any files
> transmitted
> > > with it are confidential and solely for the intended addressee(s)'s
> > > attention. Do not divulge, copy, forward, or use the contents,
> > > attachments, or information without permission of Fannie Mae.
> > > Information contained in this message is provided solely for the
> purpose
> > > stated in the message or its attachment(s) and must not be disclosed
> to
> > > any third party or used for any other purpose without consent of
> Fannie
> > > Mae. If you have received this message and/or any files transmitted
> with
> > > it in error, please delete them from your system, destroy any hard
> > > copies of them, and contact the sender.
> > >
> > >
> > > -----Original Message-----
> > > From: andreas a [mailto:andreoua@gmail.com] On Behalf Of andyhot
> > > Sent: Tuesday, January 30, 2007 12:15 PM
> > > To: Tapestry users
> > > Subject: Re: Tapestry prop: suggestion (or question)
> > >
> > > Gentry, Michael (Contractor) wrote:
> > >
> > >> I've downloaded and tried out the prop: prefix extension from HLS.
> > >>
> > > One
> > >
> > >> thing I was *really* hoping for, compared to OGNL, is that it would
> > >> ignore null pointers, at least on reads.
> > >>
> > >
> > > OGNL has a feature called NullHandlers
> > >
> > > You contribute one to configuration point tapestry.ognl.NullHandlers
> > > like this
> > > <null-handler class="class.having.null.properties"
> > > object="instance:org.MyNullHandler"/>
> > >
> > > where MyNullHandler implements
> > > http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
> > >
> > > So, if you have a RegisterPage that contains a path like
> > > user.department.name you have
> > > to register null handlers (could be the same one) for the following :
> > > RegisterPage (cause its user may be null),
> > > User (cause his department may be null)
> > >
> > >
> > >
> > >
> > >
> > >> I have report-type pages
> > >> (read-only) where I can sometimes have thousands of rows with 10-15
> > >> columns. Each of those columns currently has bulky cover methods
> > >>
> > > which
> > >
> > >> do NPE protection in case a relationship is missing (the actual
> values
> > >> almost always come from a dotted path: foo.bar.baz.status, and OGNL
> > >>
> > > will
> > >
> > >> blow up if "bar" is null). I was hoping the prop: extension would
> > >> handle this, but it seems to work just like OGNL if it hits a null.
> > >>
> > > If
> > >
> > >> something doesn't exist, I'm pretty happy with just getting a null
> > >>
> > > back
> > >
> > >> and displaying nothing.
> > >>
> > >> I played with the code a bit and this seems to work if you edit
> > >> PropertyAccessorBinding.java and change the getObject() method:
> > >>
> > >> public Object getObject()
> > >> {
> > >> return _accessor.readProperty();
> > >> } <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
> > >>
> > >> to:
> > >>
> > >> public Object getObject()
> > >> {
> > >> try
> > >> {
> > >> return _accessor.readProperty();
> > >> }
> > >> catch (NullPointerException exception)
> > >> {
> > >> // Ignore NPE on reads ...
> > >> return null;
> > >> }
> > >> }
> > >>
> > >> A) Does this seem like a reasonable thing to do?
> > >> B) If yes to A, could it maybe be included in the actual prop:
> package
> > >> (would beat maintaining a separate branch).
> > >>
> > >> Thanks!
> > >>
> > >> /dev/mrg
> > >>
> > >> PS. I didn't alter setObject() ... I'd consider that an actual error
> > >>
> > > if
> > >
> > >> you were trying to set things through nulls.
> > >>
> > >>
> > >> The electronic mail message you have received and any files
> > >>
> > > transmitted
> > >
> > >> with it are confidential and solely for the intended addressee(s)'s
> > >> attention. Do not divulge, copy, forward, or use the contents,
> > >> attachments, or information without permission of Fannie Mae.
> > >> Information contained in this message is provided solely for the
> > >>
> > > purpose
> > >
> > >> stated in the message or its attachment(s) and must not be disclosed
> > >>
> > > to
> > >
> > >> any third party or used for any other purpose without consent of
> > >>
> > > Fannie
> > >
> > >> Mae. If you have received this message and/or any files transmitted
> > >>
> > > with
> > >
> > >> it in error, please delete them from your system, destroy any hard
> > >> copies of them, and contact the sender.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
> > --
> > Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> > Tapestry / Tacos developer
> > Open Source / J2EE Consulting
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
Re: Tapestry prop: suggestion (or question)
Posted by Drew McAuliffe <dr...@gmail.com>.
You can also do what I did and just contribute a brand new expression
evaluator:
public class NullSafeExpressionEvaluator extends ExpressionEvaluatorImpl
{
private static Logger log = Logger.getLogger(
NullSafeExpressionEvaluator.class);
private static final String START_BRACKET = "{";
private static final String ESCAPED_BRACKET = START_BRACKET;
private static final String END_BRACKET = ESCAPED_BRACKET;
public Object readCompiled(Object target, Object expression){
Object result = null;
try{
result = super.readCompiled(target, expression);
}
catch (ApplicationRuntimeException e){
if (!(e.getRootCause() instanceof NullPointerException))
result = "";
// don't do anything!
}
return result;
}
}
HIVEMIND:
<!-- override OGNL evaluator to use more null friendly one -->
<implementation service-id="tapestry.ognl.ExpressionEvaluator">
<invoke-factory>
<construct class="com.mypackage.NullSafeExpressionEvaluator">
<set-object property="applicationSpecification"
value="infrastructure:applicationSpecification"/>
<set-configuration property="contributions"
configuration-id="PropertyAccessors"/>
<set-configuration property="nullHandlerContributions"
configuration-id="NullHandlers"/>
</construct>
</invoke-factory>
</implementation>
On 1/31/07, andyhot <an...@di.uoa.gr> wrote:
>
> Gentry, Michael (Contractor) wrote:
> > I get an error trying to contribute to tapestry.ognl.NullHandlers ...
> > Is that available in T4? Thanks!
> >
>
> Damn, that's 4.1 only...
> If you're on 4.0.x, you can still do this, but you'll have to register
> the handlers on your own.
>
> You just have to call OgnlRuntime's static method at a convenient time,
> i.e. on app startup
>
> OgnlRuntime.setNullHandler(subjectClass, handler);
>
> That's exactly what happens in
>
> http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/services/impl/ExpressionEvaluatorImpl.java?view=markup
>
>
>
> >
> > The electronic mail message you have received and any files transmitted
> > with it are confidential and solely for the intended addressee(s)'s
> > attention. Do not divulge, copy, forward, or use the contents,
> > attachments, or information without permission of Fannie Mae.
> > Information contained in this message is provided solely for the purpose
> > stated in the message or its attachment(s) and must not be disclosed to
> > any third party or used for any other purpose without consent of Fannie
> > Mae. If you have received this message and/or any files transmitted with
> > it in error, please delete them from your system, destroy any hard
> > copies of them, and contact the sender.
> >
> >
> > -----Original Message-----
> > From: andreas a [mailto:andreoua@gmail.com] On Behalf Of andyhot
> > Sent: Tuesday, January 30, 2007 12:15 PM
> > To: Tapestry users
> > Subject: Re: Tapestry prop: suggestion (or question)
> >
> > Gentry, Michael (Contractor) wrote:
> >
> >> I've downloaded and tried out the prop: prefix extension from HLS.
> >>
> > One
> >
> >> thing I was *really* hoping for, compared to OGNL, is that it would
> >> ignore null pointers, at least on reads.
> >>
> >
> > OGNL has a feature called NullHandlers
> >
> > You contribute one to configuration point tapestry.ognl.NullHandlers
> > like this
> > <null-handler class="class.having.null.properties"
> > object="instance:org.MyNullHandler"/>
> >
> > where MyNullHandler implements
> > http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
> >
> > So, if you have a RegisterPage that contains a path like
> > user.department.name you have
> > to register null handlers (could be the same one) for the following :
> > RegisterPage (cause its user may be null),
> > User (cause his department may be null)
> >
> >
> >
> >
> >
> >> I have report-type pages
> >> (read-only) where I can sometimes have thousands of rows with 10-15
> >> columns. Each of those columns currently has bulky cover methods
> >>
> > which
> >
> >> do NPE protection in case a relationship is missing (the actual values
> >> almost always come from a dotted path: foo.bar.baz.status, and OGNL
> >>
> > will
> >
> >> blow up if "bar" is null). I was hoping the prop: extension would
> >> handle this, but it seems to work just like OGNL if it hits a null.
> >>
> > If
> >
> >> something doesn't exist, I'm pretty happy with just getting a null
> >>
> > back
> >
> >> and displaying nothing.
> >>
> >> I played with the code a bit and this seems to work if you edit
> >> PropertyAccessorBinding.java and change the getObject() method:
> >>
> >> public Object getObject()
> >> {
> >> return _accessor.readProperty();
> >> } <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
> >>
> >> to:
> >>
> >> public Object getObject()
> >> {
> >> try
> >> {
> >> return _accessor.readProperty();
> >> }
> >> catch (NullPointerException exception)
> >> {
> >> // Ignore NPE on reads ...
> >> return null;
> >> }
> >> }
> >>
> >> A) Does this seem like a reasonable thing to do?
> >> B) If yes to A, could it maybe be included in the actual prop: package
> >> (would beat maintaining a separate branch).
> >>
> >> Thanks!
> >>
> >> /dev/mrg
> >>
> >> PS. I didn't alter setObject() ... I'd consider that an actual error
> >>
> > if
> >
> >> you were trying to set things through nulls.
> >>
> >>
> >> The electronic mail message you have received and any files
> >>
> > transmitted
> >
> >> with it are confidential and solely for the intended addressee(s)'s
> >> attention. Do not divulge, copy, forward, or use the contents,
> >> attachments, or information without permission of Fannie Mae.
> >> Information contained in this message is provided solely for the
> >>
> > purpose
> >
> >> stated in the message or its attachment(s) and must not be disclosed
> >>
> > to
> >
> >> any third party or used for any other purpose without consent of
> >>
> > Fannie
> >
> >> Mae. If you have received this message and/or any files transmitted
> >>
> > with
> >
> >> it in error, please delete them from your system, destroy any hard
> >> copies of them, and contact the sender.
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
> --
> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> Tapestry / Tacos developer
> Open Source / J2EE Consulting
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Tapestry prop: suggestion (or question)
Posted by andyhot <an...@di.uoa.gr>.
Gentry, Michael (Contractor) wrote:
> I get an error trying to contribute to tapestry.ognl.NullHandlers ...
> Is that available in T4? Thanks!
>
Damn, that's 4.1 only...
If you're on 4.0.x, you can still do this, but you'll have to register
the handlers on your own.
You just have to call OgnlRuntime's static method at a convenient time,
i.e. on app startup
OgnlRuntime.setNullHandler(subjectClass, handler);
That's exactly what happens in
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/services/impl/ExpressionEvaluatorImpl.java?view=markup
>
> The electronic mail message you have received and any files transmitted
> with it are confidential and solely for the intended addressee(s)'s
> attention. Do not divulge, copy, forward, or use the contents,
> attachments, or information without permission of Fannie Mae.
> Information contained in this message is provided solely for the purpose
> stated in the message or its attachment(s) and must not be disclosed to
> any third party or used for any other purpose without consent of Fannie
> Mae. If you have received this message and/or any files transmitted with
> it in error, please delete them from your system, destroy any hard
> copies of them, and contact the sender.
>
>
> -----Original Message-----
> From: andreas a [mailto:andreoua@gmail.com] On Behalf Of andyhot
> Sent: Tuesday, January 30, 2007 12:15 PM
> To: Tapestry users
> Subject: Re: Tapestry prop: suggestion (or question)
>
> Gentry, Michael (Contractor) wrote:
>
>> I've downloaded and tried out the prop: prefix extension from HLS.
>>
> One
>
>> thing I was *really* hoping for, compared to OGNL, is that it would
>> ignore null pointers, at least on reads.
>>
>
> OGNL has a feature called NullHandlers
>
> You contribute one to configuration point tapestry.ognl.NullHandlers
> like this
> <null-handler class="class.having.null.properties"
> object="instance:org.MyNullHandler"/>
>
> where MyNullHandler implements
> http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
>
> So, if you have a RegisterPage that contains a path like
> user.department.name you have
> to register null handlers (could be the same one) for the following :
> RegisterPage (cause its user may be null),
> User (cause his department may be null)
>
>
>
>
>
>> I have report-type pages
>> (read-only) where I can sometimes have thousands of rows with 10-15
>> columns. Each of those columns currently has bulky cover methods
>>
> which
>
>> do NPE protection in case a relationship is missing (the actual values
>> almost always come from a dotted path: foo.bar.baz.status, and OGNL
>>
> will
>
>> blow up if "bar" is null). I was hoping the prop: extension would
>> handle this, but it seems to work just like OGNL if it hits a null.
>>
> If
>
>> something doesn't exist, I'm pretty happy with just getting a null
>>
> back
>
>> and displaying nothing.
>>
>> I played with the code a bit and this seems to work if you edit
>> PropertyAccessorBinding.java and change the getObject() method:
>>
>> public Object getObject()
>> {
>> return _accessor.readProperty();
>> } <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
>>
>> to:
>>
>> public Object getObject()
>> {
>> try
>> {
>> return _accessor.readProperty();
>> }
>> catch (NullPointerException exception)
>> {
>> // Ignore NPE on reads ...
>> return null;
>> }
>> }
>>
>> A) Does this seem like a reasonable thing to do?
>> B) If yes to A, could it maybe be included in the actual prop: package
>> (would beat maintaining a separate branch).
>>
>> Thanks!
>>
>> /dev/mrg
>>
>> PS. I didn't alter setObject() ... I'd consider that an actual error
>>
> if
>
>> you were trying to set things through nulls.
>>
>>
>> The electronic mail message you have received and any files
>>
> transmitted
>
>> with it are confidential and solely for the intended addressee(s)'s
>> attention. Do not divulge, copy, forward, or use the contents,
>> attachments, or information without permission of Fannie Mae.
>> Information contained in this message is provided solely for the
>>
> purpose
>
>> stated in the message or its attachment(s) and must not be disclosed
>>
> to
>
>> any third party or used for any other purpose without consent of
>>
> Fannie
>
>> Mae. If you have received this message and/or any files transmitted
>>
> with
>
>> it in error, please delete them from your system, destroy any hard
>> copies of them, and contact the sender.
>>
>>
>>
>>
>>
>>
>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: Tapestry prop: suggestion (or question)
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
I get an error trying to contribute to tapestry.ognl.NullHandlers ...
Is that available in T4? Thanks!
The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender.
-----Original Message-----
From: andreas a [mailto:andreoua@gmail.com] On Behalf Of andyhot
Sent: Tuesday, January 30, 2007 12:15 PM
To: Tapestry users
Subject: Re: Tapestry prop: suggestion (or question)
Gentry, Michael (Contractor) wrote:
> I've downloaded and tried out the prop: prefix extension from HLS.
One
> thing I was *really* hoping for, compared to OGNL, is that it would
> ignore null pointers, at least on reads.
OGNL has a feature called NullHandlers
You contribute one to configuration point tapestry.ognl.NullHandlers
like this
<null-handler class="class.having.null.properties"
object="instance:org.MyNullHandler"/>
where MyNullHandler implements
http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
So, if you have a RegisterPage that contains a path like
user.department.name you have
to register null handlers (could be the same one) for the following :
RegisterPage (cause its user may be null),
User (cause his department may be null)
> I have report-type pages
> (read-only) where I can sometimes have thousands of rows with 10-15
> columns. Each of those columns currently has bulky cover methods
which
> do NPE protection in case a relationship is missing (the actual values
> almost always come from a dotted path: foo.bar.baz.status, and OGNL
will
> blow up if "bar" is null). I was hoping the prop: extension would
> handle this, but it seems to work just like OGNL if it hits a null.
If
> something doesn't exist, I'm pretty happy with just getting a null
back
> and displaying nothing.
>
> I played with the code a bit and this seems to work if you edit
> PropertyAccessorBinding.java and change the getObject() method:
>
> public Object getObject()
> {
> return _accessor.readProperty();
> } <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
>
> to:
>
> public Object getObject()
> {
> try
> {
> return _accessor.readProperty();
> }
> catch (NullPointerException exception)
> {
> // Ignore NPE on reads ...
> return null;
> }
> }
>
> A) Does this seem like a reasonable thing to do?
> B) If yes to A, could it maybe be included in the actual prop: package
> (would beat maintaining a separate branch).
>
> Thanks!
>
> /dev/mrg
>
> PS. I didn't alter setObject() ... I'd consider that an actual error
if
> you were trying to set things through nulls.
>
>
> The electronic mail message you have received and any files
transmitted
> with it are confidential and solely for the intended addressee(s)'s
> attention. Do not divulge, copy, forward, or use the contents,
> attachments, or information without permission of Fannie Mae.
> Information contained in this message is provided solely for the
purpose
> stated in the message or its attachment(s) and must not be disclosed
to
> any third party or used for any other purpose without consent of
Fannie
> Mae. If you have received this message and/or any files transmitted
with
> it in error, please delete them from your system, destroy any hard
> copies of them, and contact the sender.
>
>
>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry prop: suggestion (or question)
Posted by andyhot <an...@di.uoa.gr>.
Gentry, Michael (Contractor) wrote:
> I've downloaded and tried out the prop: prefix extension from HLS. One
> thing I was *really* hoping for, compared to OGNL, is that it would
> ignore null pointers, at least on reads.
OGNL has a feature called NullHandlers
You contribute one to configuration point tapestry.ognl.NullHandlers
like this
<null-handler class="class.having.null.properties"
object="instance:org.MyNullHandler"/>
where MyNullHandler implements
http://www.ognl.org/2.6.9/Documentation/javadoc/ognl/NullHandler.html
So, if you have a RegisterPage that contains a path like
user.department.name you have
to register null handlers (could be the same one) for the following :
RegisterPage (cause its user may be null),
User (cause his department may be null)
> I have report-type pages
> (read-only) where I can sometimes have thousands of rows with 10-15
> columns. Each of those columns currently has bulky cover methods which
> do NPE protection in case a relationship is missing (the actual values
> almost always come from a dotted path: foo.bar.baz.status, and OGNL will
> blow up if "bar" is null). I was hoping the prop: extension would
> handle this, but it seems to work just like OGNL if it hits a null. If
> something doesn't exist, I'm pretty happy with just getting a null back
> and displaying nothing.
>
> I played with the code a bit and this seems to work if you edit
> PropertyAccessorBinding.java and change the getObject() method:
>
> public Object getObject()
> {
> return _accessor.readProperty();
> } <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
>
> to:
>
> public Object getObject()
> {
> try
> {
> return _accessor.readProperty();
> }
> catch (NullPointerException exception)
> {
> // Ignore NPE on reads ...
> return null;
> }
> }
>
> A) Does this seem like a reasonable thing to do?
> B) If yes to A, could it maybe be included in the actual prop: package
> (would beat maintaining a separate branch).
>
> Thanks!
>
> /dev/mrg
>
> PS. I didn't alter setObject() ... I'd consider that an actual error if
> you were trying to set things through nulls.
>
>
> The electronic mail message you have received and any files transmitted
> with it are confidential and solely for the intended addressee(s)'s
> attention. Do not divulge, copy, forward, or use the contents,
> attachments, or information without permission of Fannie Mae.
> Information contained in this message is provided solely for the purpose
> stated in the message or its attachment(s) and must not be disclosed to
> any third party or used for any other purpose without consent of Fannie
> Mae. If you have received this message and/or any files transmitted with
> it in error, please delete them from your system, destroy any hard
> copies of them, and contact the sender.
>
>
>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Should @Insert encode whitespace?
Posted by andyhot <an...@di.uoa.gr>.
http://tapestry.apache.org/tapestry4.1/components/general/insert.html
Use the format parameter and provide it with a SpaceToNBSPFormat (that
you also create)
Must leave raw to true.
Wes Bramhall wrote:
> I have an app that displays a list of filenames to the user. I'm looping
> over a list of File objects and displaying the names using an insert
> component. Here's a barebones example:
>
> <files jwcid="@For" source="ognl:files" value="ognl:loopFile">
> <filename jwcid="@Insert" value="ognl:loopFile.name" /><br />
> </files>
>
> It is possible to have filenames like "A B", "A B", and "A B".
> Sent to the insert component, they get rendered as "A B", "A B", and
> "A B" in the HTML source but end up displayed as "A B", "A B", and "A
> B" on the screen. Setting the raw attribute to true doesn't change this
> behavior. Would it be reasonable to encode consecutive spaces as ?
> Does anyone have a better idea?
>
>
> For now I'll have to switch to the below code:
>
> <files jwcid="@For" source="ognl:files" value="ognl:loopFile">
> <filename jwcid="@Insert" raw="ognl:true" value="ognl:safeName"
> /><br />
> </files>
>
> public String getSafeName()
> {
> return getLoopFile().getName().replace(" ", " ");
> }
>
> Thanks,
> -Wes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Should @Insert encode whitespace?
Posted by Jesse Kuhnert <jk...@gmail.com>.
I don't remember which version this affected but I did fix a minor
whitespace issue in the template parser a few weeks ago. (I have no
idea, just know it's probably in >= 4.1.1 - it was related to i18n but
may be applicable to your situation )
On 1/30/07, Wes Bramhall <We...@widen.com> wrote:
> I have an app that displays a list of filenames to the user. I'm looping
> over a list of File objects and displaying the names using an insert
> component. Here's a barebones example:
>
> <files jwcid="@For" source="ognl:files" value="ognl:loopFile">
> <filename jwcid="@Insert" value="ognl:loopFile.name" /><br />
> </files>
>
> It is possible to have filenames like "A B", "A B", and "A B".
> Sent to the insert component, they get rendered as "A B", "A B", and
> "A B" in the HTML source but end up displayed as "A B", "A B", and "A
> B" on the screen. Setting the raw attribute to true doesn't change this
> behavior. Would it be reasonable to encode consecutive spaces as ?
> Does anyone have a better idea?
>
>
> For now I'll have to switch to the below code:
>
> <files jwcid="@For" source="ognl:files" value="ognl:loopFile">
> <filename jwcid="@Insert" raw="ognl:true" value="ognl:safeName"
> /><br />
> </files>
>
> public String getSafeName()
> {
> return getLoopFile().getName().replace(" ", " ");
> }
>
> Thanks,
> -Wes
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Should @Insert encode whitespace?
Posted by Wes Bramhall <We...@widen.com>.
I have an app that displays a list of filenames to the user. I'm looping
over a list of File objects and displaying the names using an insert
component. Here's a barebones example:
<files jwcid="@For" source="ognl:files" value="ognl:loopFile">
<filename jwcid="@Insert" value="ognl:loopFile.name" /><br />
</files>
It is possible to have filenames like "A B", "A B", and "A B".
Sent to the insert component, they get rendered as "A B", "A B", and
"A B" in the HTML source but end up displayed as "A B", "A B", and "A
B" on the screen. Setting the raw attribute to true doesn't change this
behavior. Would it be reasonable to encode consecutive spaces as ?
Does anyone have a better idea?
For now I'll have to switch to the below code:
<files jwcid="@For" source="ognl:files" value="ognl:loopFile">
<filename jwcid="@Insert" raw="ognl:true" value="ognl:safeName"
/><br />
</files>
public String getSafeName()
{
return getLoopFile().getName().replace(" ", " ");
}
Thanks,
-Wes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry prop: suggestion (or question)
Posted by Howard Lewis Ship <hl...@gmail.com>.
The source for tapestry-prop is available.
If I were doing this, I would change how it generates code to check
for the nulls as it goes, rather than forcing an NPE. Further, when
accessing a property, there's always the potential that the terminal
property accessor method throws the NPE which you wouldn't want to
mask. So handle nulls by checking for nulls.
I don't believe in baking this into tapestry-prop, I try to code in
the "don't expect null, don't return null" vein. You can do a lot
with Collections.EMPTY_LIST and flyweight placeholders to prevent
NPEs.
On 1/30/07, Gentry, Michael (Contractor) <mi...@fanniemae.com> wrote:
> I've downloaded and tried out the prop: prefix extension from HLS. One
> thing I was *really* hoping for, compared to OGNL, is that it would
> ignore null pointers, at least on reads. I have report-type pages
> (read-only) where I can sometimes have thousands of rows with 10-15
> columns. Each of those columns currently has bulky cover methods which
> do NPE protection in case a relationship is missing (the actual values
> almost always come from a dotted path: foo.bar.baz.status, and OGNL will
> blow up if "bar" is null). I was hoping the prop: extension would
> handle this, but it seems to work just like OGNL if it hits a null. If
> something doesn't exist, I'm pretty happy with just getting a null back
> and displaying nothing.
>
> I played with the code a bit and this seems to work if you edit
> PropertyAccessorBinding.java and change the getObject() method:
>
> public Object getObject()
> {
> return _accessor.readProperty();
> } <http://www.len.ro/work/articles/tapestry-ajax-application-1/>
>
> to:
>
> public Object getObject()
> {
> try
> {
> return _accessor.readProperty();
> }
> catch (NullPointerException exception)
> {
> // Ignore NPE on reads ...
> return null;
> }
> }
>
> A) Does this seem like a reasonable thing to do?
> B) If yes to A, could it maybe be included in the actual prop: package
> (would beat maintaining a separate branch).
>
> Thanks!
>
> /dev/mrg
>
> PS. I didn't alter setObject() ... I'd consider that an actual error if
> you were trying to set things through nulls.
>
>
> The electronic mail message you have received and any files transmitted
> with it are confidential and solely for the intended addressee(s)'s
> attention. Do not divulge, copy, forward, or use the contents,
> attachments, or information without permission of Fannie Mae.
> Information contained in this message is provided solely for the purpose
> stated in the message or its attachment(s) and must not be disclosed to
> any third party or used for any other purpose without consent of Fannie
> Mae. If you have received this message and/or any files transmitted with
> it in error, please delete them from your system, destroy any hard
> copies of them, and contact the sender.
>
>
>
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Tapestry prop: suggestion (or question)
Posted by D&J Gredler <dj...@gmail.com>.
Sometimes it might make sense to have a setObject( ) with a little bit
different behavior... namely, if elements of the property path are null then
try to instantiate them, but ignore setObject( ) calls where the value to
set is null and one of the property path elements is also null. I've taken
this approach in the past with reflection-based bindings, and it's been
pretty nice.
On 1/30/07, Gentry, Michael (Contractor) <mi...@fanniemae.com>
wrote:
>
>
> PS. I didn't alter setObject() ... I'd consider that an actual error if
> you were trying to set things through nulls.
>
>