On Fri, Apr 8, 2011 at 3:39 PM, Ean Schuessler <[email protected]> wrote:
>
> To me the convenience is being able to program to a straight AWT like
> interface. It is just so convenient to be able to do things like:
>
>
>
> myButton = new Button("Click Me", new Button.ClickListener() {
> public void buttonClick(ClickEvent event) {
> myLabel.setValue("You clicked my button"); // simple stuff like this
> dispatcher.runSync("SetPartyRole", [roleTypeId: 'BUTTON_CLICKER']); // or
> even things like this
> }
> });
>
>
> The process of binding these events to URLs to trigger services and
> worrying through AJAX processing just falls away. I could add a dozen
> buttons to a page and concentrate on the logic they trigger instead of a
> pile of oddly named events and url bindings. Sure there is some memory
> overhead there, sure it has state but man does it make some things easier.
>
>
> I think your answer (as I've illustrated above) makes perfect sense and you
> can definitely just trigger a service engine from these other frameworks.
> However, I've wondered for a while why we couldn't construct stateful graphs
> of UI objects from the XML widget descriptors and have the event bindings
> attach directly to the widgets.
>
There is "Declarative Layout" in GWT which is similar to what you have
described, but it still requires writing java classes. You can see it here:
http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html
Bilgin
> ----- "David E Jones" wrote:
> > That's a tough one. I just did some research on Vaadin, and in some ways
> it looks similar to Wicket, and I suppose in some ways similar to JSF as
> well, though Vaadin appears to be a sort of extension to GWT and the unlike
> Wicket where the Java code is mostly run on the server (if I understand
> right) in Vaadin most of the Java code is transformed using GWT and run on
> the client, turning the client into almost a desktop app that communicates
> with the server to mostly pass data around.
> > How to get any two technologies like these to work together is a good
> question, or at least how to get them to work together seamlessly. Say you
> want to write part of your app in Vaadin and part of it in Wicket... how
> will you get them to work together well? I think the answer is that you
> could have them both deployed in the same webapp, and pages written in each
> could link to each other, but sharing decoration (except by including the
> same text or using a tool to interpret a template that they can both
> include) and navigation and such would be a nightmare.
> > In Moqui, like in OFBiz, most of the web UI stuff is based on writing to
> a writer or stream and being able to assemble various pieces of text to
> create a single web page. Without getting into lower level code, I looked at
> each of these three (Vaadin, JSF, and Wicket) and it does not look like they
> have a way to generate text to be included in a web page, and perhaps worse
> handling navigation and links is so ingrained in the way the tools are
> designed that nothing there could be shared (not in ways that I could find,
> though of course with enough creative coding anything could be done in
> theory).
> > So, I guess the answer is that just like with OFBiz, with Moqui Framework
> if you want to use one of those web UI frameworks then use that instead of
> the Moqui XML Screens/Forms, and just use other parts of the Moqui API
> through the ExecutionContext that could be inited/destroyed in an event
> listener instead of the MoquiServlet (since the MoquiServlet wouldn't be
> used in that case), or if desperate you could use the Moqui class for static
> init of the ExecutionContextFactory and ExecutionContext.
> > That parts easy, ie use Moqui API for services, entities, and other tools
> but not for the web UI... trying to merge and share artifacts between these
> kinds of restrictive UI approaches would be tough. On the other hand, if you
> can get plain text out of them, you can include that in any Moqui XML
> Screen.
> > I don't think a better solution to this exists. Personally, I blame JSP
> and their restrictive nature that has been considered acceptable over the
> years, and those sorts of restrictions now seem to bleed into all sorts of
> web UI frameworks.
>
> --
> Ean Schuessler, CTO
> [email protected]
> 214-720-0700 x 315
> Brainfood, Inc.
> http://www.brainfood.com
>
