[OGo-Developer] extended bindings

[YL]

Thank you very much Helge Hess. Lots good ideas and suggestions.
But I still have some questions. Below:

    > 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;
    >     }

So like to have
(1)multiipleConditions
(2)qualifierConditions
(3)obj/key/value
(4)testVars+operators

Very good idea, lots nice work already done in SOPE!

    > In the JOPE/Java case one would probably just use an OGNL association
    > which AFAIK can do all that and more.
    >
What the Java performance here? It's interesting.

    > 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.

Using regular ObjC message expression sounds the best. But I don't know
how to modify WOImage for this, maybe I can edit my XYImage for this.
But if you can list a outline of doing so, please help

        >>
        >> (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.
    >
The idea about store element config data into the database was started 
around
WO3.0 time. We need to host many many surveys and provide analyse tools
to business users. I've create a online survey editor for non-tech people to
manage their survey questions. So I have entities like
                       Survey <->>Questions
and my Questionnaire Page likes like
<webobject name=Questions>
<webobject name=AQuestionField></webobject>
</webobject name=Questions>
In wod:
Questions:             WORepetition { list = surveyEO.questions; item = 
aQuestion; }
AQuestionField:    XYFormField { question = aQuestion; responseSource = 
questionnaireResponse; }

XYFormField will as aQuestion for its type (PopUpButton, TextField etc)
and ask questionnaireResponse for existing response value if any. Even the
htmlPrefix and suffix around the question field html are stored in the 
database.
In short, Survey and Questions records hold the complete questionnaire data.

In that way, the questionnaire page can be the universal handler of suveys
and I have very simple idea about how to implement the survey editor for
business people.

The performance is fine although I don't know why. Even I use P-II 300Mh
machine to handle 400 question survey, still very fast. Bu if there are some
way to make this more efficient, that'll be great. One way in early days of
WO was to use replacement component instead of SwitchComponent. The
difference between them is swith over component object instead of switch
over component name. But I don't have the code and don't know how to
write my own.

There is another way of storing content data: store the template itself. But
this makes the implementing of content editor for non-tech people harder.
By using -templateWithName: method in the generic page, this way has
no performance overhead since the template can be cached (by default)
by application.

>
    >> 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.
>

I'll think this over. Thanks again