Re: Tapestry prop: suggestion (or question)
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
Re: Tapestry prop: suggestion (or question)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
RE: Tapestry prop: suggestion (or question)
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:[EMAIL PROTECTED] 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 - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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)
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) [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tapestry prop: suggestion (or question)
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:[EMAIL PROTECTED] 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 - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry prop: suggestion (or question)
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) [EMAIL PROTECTED] wrote: PS. I didn't alter setObject() ... I'd consider that an actual error if you were trying to set things through nulls.
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:[EMAIL PROTECTED] 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 - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr Tapestry / Tacos developer Open Source / J2EE Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tapestry prop: suggestion (or question)
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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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