The NPEs from OGNL strings (like "foo.bar.name") are more of an OGNL issue than a Cayenne issue. At least in my opinion. I think the best thing to do, especially with regards to Tapestry and OGNL and Cayenne, is to add a cayenne: prefix extension to Tapestry (just like HLS added a prop: prefix -- see http://tapestryjava.blogspot.com/2006/11/improve-tapestry-performance-with.html if not familiar with it). The cayenne: prefix would ignore nulls. Like in your example of "foo.bar.name", if bar is null, the whole expression is null. This has been on my personal to-do list for a while. Maybe I should revisit it. Then most of the ognl: expressions can go away and you won't need to write a lot of special null-handling code. In my own project here, that special null-handling code can add 30-40% to the size of the page class. Nasty.
/dev/mrg PS. I just started looking at that blog entry from HLS. Looks like he has added path expressions to it since I last looked. It *may* already handle nulls ... must investigate more. On 12/14/06, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
On 12/14/06, Tore Halset <[EMAIL PROTECTED]> wrote: > On Dec 14, 2006, at 9:11 , Øyvind Harboe wrote: > > > Could I implement my own "NeverNullString" datatype where I'm thinking > > that .toString() returns the either what Cayenne java.lang.String > > returns today or e.g. "" for the case where it represents a database > > null? > > Or perhaps map java.lang.CharSequence and create a NullString that > implements it. You could then create an ExtendedType (perhaps > subclass CharType) that does what you want. I messed around with this for a while and I've drawn some conclusions: - If I'm to use CharSequence instead of String's, then that needs to be in the application from day #1. It's testing hell trying to replace String w/anything but a subclass of string(which isn't possible since String is final). - As I'm using Tapestry, then if I return something to Tapestry that it interprets as an empty string, then it will set an empty string upon my Cayenne object during Form rewind. If I used an empty string to represent database null, my code would then make the mistake of changing the database value from database null to an empty string. - If it is OK from an application point of view to turn database null into empty strings as a side effect of Tapestry form rewind, then this approach seems fine and relatively straightforward. - ExtendedType can not deal with relationships and database null, and until I get rid of NPE(null pointer exceptions) w/relationships(ref. OGNL property strings foo.bar.name where bar might be null), I've only got half a solution. There have been other posts about relationships and NPE's in the past in Cayenne-user, but a robust solution is far from obvious. -- Øyvind Harboe http://www.zylin.com
