Hi there,

On 29/10/2007, at 10:28 PM, Mike Schrag wrote:

Personally I find creating a simple groovy expression in your wod binding cleaner looking than WOOgnl.

e.g.,
SomeDiv : WOGenericContainer {
        <....>
        omitTags = hasFoo && hasBar;
}
I wasn't very clear -- I'm with you on this (though honestly this is actually identical to OGNL except that WOOGNL requires the leading "~".

... and the surrounding quotes, no? And, thus escaping quotes within the expression.

5.4 lets you plugin custom association parsers -- you can literally write groovy methods as bindings. It's academically interesting, but sort of crazy. There's a pretty wild example of what the parser can do floating around that I'm not sure if it made it into the developer examples or not ... I'll have to check.

Okay, interesting. My Leopard copy has finally arrived, so I'll be able to check this out soon enough.

Other than that, I think Wonder's is a more developer-friendly parser. I am, however, totally biased on this topic :) I think groovy components over in-place groovy bindings is probably the better approach to solve the dynamic binding problem.

If it's a developer updating the page, sure. It's simple things like being able to prefix a numeric id for css purposes where groovy bindings are very helpful for a web designer.
Yep, which is why I'm pro OGNL as well (and helper functions, though that's less of a designer thing, but similar sort of goals). WOLips actually validates limited OGNL expressions -- so if you do "~person.firstName + ' ' + person.lastName", WOLips will actually validate those keypaths for you.

Our web designer doesn't use WOLips at all, so validation is a moot point, though helpful when I svn up :-)

So how do you determine when to eval as groovy and when it's not? Or is it just always eval'd as groovy for your apps?

The choice is quite easy:
if (KEY_PATH_PTN.matcher(expression).matches()
    ||CONSTANT_PTN.matcher(expression).matches())
        // normal eval
else
        // eval as groovy expresion

Or... just eval it all as a groovy expression. I've not done any performance tests to see which is better.

But this way, the binding is always clean. Here's an example of what I mean by clean:

Taken from [1] we see something that should be simply expressed looking like:
String3: WOString {
        value = "~\"Hello Max \" + name";
}

To me that's ugly. And it gets worse the more complex the expression. However, as a Groovy expression it remains simple and readable (and thus easier to validate :)
Title: WOString {
        value = "Hello Max" + name;
}

Now, which do you prefer? (Leaving aside inline stuff)

[1] http://wiki.objectstyle.org/confluence/display/WO/Project+WONDER- Frameworks-WOOgnl

with regards,
--

Lachlan Deck

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to