Alessandro, Ignoring the UI for a moment and assuming HTML5 as your data model (for model, layout and behaviour) then I guess the non admin end user runtime could be something like this: 1) We have the HTML5 from your previous example (is the admin user going to type in the expressions?) 2) Use the DOM parser to generate the UI of your heavy GWT Widgets MyTextBox etc, also creates MyRule objects in the tree of Widgets (So pure GWT UI created from your HTML definition but not using that in the browser) 3) The MyX Widgets connection themselves to the event bus. 4) Big decision is if you just have JavaScript objects that the expressions work on or is the actual HTML Form objects... Pros and Cons of both. For sake of argument say you have the scripts act directly on the real form. 5) Your MyTextBox widget has an onchange handler that fires events on the event bus. 6) MyRule widget listens to events that may interest it. 7) MyRule may choose to execute the JS expressions (to see if they should run) if they do then they fire another event to tell the MyTextBox etc that the underlying DOM may have changed. (Think you might need to make your own wrapper to JS eval function. The JSONUtils probably does the same thing but safer to do your own). You might want to use a global variable like "form" to make it clear what they are accessing. 8) MyTextBox checks to see if it is dirty. If it is it might re-draw something.
This is pretty brute force and lots of events but is at least simple. Not sure how you are going to drive the UI which would probably influence how you code the rules. If very noddy interface you might have XML for the rule like: <do><MySet field="testField" value="Oh, you like cats and dogs" /></ do> ... You could still have an "Expert" one that lets them do any crazy thing that is possible in JS. At their own risk. I might be tempted by a more functional approach where you define properties so you don't have to have rules for making things visible then hidden. e.g. <MyVisibleRule field="testField" test="cb1.checked && cb2.checked" /> Is the usual tough question of when is a DSL better than a general purpose language. The semantic HTML movement will also probably be very helpful as presumably you only want semantic markup in your form definition. Cheers Sam On Aug 12, 11:18 am, "A.Augustini" <[email protected]> wrote: > 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.
