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.
----- "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
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
