Chris is correct: in order to fully allow for conversion of a property back it's original form (MM/dd/yyyy -> setDate(); but also getDate() -> MM/dd/yyyy for display on the view), there will be extra configuration options needed (another reason I was pushing the config architecture so much yesterday). Essentially, at some point we'll need to let the user specify the global, action, and property-level type converters to be used. If none are specified, we'll jus default to one, so no extra config cruft is added that isn't needed.
The reason we don't have this configuration option today is actually because doing something similar to this (via PropertyEditors, which are less powerful) is done using reflection and the assumption you named your PropertyEditors correclty (I forgot the details, but it's something like ActionBeanDescriptor, which then has to register tons of PropertyEditors). This of course, is far more work for the end user than adding a configuration object, so just keep that in mind. To be honest, I'm not really that keen on a branch. I'd much rather add Ognl in a clean-room environment (a la sandbox/xwork) after I've fixed the bugs assigned to me in JIRA for a WebWork 1.3 release. -Pat ----- Original Message ----- From: "Chris Miller" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 05, 2002 10:01 AM Subject: [OS-webwork] Re: OGNL > As I see it, one of the key benefits of OGNL is its newfound ability to > perform type conversions FROM a property TO a view. WW has needed this for a > long time now. This is far more important to me than a few ms saved here and > there, so as long as performance does not degrade significantly I would > consider the move to OGNL a very positive step. > > I assume that extra configuration will be required somewhere to take full > advantage of this (although the default behaviour with no configuration > could maintain backwards compatibility?). So be it, in my book this will > prove to be incredibly useful functionality. > > Maurice's point about stability before functionality is of course extremely > valid too, but if Pat is keen to code this on a branch in the meantime I > can't see any reason to discourage him. > > > "Hani Suleiman" <[EMAIL PROTECTED]> wrote in message > news:1036517903.3dc8020f7b62a@;mail.formicary.net... > > Well, the ognl stuff seems very promising, how about having it implemented > on a > > branch (say, OGNL_1 or something), with a view to integrating it once > others > > have had a look and feel it's worthwhile? > > > > Again, I stress that the goal for adding it (from my perspective at least) > is > > performance. There should be NO configuration changes, and absolutely NO > > external changes. The only different (hopefully) will be superior > performance on > > the branch version. If it ends up being ugly/unusable/slow/unfashionable, > the > > branch can merrily die off, if it's useful/pretty/a positive step, it can > land > > on HEAD. Any objections? > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by: See the NEW Palm > > Tungsten T handheld. Power & Color in a compact size! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
