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/be useful? 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.
