[OGo-Developer] extended bindings

[Helge Hess]

On Nov 3, 2006, at 20:47, YL wrote:
> (1)reduce coding efforts.
>      In wod file, instead of saying
>
>      UseBatching: WOConditional { condition = useBatching; }  //  
> and implement method "useBatching"
>
>      We can do (more handy binding sugestions are welcome)
>
>      UseBatching: XYConditional {
>          testingValueOne = searchingResults.count;
>          testingValueTwo =  
> session.sessionUser.userPreferences.batchSize;
>          operator = ">";
>      }

SOPE/JOPE supports that partially:

   IsBill: WOConditional {
     condition = address.type;
     value     = "bill";
   }

it doesn't have an operator though. Adding multiple conditions is a  
good idea, like:
   condition1 = address.type;
   value1     = "bill";
   condition2 = address.city;
   value2     = "London";

It would be also nice to have a 'key1' binding which resolves to a  
key instead of a value. Eg:
   key1   = addressKey;
   value1 = "bill";
'addressKey' will eg return 'address.type' which then will be  
evaluated against the component. This way you can easily have dynamic  
keys.


We also support EOQualifiers for conditions:

     IfPerson: WEQualifierConditional {
       condition = "isPerson=YES AND isCategory like '*customer*'";
       object    = currentPerson;
       negate    = NO;
     }

This one should be close to what you actually want.


>      We can do
> MyImage XYImage {  src = contentEO.@imageUrlWithImageName?ofType? 
> _apple|jpg; }
>
> expect url from method call
> [contentEO imageUrlWithImageName:@"apple" ofType: @"jpg"]
> or  contentEO.imageUrlWithImageName("apple","jpg")

In the JOPE/Java case one would probably just use an OGNL association  
which AFAIK can do all that and more.

In SOPE/ObjC it should be easy to add a trampoline in your code which  
does this. I'm not entirely sure what the best syntax would be, but  
writing a simple ObjC message expression parser is not too hard either.

Should be rather easy to support this:
   A: WOImage {
     src = [contentEO imageUrlWithImageName:@"apple" ofType:@"jpg";
   };

Possibly a day or two of work, not much more.


> will be assigned to src
>
> (2)support runtime manageable contents and more.
>
> MayImage:  XYField { dataDict = aDataDict; }
>
> // Where XYField is a WOSwitchComponent, the component name is  
> specified in aDataDict:
> {
>   WOComponentName = XYImage;
>   sourceObjectKeyPath = contentEO;
>   fieldKey = src;
>   valueKeyPath = "@imageUrlWithImageName?ofType?_apple|jpg:";
>   border = 0;
>   width = 135;
>   ...
> }
> And aDataDict can be from database, etc. that way one can have a  
> meta page (WOComponent) to handle various contentEOs and those EOs  
> are editable at runtime.

You want to retrieve element bindings from the database? I think this  
is ugly and won't work well. It should be done by a wrapper element  
instead, like this:

   MayImage: WOConstructElement {
     element  = "WOSwitchComponent";
     bindings = currentComponent.bindings;
   }

Might be useful, not sure. The element would need to instantiate  
WOSwitchComponent on every call with the dynamic bindings. But I  
think that would be acceptable and not really slower than dynamically  
resolving bindings instead of storing them in ivars.


> I hope to be able to make some changes at WOAssociation level to  
> solve most of the issues towards the featues I like. Any advises  
> are greatly appreciated.

Hm, see above. The only association related thing would be that  
WOObjCExpressionAssociation (aka super-mini WebScript), which would  
be neat.

Greets,
   Helge
-- 
Helge Hess
http://docs.opengroupware.org/Members/helge/