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. -David On Apr 7, 2011, at 10:27 AM, Ean Schuessler wrote: > Hi David, > > As usual you are a fantastically productive guy. Its a little awe > inspiring. :-D > > Have you given any thought as to how different display technologies like > Vaadin, JSF or even Wicket could be accommodated in your framework? > Playing with Vaadin has shown me how I wish my views were constructed in > OFBiz. > > ~Ean > > On 04/02/11 01:09, David E Jones wrote: >> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today): >> >> http://www.moqui.org/ >> >> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0. >> >> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more). >> >> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project. >> >> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far. >> >> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it. >> >> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such. >> > -- > Ean Schuessler, CTO > [hidden email] > 214-720-0700 x 315 > Brainfood, Inc. > http://www.brainfood.com > > <ean.vcf> |
In reply to this post by David E. Jones-2
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 [hidden email] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com |
Yes, creating an object graph for Vaadin or Wicket should certainly be doable based on XML definitions of screens and forms. You could even have scriptlets for additional screen functionality in the platform-specific (or in Moqui render-mode) element. And interesting approach for this might be to create a Groovy script based on the screen/form XML files, much like the Moqui XML Actions template does. That template just uses FreeMarker Macros to create a script based on the XML (which makes it easy and computationally cheap to have Groovy expressions and scriptlets scattered about the XML), and that script is compiled using Groovy to a class which is cached for use (all at run-time). This would make an interesting add-on to Moqui, if anyone is interested. I've added a section on creating add-on components to the Introduction to Moqui Framework document (http://sourceforge.net/projects/moqui/files/), and there is now a page on the Moqui site to list add-on components (pretty empty right now... ;) ) at: http://www.moqui.org/crust.html One thing I wonder about using the Vaadin/Wicket approach and the OFBiz/Moqui approach together is how much value it would add to create Vaadin/Wicket screens from XML screen/form definitions. In other words, would it be easier to develop Vaadin/Wicket screen using their native Java code directly, or through an XML screen/form definition? On the other side of the coin, would the resulting UI for XML screens/forms be better based on Vaadin/Wicket than on plain old HTML, CSS, and jQuery? Before trying it out it may be hard to tell... or in other words only by trying it in a few scenarios would make answers to those questions clear. -David On Apr 8, 2011, at 8:39 AM, Ean Schuessler 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. > ----- "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 > [hidden email] > 214-720-0700 x 315 > Brainfood, Inc. > http://www.brainfood.com |
In reply to this post by Ean Schuessler
On Fri, Apr 8, 2011 at 3:39 PM, Ean Schuessler <[hidden email]> 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 > [hidden email] > 214-720-0700 x 315 > Brainfood, Inc. > http://www.brainfood.com > |
Free forum by Nabble | Edit this page |