Which is exactly what GWT gives you. The UI code in the form of a minimal HTML file and a lump of javascript are served by the we server by run on the client.
David On Wednesday 25 April 2007 05:40, Jonathon -- Improov wrote: > David, > > UI code on the client in the form of dynamically downloaded javascripts, > yes, that's good. But not UI definitions residing on the client. > > That's why I can't quite use SWT (Swing, UI with Java). Hefty deployment > costs. > > Jonathon > > David Goodenough wrote: > > Surely that is what JSON is for. It is just a javascript based RPC > > mechanism. Having the UI code on the client rather than the server > > is a good thing, its a perfectly good of the MVC models, and it means > > that it can be very responsive to the user and feels like a normal > > PC application. > > > > David > > > > On Tuesday 24 April 2007 18:52, BJ Freeman wrote: > >> I have a tool that creates SWT code. > >> the problem with JAVA based UI is that the application runs on the > >> client not the web server. So a interface has to be written to > >> communication with the ofbiz. > >> > >> Where I am going with this, is the Widgets xml is converted already in > >> ofbiz. So I would liked to see more functionality built into the > >> widgets, where possible, instead of having redundant functionality, in > >> some other form. > >> > >> For Java UI applications, I would like to see a standard interface > >> fleshed out for communication to Ofbiz. Then each developer can use > >> his/her favorite UI code to build on. > >> > >> David Goodenough sent the following on 4/24/2007 8:24 AM: > >>> I have not looked in detail, but given that OfBiz has an abstract > >>> definition of the UI and the processing it should be possible to > >>> have an xslt transform that generates a set of GWT java source that > >>> can be compiled and then used by the browser. Doing it dynamically > >>> would not seem sensible, but the code only needs to be regenerated > >>> when the UI definition changes. > >>> > >>> David > >>> > >>> On Tuesday 24 April 2007 16:11, Chris Howe wrote: > >>>> In that case, what would be the likelihood of being able to create a > >>>> renderer for it? > >>>> > >>>> --- David Goodenough <[EMAIL PROTECTED]> wrote: > >>>>> Tim, > >>>>> > >>>>> I am not at all sure what you mean by "tight coupling with the HTML". > >>>>> As you never (or should never) write any HTML as part of the GWT code > >>>>> this makes no sense. Yes the GWT controls are mapped to HTML, but > >>>>> you > >>>>> can make your own controls quite easily, and integrate them into the > >>>>> GWT framework so you are not limited to what simple HTML widgets can > >>>>> do. > >>>>> > >>>>> But I am merely a bystander when it comes to OfBiz, so it is for > >>>>> others > >>>>> to decide. What I was reacting to was the thought that getting > >>>>> Javascript > >>>>> expertise into OfBiz might be difficult, and so doing things in Java > >>>>> makes > >>>>> a lot of sense. Personally I find Javascript to be a problematic > >>>>> language, > >>>>> it is very powerful, almost too powerful - you can almost redefine > >>>>> the > >>>>> language as you go along - but being interpreted and not type safe in > >>>>> the > >>>>> way that Java is makes it a much more difficult language to use well. > >>>>> > >>>>> David > >>>>> > >>>>> On Tuesday 24 April 2007 14:39, Tim Ruppert wrote: > >>>>>> David, we did a number of pilots with GWT (and other frameworks) in > >>>>>> OFBiz and were much happier with the dojo toolkit. The GWT, while > >>>>>> having the bonus of being able to do everything in java, also > >>>>>> required a bit more of a tight coupling with the HTML - which in my > >>>>>> mind - made it less desirable. > >>>>>> > >>>>>> JSON is there in case you can show us all a better way of handling > >>>>>> it! Hope that helps. > >>>>>> > >>>>>> Cheers, > >>>>>> Tim > >>>>>> -- > >>>>>> Tim Ruppert > >>>>>> HotWax Media > >>>>>> http://www.hotwaxmedia.com > >>>>>> > >>>>>> o:801.649.6594 > >>>>>> f:801.649.6595 > >>>>>> > >>>>>> On Apr 24, 2007, at 7:06 AM, David Goodenough wrote: > >>>>>>> Jonathon, > >>>>>>> > >>>>>>> Probably the best approach would be to write an xslt script which > >>>>>>> would > >>>>>>> parse the OfBiz XML descriptors and generate skeleton code which > >>>>> > >>>>> could > >>>>> > >>>>>>> then be subclassed to put in specific processing (it may be > >>>>>>> possible to > >>>>>>> generate the whole thing, I have not looked closely enough). I > >>>>> > >>>>> am > >>>>> > >>>>>>> thinking > >>>>>>> of something like the juic system used by QtJambi - the new Java > >>>>>>> binding > >>>>>>> for Qt that Trolltech have currently in beta (juic was actually > >>>>>>> originally > >>>>>>> part of kdebindings but that is another story). > >>>>>>> > >>>>>>> It may sound odd, but actually it is best not to think about HTML > >>>>> > >>>>> and > >>>>> > >>>>>>> Javascript when coding GWT, it just complicates things. You can > >>>>>>> include > >>>>>>> explicit HTML or Javascript if necessary, but it is better to > >>>>> > >>>>> start > >>>>> > >>>>>>> from > >>>>>>> the position of doing it natively in GWT. It may be necessary > >>>>> > >>>>> (or > >>>>> > >>>>>>> desirable) > >>>>>>> to write some GWT code to emulate specific OfBiz widgets, I have > >>>>>>> not looked > >>>>>>> closely enough to find out. > >>>>>>> > >>>>>>> David > >>>>>>> > >>>>>>> On Tuesday 24 April 2007 13:22, Jonathon -- Improov wrote: > >>>>>>>> David, > >>>>>>>> > >>>>>>>> Seems to me the GWT will generate both the HTML (events) and the > >>>>>>>> Javascript > >>>>>>>> (event handlers). Is that correct? If so, I'd have to somehow > >>>>>>>> translate the > >>>>>>>> HTML output to OFBiz widgets. Still, GWT's support for coding in > >>>>>>>> Java is > >>>>>>>> cool. > >>>>>>>> > >>>>>>>> Yes, OFBiz supports JSON (via json-lib). I've been using it > >>>>> > >>>>> often > >>>>> > >>>>>>>> in Ajax > >>>>>>>> work with OFBiz. > >>>>>>>> > >>>>>>>> Jonathon > >>>>>>>> > >>>>>>>> David Goodenough wrote: > >>>>>>>>> You ask about whether there are Javascript experts around. Of > >>>>>>>>> course > >>>>>>>>> if you were to use GWT (Google Widget Toolkit), you do the > >>>>>>>>> programming > >>>>>>>>> in Java and it is translated into Javascript. That way you get > >>>>>>>>> all the > >>>>>>>>> strict typing of Java but the implementation on the browser > >>>>> > >>>>> without > >>>>> > >>>>>>>>> addons. GWT is of course now entirely open source and > >>>>> > >>>>> integrated > >>>>> > >>>>>>>>> into > >>>>>>>>> Eclipse quite easily. > >>>>>>>>> > >>>>>>>>> As I read it much of what is needed for using GWT is already > >>>>>>>>> present in > >>>>>>>>> Ofbiz, GWT can use JSON as its comms protocol and I think I am > >>>>>>>>> right in > >>>>>>>>> saying that JSON is supported by Ofbiz. You could use SOAP but > >>>>>>>>> JSON is > >>>>>>>>> lighter weight and as the execution environment is javascript > >>>>> > >>>>> is > >>>>> > >>>>>>>>> the more > >>>>>>>>> native protocol. GWT does have its own RPC protocol as well, > >>>>> > >>>>> in > >>>>> > >>>>>>>>> which > >>>>>>>>> case you would have to write the server end in its environment, > >>>>>>>>> but there > >>>>>>>>> is no requirement to use it, JSON (or even native HTTP) will do > >>>>>>>>> perfectly > >>>>>>>>> well. > >>>>>>>>> > >>>>>>>>> David > >>>>>>>>> > >>>>>>>>> On Tuesday 24 April 2007 04:33, Jonathon -- Improov wrote: > >>>>>>>>>> I was actually looking to pump in my enhancements to the > >>>>> > >>>>> Widget > >>>>> > >>>>>>>>>> module. > >>>>>>>>>> I've incorporated some Ajax-facilitating or Ajax-related > >>>>> > >>>>> features > >>>>> > >>>>>>>>>> directly into the Widget module, so I won't have to do HUGE > >>>>> > >>>>> .ftl > >>>>> > >>>>>>>>>> (s). > >>>>>>>>>> > >>>>>>>>>> Imagine being able to use and reuse a widget-screen for 2 (or > >>>>> > >>>>> more) > >>>>> > >>>>>>>>>> purposes: non-ajax operation and ajax operation (pulling down > >>>>>>>>>> various > >>>>>>>>>> sub-sub-parts of the screen). > >>>>>>>>>> > >>>>>>>>>> In general, I was able to make all listings screens (with the > >>>>>>>>>> Prev/Next > >>>>>>>>>> hrefs) load via Ajax. > >>>>>>>>>> > >>>>>>>>>> But be warned that this Ajax approach, if carried further, > >>>>> > >>>>> could > >>>>> > >>>>>>>>>> hark > >>>>>>>>>> back to those times when you programmed Java AWTs for rich UIs > >>>>>>>>>> (events > >>>>>>>>>> and concurrency). Except there's lots of javascript involved > >>>>> > >>>>> in > >>>>> > >>>>>>>>>> this > >>>>>>>>>> case, not Java, and bad news is there's no concurrency > >>>>> > >>>>> controls in > >>>>> > >>>>>>>>>> javascript. Which means, prepare to get wickedly good at > >>>>>>>>>> acrobatics in > >>>>>>>>>> javascript (obscure acquired taste, really), or deal with the > >>>>>>>>>> potential > >>>>>>>>>> mess and meltdown. Please let me know if there's any experts > >>>>> > >>>>> in > >>>>> > >>>>>>>>>> javascript OO and programming here. > >>>>>>>>>> > >>>>>>>>>> I'm willing to help with Ajax-ing OFBiz. Just let me know if > >>>>> > >>>>> the > >>>>> > >>>>>>>>>> "nice > >>>>>>>>>> addition" Andrew's talking about will go into Opentaps or > >>>>> > >>>>> OFBiz, > >>>>> > >>>>>>>>>> and > >>>>>>>>>> I'll follow. I only need to know if there's any anti-trust > >>>>> > >>>>> case > >>>>> > >>>>>>>>>> against > >>>>>>>>>> the body I'm contributing to. > >>>>>>>>>> > >>>>>>>>>> Jonathon > >>>>>>>>>> > >>>>>>>>>> Andrew Zeneski wrote: > >>>>>>>>>>> This sounds like it will be a nice addition to OFBiz, I can't > >>>>>>>>>>> wait to > >>>>>>>>>>> see the progress! > >>>>>>>>>>> > >>>>>>>>>>> Andrew > >>>>>>>>>>> > >>>>>>>>>>> On Apr 23, 2007, at 4:59 PM, Si Chen wrote: > >>>>>>>>>>>> If there are any developers interested in working on a CRM > >>>>>>>>>>>> system, > >>>>>>>>>>>> we're looking for more help here at Open Source Strategies. > >>>>>>>>>>>> We have > >>>>>>>>>>>> both full-time openings and part-time paid opportunities, > >>>>> > >>>>> and > >>>>> > >>>>>>>>>>>> you can > >>>>>>>>>>>> work from home and set your own hours. You'll have a chance > >>>>>>>>>>>> to work > >>>>>>>>>>>> with us on a combination of client projects, our open source > >>>> > >>>> === message truncated ===
