I have not used it but Tohu  (http://jboss.org/tohu) sounds like what
you are looking for.

Let us know if it works for you

On Aug 8, 2:33 am, "A.Augustini" <[email protected]>
wrote:
> Hi Sam:
>
> For simplicity, I'll provide the "open details" inline:
>
> > There are more complete frameworks/application for what you are trying
> > to do. I'll try and dig out some links. Off top of
> > my head would something likehttp://metawidget.org/beuseful?
>
> Thank you for pointing me to "Metawidget"; It looks quite interesting,
> though I'm currently not sure how to (if it will be possible to)
> "inject" custom *client-side logic* (GWT code or JS functions) for the
> dynamic forms behavior. Maybe you already have some experiences with
> that.
> I'll take a closer look on "Metawidget" these coming days.
>
> > Not sure if you said what your server side technology would be. RDBMS,
> > Java...?
>
> Back-end techs: Java(EE) with JPA access to Derby or MySQL. But there
> could also be a XML/XSD storage (db or files) to store form
> descriptions. The actual orderings/purchases done via these forms
> should be in a RDBMS because of statistical analysis functionality
> (sales quantity per day/month/year, revenue, etc.)
> Front-end techs: JSF, GWT, or both (the complex GWT widgets integrated
> in "traditional" web pages).
>
> Before GWT consideration, the plan was to store the custom form specs
> in XML or JSON. Now, with GWT-RPC there would be a 3rd option,
> (de)serialized JS objects, right??? -- But XML or the less-verbose
> JSON would also be good for me, e.g. to remain GWT-independent.
> Which serialization tech would you choose for this?
>
> > [...]Maybe have your non-tech users designing the forms
> > in XML Spy or something like that. If your rules and validation get
> > complicated quickly it might be worth jumping to JavaScript as
> > the expression language. Even if you provide a nice UI on top of this
> > at least you will have a Turing complete engine at the outset.
>
> There should be *no* external tools in place; instead, a usual "online
> forms builder" where admins can define simple web forms either in a
> forms-based or in a graphical (form widget palette, form cavas, drag-
> and-drop, properties pane) manner.
> Btw., do you know a framework "mimicking" such a work area, like
> Eclipse Workbench, for GWT???
>
> The forms UIs are rather simple -- basically HTML forms with some
> DateTimePicker enhancements and field validation. The *problem* is
> their *dynamic behavior*, i.e. the widget-to-action bindings, how to
> specify them, and the underlying arch design that also permits an edit
> vs. preview mode.
>
> I think this arch will have to go in the following direction:
> A client-side "metawidget" ;-) downloads admin-provided form spec via
> GWT-RPC (in XML, JSON, or serialized JS format). This spec describes
> in an id- and css-based manner (a) the form layout, (b) the field
> widgets and their locations in the layout, (c) field validation rules,
> and (d) presentation rules (i.e. reactiveness hiding/reveiling fields/
> sections).
> The metawidget (1) dynamically instantiates all field widgets and
> "places them on the layout", (2) instantiates for each field the
> described validation rules and registers them with the corresp. field
> widget (alt.: "client-side validation event bus"?), (3) instantiates
> the "presentation rules" and registers them to a "client-side
> presentation event bus". Each widget always reports state changes to
> this "event bus"; there the state change event selects all event-
> matching, registered presentation rules and triggers their "action(s)
> section" which again results in *state change(s)* on the available
> form widgets, and which by themselves may again trigger more
> presentation rules, and so on...
>
> Briefly, what arch would you put in place???  Especially for the
> client-side???
>
> > Being in the browser XML and JS work nicely although not so great if
> > you back end is a RDBMS.
>
> Well, in my case the metadata parts (=form descriptions) could also be
> stored in XML into a XML db or webserver filesystem location.
> The data parts (=purchase orders) should be saved in a RDBMS due to
> statistics.
>
> I sincerely hope you've already made some experiences with such a
> scenario and can help me further outlining a practical architecture.
> As stated above, the main problems are (a) the client-side form logic
> instantiation, and (b) how to provide an "edit-and-preview mode ui"
> for admins (the preview result is the one later "recycled"/presented
> to the non-admin endusers (customers)). What would an arch for this
> look like???
>
> Thank you a million in advance.
>
> Best regards,
>   Alessandro
>
> > On Aug 5, 6:27 pm, "A.Augustini" <[email protected]>
> > wrote:
>
> > > Hello Sam:
>
> > > First of all, thanx a lot for your reply.
>
> > > > If I had similar spec to you (complicated interactive registration
> > > > that needs to happen on the client) then GWT seems like a good fit.
>
> > > Yes indeed, your spec is comparable mine: I've to build an *ordering
> > > form* with "injected" rules, which are *dynamically specified* by an
> > > admin via an Online Admin Module. These specifications are then stored
> > > in my backend database.
>
> > > > Depends a bit how often your registration fields and rules change. If
> > > > it is not very often then expressing them in Java (compiled to
> > > > JavaScript) seems much
> > > > the best way. Then you can write unit tests and use Java tooling...
>
> > > Once defined, the fields and rules don't change very much. The issue
> > > is that fields & rules must be programmable by a non-technical enduser
> > > (the admin mentioned above). -- So *Java* would't be very appropriate
> > > for this enduser-programming case; the idea is to offer admins a
> > > *declarative* method for specifying the form components and their
> > > behaviour in a textual (or better graphical) manner.
>
> > > > I've written the other extreme (UI to add fields, config
> > > > validation...) and it is a big task.
>
> > > It seems that this goes in the same direction (???), assuming that you
> > > have a graphical form composer and one kind (?) of rules, namely
> > > *field validation rules*.
> > > If your scenario is comparable to mine, could you please outline which
> > > GWT app components are in place and which responsibilities
> > > (collaborations) they have? I think this would help me a lot at the
> > > moment. ... And I would be very thankful for that.
>
> > > @all: I also would very much appreciate some other suggestions/ideas
> > > if there are any among you more experienced GWT users.
>
> > > Thank you very much in advance.
>
> > > Best regards,
> > >   Alessandro
>
> > > > On Aug 3, 12:36 pm, "A.Augustini"
>
> > > > <[email protected]> wrote:
> > > > > Currently learning GWT, and I still cannot imagine how to build a
> > > > > *rule-based* controller for a dynamically composed form -- preferably
> > > > > a multipage one, and -- due to GWT concepts -- obviously running on
> > > > > the client side in JavaScript.
>
> > > > > The idea is to have a multi-sections/multi-tabs registration form
> > > > > that:
> > > > > (a) shows its questions according to "question specs" from a
> > > > >      backend database,
> > > > > (b) gives the users instant input validation feedback via locally
> > > > >      centralized validation rules base,
> > > > > (c) controls the "questionary behaviour" after some locally
> > > > >      centralized "fill out" rules, e.g.,
>
> > > > >       * "When user fills out InputField A, hide section/tab C".
> > > > >       * "When user checks CheckBox B, also check boxes Y
> > > > >          and Z automatically".
> > > > >      * "When user selects D,E and F then show {widget} G".
> > > > >      * ...
>
> > > > > (d) finally submits all the collected data (from each form page/tab)
> > > > >      to a server-side service (i.e. 'submit' button triggers RPC).
>
> > > > > The main point is to optimally have all the validation, filter,
> > > > > action/
> > > > > behaviour, etc. rules centralized at one place -- hence the rule-based
> > > > > approach.
>
> > > > > The main issues are:
> > > > > 1. Which way to go for realizing such a "JavaScript Rule Engine"
> > > > >     solution in GWT?
>
> > > > > 2. Does there already exist a GWT framework or Composite targeting
> > > > >     *rule-based* form controllers for the client side?
>
> > > > > Hope some more experienced GWT programmers can help me further on
> > > > > this topic.
>
> > > > > Kindly 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.

Reply via email to