One important thing about what I am proposing is that the xsl transform happens on the UI definition, NOT on the HTML that would have been displayed. And that xsl transform is done once when the code is built, it is not done on the fly which is what I take a renderer to mean.
David On Wednesday 25 April 2007 06:13, Chris Howe wrote: > Not a renderer for javascript, a renderer for GWT or a renderer for > Echo2 or for one of the xml based engines. It would transform the > screen definition into what is expected of the engine. The one you're > most used to is the one that transforms the screen definition into > html. It's very similar to what David G. is talking about with an xsl > transformation but using the methodology that Ofbiz uses by abstracting > it out to the renderer. > > http://svn.apache.org/viewvc/ofbiz/trunk/framework/widget/src/org/ofbiz/wid >get/ > > I don't have my head wrapped completely around where one part begins or > ends, but David J. or Jacopo might be able to add some insight. My > reply to David G. was a question, not an interrogative statement. > > --- Jonathon -- Improov <[EMAIL PROTECTED]> wrote: > > Chris, > > > > A renderer for javascript? Currently, the "renderer" I'm using is > > merely Freemarker. > > > > Jonathon > > > > 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 > > === message truncated ===
