Re: Escaping in strings according to WOML
Re: Escaping in strings according to WOML
- Subject: Re: Escaping in strings according to WOML
- From: Mike Schrag <email@hidden>
- Date: Tue, 30 Jun 2009 13:13:15 -0400
This requires an association factory registered per function, though,
right? Part of the niceness of helpers is how they are registered and
resolved ...
For instance, I can just create PersonHelper, and somePerson|
displayName will automatically look for PersonHelper and call
displayName on it, just based on the type of the bound object. It
will also walk the inheritance tree, so you can have
EOGenericRecordHelper and it will look up the inheritance tree to find
the class or interface helper that defines the function you're
referencing (so you can do "$anyEO|id" and it will call
EOGenericRecordHelper.id(eo) ). Also, because it's implemented behind
the scenes as an OGNL expression, you can pass arbitrary params "for
free" -- so I can do "$paragraph|highlight(word)" and it will call
StringHelper.highlight(String paragraph, String word). On top of
that, if your binding evaluates to null (say "somePerson" was a null
in the first example) it actually computes the Class name of the
bindings (we have an NSKVC impl that operates purely on Classes, not
on the objects themselves) and figures out what type the object WOULD
have been (obviously limited by what you declare it to be) and calls
the appropriate helper passing a null, so you can do helpers with null
values. So in the first example somePerson was null, it would figure
out that somePerson was a Person class from the type declaration of
the binding (this works on keypaths too) and would dispatch to
PersonHelper.displayName(null) so you can display "No name
available" (or whatever).
My impression, though, is that it's quite a bit more programmatically
expensive to register functions in the 5.4 parser and it wouldn't have
the fancy scoping or resolution. I think maybe you'd have to do
something like "helper: person|displayName", maybe, and parse it with
a fancier association factory?
In the Wonder one, the way we do it is that as it parses, it actually
turns into an OGNLAssociation behind the scenes, and we just jam the
parameters onto the end of the registry lookup. For example, that
"$paragraph|highlight(word)" becomes:
~
@ognl
.helperfunction
.WOHelperFunctionRegistry
@registry()._helperInstanceForFrameworkNamed(#this, "paragraph",
"highlight", "app").highlight(paragraph, word)
it's sort of magical, but actually works :) gotta love ognl ...
Oh, the other thing that would be nice in the 5.4 parser is support
for "// VALID" There are cases where the WOLips validator can't
provably validate an expression (not often, but happens). The Wonder
parser has an extension to WOD and inline bindings that allows you to
do:
Test : WOString {
value = someKVCExpressionThatCantBeStaticallyResolved; // VALID
}
and
<wo:str value="$someKVCExpressionThatCantBeStaticallyResolved //
VALID"/>
so the WOLips validator can hide warnings on them.
ms
On Jun 30, 2009, at 12:36 PM, Mr. Pierre Frisch wrote:
Mike there is only one space difference:
<wo:string value="[person|displayName]" />
or
<wo:string value="[displayName: person]" />
Cheers
Pierre
--
Pierre Frisch
email@hidden
On Jun 29, 2009, at 15:46, Mike Schrag wrote:
I suppose we just need to integrate them as association and add
them to the association factory. This is trivial to do.
yeah, i'm pretty sure 5.4's parser can do it with a custom factory,
but I'm concerned about how much typing it will require to actually
use it ... helpers are cool because it's so easy to drop into a
binding (change from "$person" to "$person|displayName"). if you
have to switch to a different association namespace to get it on a
binding, i think it might suck more, but I'll withhold judgment.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden