Dear Sam:
> If you like the Tohu spec (but not the implementation choice) could
> you not use their data model for describing forms? That is probably
> the most time consuming and painful to undo mistakes bit.
Tohu follows a different tech approach (server-side rule eval &
actions exec) compared to my client-side intended approach ... what I
would need is exactly their "rule engine"-based approach on the client
side, i.e. in JavaScript.
Nevertheless, I guess that their concepts could be taken and ported to
a JS version, basically having 'RuleSets' of 'Rules' (expressed via JS
statements) as "data structures" plus 'ActionSets' with N 'Action'
objects, each containing one JS function. Finaly 1 "big processing
routine" (the JS-implemented rules engine) for managing the 'EventBus'
and triggering (a) conditions evaluation and (a) action execution.
> Not sure I full understand the two open aspects you describe. Being an
> old geek bore I'll have a go.
> a) config for a form (probably bad interpretation).
> If "lifting" Tohu's data model doesn't work (wrong or licence issues)
> then I quite like your idea of starting with HTML. You can then use
> HTML5 syntax to add what you need.
> <form>
> <input type="text" name="foo" class="assertNotEmpty" />
> <input type="text" name="bar" data-hiddenIf="form.foo='blah'" />
> </form>
Well, your interpretation of the XML syntax extension of (X)HTML5 is
right.
My real problem actually is the JS-events-to-JS-function-call(s)
wirings, a mech basically consisting of (a) "condition script pieces"
and (b) "parameterized action functions" both intended to be
*reusable* for difference use cases within one HTML document. The
"configuration" I meant above should better be replaced by "dynamic
widget refs & widget params passing" into these reusable "condition
eval functions" as well as "action functions" during each use case --
or simply "dyn. invocation" would be the better term.
I guess my problem actually reduces to
* How do I achieve the evaluation of JS expression statements during
runtime and enact dyn. invocations with case-specific params???
Maybe this makes it a little bit clearer:
<form>
<input type="checkbox" name="cb1" value="Cats" checked="checked" /
> I like cats. <br/>
<input type="checkbox" name="cb2" value="Dogs" /> I like dogs. <br/
>
<input type="text" name="text-field" value="{initialValue1}">
<!-- shortcut form. (please, see also 2nd example below) -->
<visibleIF> ((cb1.checked=='true') AND (cb2.checked=='true')) </
visibleIF>
</input>
</form>
My problem is the dyn. eval. of these JS condition statements, and the
dyn. implicit call "text-field.visible="true" -- or better said:
"set(text-field, visible, true)".
A more detailed/"rules-oriented" form would be:
...
<input type="text" name="text-field" value="{initialValue1}">
<!-- other form including visibility rule (here: "guarded
actions") -->
<IF-THEN>
<IF> <cond>
((cb1.checked=='true') AND (cb2.checked=='true'))
</cond>
</IF>
<THEN>
<do> (text-field.visible='true') </do>
<do> (text-field.value= "Oh, you like cats and dogs") </do>
<do> ... </do>
</THEN>
</IF-THEN>
</input>
Here multiple actions get executed dynamically whenever the guard
evaluates 'true'.
Basically this "conditinal action(s) execution" in *JS* issue (fixed
events set, conditional evals, fixed actions set) would cover all my
requirements for the form controllers.
Perhaps you have some further suggestions based on your experiences.
Again, thank you very much in advance.
Best regards,
Alessandro
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
