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 ===
> 
> 
> 

Reply via email to