Hmmm. The Tohu thing any use? Sounds like they are taking a sensible approach...
Incase not: > 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? I don't think GWT-RPC would/should change how you transport the data. XML has better tool support but JSON is very convenient with GWT (overlay types) and makes testing easy. Your Java/GWT objects could then be for the client only so have some behaviour inside them (good OO?) > There should be *no* external tools in place; instead, a usual "online This seems like the scary time consuming bit. Any idea of time budget? How many man months to get something out? > Eclipse Workbench, for GWT??? Nothing FOSS that I know of. This the closest I've seen: http://gwtgallery.appspot.com/about_app?app_id=158001 but closed source, commerical... I think there are some client side HTML WYSIWYG editors. Be a bit messy but you would get drag and drop form construction in the browser. A lot of them have "plugin" hooks. Not sure if you have six man months or sixty to play with.... > 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... This sounds like a sensible approach. I think the big choice is if you have lots of classes like EmptyValidator or a XPath or JavaScript based language. Same for logic about when a field is shown... e.g. <formItem name="willNotEat" showIf="implicitFormObject.hasAllergies.checked" /> > Briefly, what arch would you put in place??? Especially for the > client-side??? I think what you describe sounds about right for the end user code and should be doable. The form designer seems like the complicated bit. Is this for end users too? You doing something like a SaaS form designer? So the form designers are end user/customers too? > 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??? I have done this before, and at current day job. If you are careful then the end user part is not too bad, I think the worry is the admin CRUD. A rough idea of how many man months you have to do this would help. Is a big job, so even more reason to look at tohu. Cheers Sam -- 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.
