You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@hlmksw.com> on 2008/02/15 16:50:33 UTC
Need help from a Java guru
I'm working on modifying the screen widgets to support Dojo (or any
other third party library). I set up the widgets to get their rendering
classes from a factory method instead of using the new operator. The
factory method uses the ObjectType.getInstance(...) methods to create
the class instances.
Everything works great except for one thing. Some of the rendering
classes have constructors that take
javax.servlet.http.HttpServletRequest
javax.servlet.http.HttpServletResponse
arguments. When I use the request and response objects found in the
screen widget context as arguments for the ObjectType.getInstance(...)
method, an exception is thrown - because the objects don't implement the
correct interfaces:
java.lang.NoSuchMethodException:
org.ofbiz.widget.html.HtmlFormRenderer.<init>(org.apache.catalina.connector.RequestFacade,
org.apache.catalina.connector.ResponseFacade).
Those classes implement the javax.servlet.ServletRequest and
javax.servlet.ServletResponse interfaces - which are the super
interfaces of the ones needed for the constructor.
I'm stuck. I don't know where to go from here.
Any ideas?
-Adrian
Re: Need help from a Java guru
Posted by Jacques Le Roux <ja...@les7arts.com>.
One point though : I'm not sure how XAP is dealing with i18n (for instance XUI manages i18n/i10n brilliantly). BTW I'm currently
looking at an i18n issue which seems related to Dojo use : https://issues.apache.org/jira/browse/OFBIZ-1652
Jacques
From: "David E Jones" <jo...@hotwaxmedia.com>
>
> It would be really cool to use this project for the OFBiz UI going forward (or at least part of it, I mean if not all).
>
> Has anyone played with this before? It looks like what we could do is have the form/screen/etc widgets generate XAL XML text and
> send it to XAP for processing and send that output to the browser.... That would be for the current widget elements.
>
> Another thing we could do is allow XAL within screen widget sections directly, and pass on the appropriate elements to XAP...
>
> Anyway, they have lots of little widgets in their library and it would be cool to have them supported.
>
> -David
>
>
> On Feb 15, 2008, at 11:37 PM, Jacopo Cappellato wrote:
>
>> Maybe it is off topic, and I've already sent this link in another thread one or two months ago, but what do you think about this
>> project:
>>
>> http://incubator.apache.org/xap/
>>
>> ?
>>
>> Could it help to enhance the widgets with dynamic elements?
>>
>> Jacopo
>>
>>
>> David E Jones wrote:
>>> On Feb 15, 2008, at 10:24 AM, Adrian Crum wrote:
>>>> Thanks David! I'll try your suggestion.
>>>>
>>>> Regarding the Dojo support strategy I had in mind: it has been mentioned in the past that something like that could be
>>>> implemented by extending the existing HTML rendering classes. I agree with that view, since these libraries simply add
>>>> attributes and such to regular HTML. Hence the factory method - a properties file specifies which rendering classes to use.
>>>> It works the same way as the FreeMarkerWorker loading transforms thing.
>>> Maybe we should step back then and discuss it in terms of possible usage rather than what is possible on the technology level.
>>>> I hadn't gotten to the widget XML side of things yet. The ideas I've had so far try to keep within the constraint that the
>>>> widget XML files should be rendering-platform independent. I don't have any specifics yet, but the general idea I had in mind
>>>> was to keep the existing widget elements, but have an additional element attribute that allows developers to pass
>>>> library-specific data to the rendering classes.
>>> Wouldn't that right there break the whole idea of being rendering platform independent?
>>>> Anyways, I was planning on submitting my current work to Jira for review and comment. Let me work out this one problem, submit
>>>> the patch to Jira, and then we can work out how to support Dojo, Ajax, etc. Does that sound okay?
>>> I'm sure something good will come of it, but in general a bit more planning and design might result in something more effective
>>> and long-term applicable.
>>> -David
>>>> David E Jones wrote:
>>>>> You should be able to cast the ones you pass in, but I'm still not totally sure how you're doing this.
>>>>> Could you send a code snippet or just commit the code you're working on in an inactive state (ie not called by anything)?
>>>>> BTW, in general for the AJAX stuff my thought was to add new widget elements to the screen definition for new types of UI
>>>>> elements, like an AJAX combo-box that does server-side lookups as the user is typing things in. I think we already have
>>>>> another combobox that is pre-populated when the page is loaded, but I'd rather have these be different in the screen
>>>>> definition XML so that both could be used and it would be easy to switch between them.
>>>>> In other words, I don't know if there is any place where we would override the default functionality, I'd rather add these as
>>>>> new features with new XML elements (or attributes to extend existing ones) and make them otherwise independent of the
>>>>> existing stuff.
>>>>> -David
>>>>> On Feb 15, 2008, at 8:50 AM, Adrian Crum wrote:
>>>>>> I'm working on modifying the screen widgets to support Dojo (or any other third party library). I set up the widgets to get
>>>>>> their rendering classes from a factory method instead of using the new operator. The factory method uses the
>>>>>> ObjectType.getInstance(...) methods to create the class instances.
>>>>>>
>>>>>> Everything works great except for one thing. Some of the rendering classes have constructors that take
>>>>>>
>>>>>> javax.servlet.http.HttpServletRequest
>>>>>> javax.servlet.http.HttpServletResponse
>>>>>>
>>>>>> arguments. When I use the request and response objects found in the screen widget context as arguments for the
>>>>>> ObjectType.getInstance(...) method, an exception is thrown - because the objects don't implement the correct interfaces:
>>>>>>
>>>>>> java.lang.NoSuchMethodException: org .ofbiz .widget .html .HtmlFormRenderer
>>>>>> .<init>(org.apache.catalina.connector.RequestFacade, org.apache.catalina.connector.ResponseFacade).
>>>>>>
>>>>>> Those classes implement the javax.servlet.ServletRequest and javax.servlet.ServletResponse interfaces - which are the super
>>>>>> interfaces of the ones needed for the constructor.
>>>>>>
>>>>>> I'm stuck. I don't know where to go from here.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> -Adrian
>>
>>
>
>
Re: Need help from a Java guru
Posted by Jacques Le Roux <ja...@les7arts.com>.
I really think we should have a closer look at XAP before beginning any effort around odjo-widget, what do you think ? There is an
integrated
solution for i18n for instance, and I'm sure there are more ready made artifacts like this...
Jacques
From: "David E Jones" <jo...@hotwaxmedia.com>
>
> It would be really cool to use this project for the OFBiz UI going forward (or at least part of it, I mean if not all).
>
> Has anyone played with this before? It looks like what we could do is have the form/screen/etc widgets generate XAL XML text and
> send it to XAP for processing and send that output to the browser.... That would be for the current widget elements.
>
> Another thing we could do is allow XAL within screen widget sections directly, and pass on the appropriate elements to XAP...
>
> Anyway, they have lots of little widgets in their library and it would be cool to have them supported.
>
> -David
>
>
> On Feb 15, 2008, at 11:37 PM, Jacopo Cappellato wrote:
>
>> Maybe it is off topic, and I've already sent this link in another thread one or two months ago, but what do you think about this
>> project:
>>
>> http://incubator.apache.org/xap/
>>
>> ?
>>
>> Could it help to enhance the widgets with dynamic elements?
>>
>> Jacopo
>>
>>
>> David E Jones wrote:
>>> On Feb 15, 2008, at 10:24 AM, Adrian Crum wrote:
>>>> Thanks David! I'll try your suggestion.
>>>>
>>>> Regarding the Dojo support strategy I had in mind: it has been mentioned in the past that something like that could be
>>>> implemented by extending the existing HTML rendering classes. I agree with that view, since these libraries simply add
>>>> attributes and such to regular HTML. Hence the factory method - a properties file specifies which rendering classes to use.
>>>> It works the same way as the FreeMarkerWorker loading transforms thing.
>>> Maybe we should step back then and discuss it in terms of possible usage rather than what is possible on the technology level.
>>>> I hadn't gotten to the widget XML side of things yet. The ideas I've had so far try to keep within the constraint that the
>>>> widget XML files should be rendering-platform independent. I don't have any specifics yet, but the general idea I had in mind
>>>> was to keep the existing widget elements, but have an additional element attribute that allows developers to pass
>>>> library-specific data to the rendering classes.
>>> Wouldn't that right there break the whole idea of being rendering platform independent?
>>>> Anyways, I was planning on submitting my current work to Jira for review and comment. Let me work out this one problem, submit
>>>> the patch to Jira, and then we can work out how to support Dojo, Ajax, etc. Does that sound okay?
>>> I'm sure something good will come of it, but in general a bit more planning and design might result in something more effective
>>> and long-term applicable.
>>> -David
>>>> David E Jones wrote:
>>>>> You should be able to cast the ones you pass in, but I'm still not totally sure how you're doing this.
>>>>> Could you send a code snippet or just commit the code you're working on in an inactive state (ie not called by anything)?
>>>>> BTW, in general for the AJAX stuff my thought was to add new widget elements to the screen definition for new types of UI
>>>>> elements, like an AJAX combo-box that does server-side lookups as the user is typing things in. I think we already have
>>>>> another combobox that is pre-populated when the page is loaded, but I'd rather have these be different in the screen
>>>>> definition XML so that both could be used and it would be easy to switch between them.
>>>>> In other words, I don't know if there is any place where we would override the default functionality, I'd rather add these as
>>>>> new features with new XML elements (or attributes to extend existing ones) and make them otherwise independent of the
>>>>> existing stuff.
>>>>> -David
>>>>> On Feb 15, 2008, at 8:50 AM, Adrian Crum wrote:
>>>>>> I'm working on modifying the screen widgets to support Dojo (or any other third party library). I set up the widgets to get
>>>>>> their rendering classes from a factory method instead of using the new operator. The factory method uses the
>>>>>> ObjectType.getInstance(...) methods to create the class instances.
>>>>>>
>>>>>> Everything works great except for one thing. Some of the rendering classes have constructors that take
>>>>>>
>>>>>> javax.servlet.http.HttpServletRequest
>>>>>> javax.servlet.http.HttpServletResponse
>>>>>>
>>>>>> arguments. When I use the request and response objects found in the screen widget context as arguments for the
>>>>>> ObjectType.getInstance(...) method, an exception is thrown - because the objects don't implement the correct interfaces:
>>>>>>
>>>>>> java.lang.NoSuchMethodException: org .ofbiz .widget .html .HtmlFormRenderer
>>>>>> .<init>(org.apache.catalina.connector.RequestFacade, org.apache.catalina.connector.ResponseFacade).
>>>>>>
>>>>>> Those classes implement the javax.servlet.ServletRequest and javax.servlet.ServletResponse interfaces - which are the super
>>>>>> interfaces of the ones needed for the constructor.
>>>>>>
>>>>>> I'm stuck. I don't know where to go from here.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> -Adrian
>>
>>
>
>
Re: Need help from a Java guru
Posted by David E Jones <jo...@hotwaxmedia.com>.
It would be really cool to use this project for the OFBiz UI going
forward (or at least part of it, I mean if not all).
Has anyone played with this before? It looks like what we could do is
have the form/screen/etc widgets generate XAL XML text and send it to
XAP for processing and send that output to the browser.... That would
be for the current widget elements.
Another thing we could do is allow XAL within screen widget sections
directly, and pass on the appropriate elements to XAP...
Anyway, they have lots of little widgets in their library and it would
be cool to have them supported.
-David
On Feb 15, 2008, at 11:37 PM, Jacopo Cappellato wrote:
> Maybe it is off topic, and I've already sent this link in another
> thread one or two months ago, but what do you think about this
> project:
>
> http://incubator.apache.org/xap/
>
> ?
>
> Could it help to enhance the widgets with dynamic elements?
>
> Jacopo
>
>
> David E Jones wrote:
>> On Feb 15, 2008, at 10:24 AM, Adrian Crum wrote:
>>> Thanks David! I'll try your suggestion.
>>>
>>> Regarding the Dojo support strategy I had in mind: it has been
>>> mentioned in the past that something like that could be
>>> implemented by extending the existing HTML rendering classes. I
>>> agree with that view, since these libraries simply add attributes
>>> and such to regular HTML. Hence the factory method - a properties
>>> file specifies which rendering classes to use. It works the same
>>> way as the FreeMarkerWorker loading transforms thing.
>> Maybe we should step back then and discuss it in terms of possible
>> usage rather than what is possible on the technology level.
>>> I hadn't gotten to the widget XML side of things yet. The ideas
>>> I've had so far try to keep within the constraint that the widget
>>> XML files should be rendering-platform independent. I don't have
>>> any specifics yet, but the general idea I had in mind was to keep
>>> the existing widget elements, but have an additional element
>>> attribute that allows developers to pass library-specific data to
>>> the rendering classes.
>> Wouldn't that right there break the whole idea of being rendering
>> platform independent?
>>> Anyways, I was planning on submitting my current work to Jira for
>>> review and comment. Let me work out this one problem, submit the
>>> patch to Jira, and then we can work out how to support Dojo, Ajax,
>>> etc. Does that sound okay?
>> I'm sure something good will come of it, but in general a bit more
>> planning and design might result in something more effective and
>> long-term applicable.
>> -David
>>> David E Jones wrote:
>>>> You should be able to cast the ones you pass in, but I'm still
>>>> not totally sure how you're doing this.
>>>> Could you send a code snippet or just commit the code you're
>>>> working on in an inactive state (ie not called by anything)?
>>>> BTW, in general for the AJAX stuff my thought was to add new
>>>> widget elements to the screen definition for new types of UI
>>>> elements, like an AJAX combo-box that does server-side lookups as
>>>> the user is typing things in. I think we already have another
>>>> combobox that is pre-populated when the page is loaded, but I'd
>>>> rather have these be different in the screen definition XML so
>>>> that both could be used and it would be easy to switch between
>>>> them.
>>>> In other words, I don't know if there is any place where we would
>>>> override the default functionality, I'd rather add these as new
>>>> features with new XML elements (or attributes to extend existing
>>>> ones) and make them otherwise independent of the existing stuff.
>>>> -David
>>>> On Feb 15, 2008, at 8:50 AM, Adrian Crum wrote:
>>>>> I'm working on modifying the screen widgets to support Dojo (or
>>>>> any other third party library). I set up the widgets to get
>>>>> their rendering classes from a factory method instead of using
>>>>> the new operator. The factory method uses the
>>>>> ObjectType.getInstance(...) methods to create the class instances.
>>>>>
>>>>> Everything works great except for one thing. Some of the
>>>>> rendering classes have constructors that take
>>>>>
>>>>> javax.servlet.http.HttpServletRequest
>>>>> javax.servlet.http.HttpServletResponse
>>>>>
>>>>> arguments. When I use the request and response objects found in
>>>>> the screen widget context as arguments for the
>>>>> ObjectType.getInstance(...) method, an exception is thrown -
>>>>> because the objects don't implement the correct interfaces:
>>>>>
>>>>> java.lang.NoSuchMethodException:
>>>>> org
>>>>> .ofbiz
>>>>> .widget
>>>>> .html
>>>>> .HtmlFormRenderer
>>>>> .<init>(org.apache.catalina.connector.RequestFacade,
>>>>> org.apache.catalina.connector.ResponseFacade).
>>>>>
>>>>> Those classes implement the javax.servlet.ServletRequest and
>>>>> javax.servlet.ServletResponse interfaces - which are the super
>>>>> interfaces of the ones needed for the constructor.
>>>>>
>>>>> I'm stuck. I don't know where to go from here.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> -Adrian
>
>
Re: Need help from a Java guru
Posted by Jacques Le Roux <ja...@les7arts.com>.
H Jacopo,
I did not notice at this time, but this looks a bit like XUI. Maybe synergy could be found...
My 2cts
Jacques
From: "Jacopo Cappellato" <ti...@sastau.it>
> Maybe it is off topic, and I've already sent this link in another thread
> one or two months ago, but what do you think about this project:
>
> http://incubator.apache.org/xap/
>
> ?
>
> Could it help to enhance the widgets with dynamic elements?
>
> Jacopo
>
>
> David E Jones wrote:
>>
>> On Feb 15, 2008, at 10:24 AM, Adrian Crum wrote:
>>
>>> Thanks David! I'll try your suggestion.
>>>
>>> Regarding the Dojo support strategy I had in mind: it has been
>>> mentioned in the past that something like that could be implemented by
>>> extending the existing HTML rendering classes. I agree with that view,
>>> since these libraries simply add attributes and such to regular HTML.
>>> Hence the factory method - a properties file specifies which rendering
>>> classes to use. It works the same way as the FreeMarkerWorker loading
>>> transforms thing.
>>
>> Maybe we should step back then and discuss it in terms of possible usage
>> rather than what is possible on the technology level.
>>
>>> I hadn't gotten to the widget XML side of things yet. The ideas I've
>>> had so far try to keep within the constraint that the widget XML files
>>> should be rendering-platform independent. I don't have any specifics
>>> yet, but the general idea I had in mind was to keep the existing
>>> widget elements, but have an additional element attribute that allows
>>> developers to pass library-specific data to the rendering classes.
>>
>> Wouldn't that right there break the whole idea of being rendering
>> platform independent?
>>
>>> Anyways, I was planning on submitting my current work to Jira for
>>> review and comment. Let me work out this one problem, submit the patch
>>> to Jira, and then we can work out how to support Dojo, Ajax, etc. Does
>>> that sound okay?
>>
>> I'm sure something good will come of it, but in general a bit more
>> planning and design might result in something more effective and
>> long-term applicable.
>>
>> -David
>>
>>
>>> David E Jones wrote:
>>>> You should be able to cast the ones you pass in, but I'm still not
>>>> totally sure how you're doing this.
>>>> Could you send a code snippet or just commit the code you're working
>>>> on in an inactive state (ie not called by anything)?
>>>> BTW, in general for the AJAX stuff my thought was to add new widget
>>>> elements to the screen definition for new types of UI elements, like
>>>> an AJAX combo-box that does server-side lookups as the user is typing
>>>> things in. I think we already have another combobox that is
>>>> pre-populated when the page is loaded, but I'd rather have these be
>>>> different in the screen definition XML so that both could be used and
>>>> it would be easy to switch between them.
>>>> In other words, I don't know if there is any place where we would
>>>> override the default functionality, I'd rather add these as new
>>>> features with new XML elements (or attributes to extend existing
>>>> ones) and make them otherwise independent of the existing stuff.
>>>> -David
>>>> On Feb 15, 2008, at 8:50 AM, Adrian Crum wrote:
>>>>> I'm working on modifying the screen widgets to support Dojo (or any
>>>>> other third party library). I set up the widgets to get their
>>>>> rendering classes from a factory method instead of using the new
>>>>> operator. The factory method uses the ObjectType.getInstance(...)
>>>>> methods to create the class instances.
>>>>>
>>>>> Everything works great except for one thing. Some of the rendering
>>>>> classes have constructors that take
>>>>>
>>>>> javax.servlet.http.HttpServletRequest
>>>>> javax.servlet.http.HttpServletResponse
>>>>>
>>>>> arguments. When I use the request and response objects found in the
>>>>> screen widget context as arguments for the
>>>>> ObjectType.getInstance(...) method, an exception is thrown - because
>>>>> the objects don't implement the correct interfaces:
>>>>>
>>>>> java.lang.NoSuchMethodException:
>>>>> org.ofbiz.widget.html.HtmlFormRenderer.<init>(org.apache.catalina.connector.RequestFacade,
>>>>> org.apache.catalina.connector.ResponseFacade).
>>>>>
>>>>> Those classes implement the javax.servlet.ServletRequest and
>>>>> javax.servlet.ServletResponse interfaces - which are the super
>>>>> interfaces of the ones needed for the constructor.
>>>>>
>>>>> I'm stuck. I don't know where to go from here.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> -Adrian
>
>
>
Re: Need help from a Java guru
Posted by Jacopo Cappellato <ti...@sastau.it>.
Maybe it is off topic, and I've already sent this link in another thread
one or two months ago, but what do you think about this project:
http://incubator.apache.org/xap/
?
Could it help to enhance the widgets with dynamic elements?
Jacopo
David E Jones wrote:
>
> On Feb 15, 2008, at 10:24 AM, Adrian Crum wrote:
>
>> Thanks David! I'll try your suggestion.
>>
>> Regarding the Dojo support strategy I had in mind: it has been
>> mentioned in the past that something like that could be implemented by
>> extending the existing HTML rendering classes. I agree with that view,
>> since these libraries simply add attributes and such to regular HTML.
>> Hence the factory method - a properties file specifies which rendering
>> classes to use. It works the same way as the FreeMarkerWorker loading
>> transforms thing.
>
> Maybe we should step back then and discuss it in terms of possible usage
> rather than what is possible on the technology level.
>
>> I hadn't gotten to the widget XML side of things yet. The ideas I've
>> had so far try to keep within the constraint that the widget XML files
>> should be rendering-platform independent. I don't have any specifics
>> yet, but the general idea I had in mind was to keep the existing
>> widget elements, but have an additional element attribute that allows
>> developers to pass library-specific data to the rendering classes.
>
> Wouldn't that right there break the whole idea of being rendering
> platform independent?
>
>> Anyways, I was planning on submitting my current work to Jira for
>> review and comment. Let me work out this one problem, submit the patch
>> to Jira, and then we can work out how to support Dojo, Ajax, etc. Does
>> that sound okay?
>
> I'm sure something good will come of it, but in general a bit more
> planning and design might result in something more effective and
> long-term applicable.
>
> -David
>
>
>> David E Jones wrote:
>>> You should be able to cast the ones you pass in, but I'm still not
>>> totally sure how you're doing this.
>>> Could you send a code snippet or just commit the code you're working
>>> on in an inactive state (ie not called by anything)?
>>> BTW, in general for the AJAX stuff my thought was to add new widget
>>> elements to the screen definition for new types of UI elements, like
>>> an AJAX combo-box that does server-side lookups as the user is typing
>>> things in. I think we already have another combobox that is
>>> pre-populated when the page is loaded, but I'd rather have these be
>>> different in the screen definition XML so that both could be used and
>>> it would be easy to switch between them.
>>> In other words, I don't know if there is any place where we would
>>> override the default functionality, I'd rather add these as new
>>> features with new XML elements (or attributes to extend existing
>>> ones) and make them otherwise independent of the existing stuff.
>>> -David
>>> On Feb 15, 2008, at 8:50 AM, Adrian Crum wrote:
>>>> I'm working on modifying the screen widgets to support Dojo (or any
>>>> other third party library). I set up the widgets to get their
>>>> rendering classes from a factory method instead of using the new
>>>> operator. The factory method uses the ObjectType.getInstance(...)
>>>> methods to create the class instances.
>>>>
>>>> Everything works great except for one thing. Some of the rendering
>>>> classes have constructors that take
>>>>
>>>> javax.servlet.http.HttpServletRequest
>>>> javax.servlet.http.HttpServletResponse
>>>>
>>>> arguments. When I use the request and response objects found in the
>>>> screen widget context as arguments for the
>>>> ObjectType.getInstance(...) method, an exception is thrown - because
>>>> the objects don't implement the correct interfaces:
>>>>
>>>> java.lang.NoSuchMethodException:
>>>> org.ofbiz.widget.html.HtmlFormRenderer.<init>(org.apache.catalina.connector.RequestFacade,
>>>> org.apache.catalina.connector.ResponseFacade).
>>>>
>>>> Those classes implement the javax.servlet.ServletRequest and
>>>> javax.servlet.ServletResponse interfaces - which are the super
>>>> interfaces of the ones needed for the constructor.
>>>>
>>>> I'm stuck. I don't know where to go from here.
>>>>
>>>> Any ideas?
>>>>
>>>> -Adrian
Re: Need help from a Java guru
Posted by Adrian Crum <ad...@yahoo.com>.
David E Jones <jo...@hotwaxmedia.com> wrote: > I hadn't gotten to the widget XML side of things yet. The ideas I've
> had so far try to keep within the constraint that the widget XML
> files should be rendering-platform independent. I don't have any
> specifics yet, but the general idea I had in mind was to keep the
> existing widget elements, but have an additional element attribute
> that allows developers to pass library-specific data to the
> rendering classes.
Wouldn't that right there break the whole idea of being rendering
platform independent?
No, I don't think so. My thinking is, I'd like to avoid another set of elements like the <platform--dependent> ones. For example, the existing container element could have something like
<container id="some-id" style="some-style" dojo="some Dojo data">
...
</container>
So, there is some data there to accomodate a third party library, but the element itself remains platform independent - other rendering methods simply ignore the dojo attribute.
On the other hand, something like
<some-dojo-element>
...
</some-dojo-element>
creates a problem. What do other rendering methods do in that scenario? Do we need to have corresponding non-dojo sets of elements in the same screen definition?
I agree we need to discuss how this should look in XML before any more work is done. I'll start another thread to get that discussion going. But I still believe, regardless of how the XML code looks in the end, we'll need a factory method to create rendering classes. ;-)
-Adrian
---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
Re: Need help from a Java guru
Posted by David E Jones <jo...@hotwaxmedia.com>.
On Feb 15, 2008, at 10:24 AM, Adrian Crum wrote:
> Thanks David! I'll try your suggestion.
>
> Regarding the Dojo support strategy I had in mind: it has been
> mentioned in the past that something like that could be implemented
> by extending the existing HTML rendering classes. I agree with that
> view, since these libraries simply add attributes and such to
> regular HTML. Hence the factory method - a properties file specifies
> which rendering classes to use. It works the same way as the
> FreeMarkerWorker loading transforms thing.
Maybe we should step back then and discuss it in terms of possible
usage rather than what is possible on the technology level.
> I hadn't gotten to the widget XML side of things yet. The ideas I've
> had so far try to keep within the constraint that the widget XML
> files should be rendering-platform independent. I don't have any
> specifics yet, but the general idea I had in mind was to keep the
> existing widget elements, but have an additional element attribute
> that allows developers to pass library-specific data to the
> rendering classes.
Wouldn't that right there break the whole idea of being rendering
platform independent?
> Anyways, I was planning on submitting my current work to Jira for
> review and comment. Let me work out this one problem, submit the
> patch to Jira, and then we can work out how to support Dojo, Ajax,
> etc. Does that sound okay?
I'm sure something good will come of it, but in general a bit more
planning and design might result in something more effective and long-
term applicable.
-David
> David E Jones wrote:
>> You should be able to cast the ones you pass in, but I'm still not
>> totally sure how you're doing this.
>> Could you send a code snippet or just commit the code you're
>> working on in an inactive state (ie not called by anything)?
>> BTW, in general for the AJAX stuff my thought was to add new widget
>> elements to the screen definition for new types of UI elements,
>> like an AJAX combo-box that does server-side lookups as the user is
>> typing things in. I think we already have another combobox that is
>> pre-populated when the page is loaded, but I'd rather have these be
>> different in the screen definition XML so that both could be used
>> and it would be easy to switch between them.
>> In other words, I don't know if there is any place where we would
>> override the default functionality, I'd rather add these as new
>> features with new XML elements (or attributes to extend existing
>> ones) and make them otherwise independent of the existing stuff.
>> -David
>> On Feb 15, 2008, at 8:50 AM, Adrian Crum wrote:
>>> I'm working on modifying the screen widgets to support Dojo (or
>>> any other third party library). I set up the widgets to get their
>>> rendering classes from a factory method instead of using the new
>>> operator. The factory method uses the ObjectType.getInstance(...)
>>> methods to create the class instances.
>>>
>>> Everything works great except for one thing. Some of the rendering
>>> classes have constructors that take
>>>
>>> javax.servlet.http.HttpServletRequest
>>> javax.servlet.http.HttpServletResponse
>>>
>>> arguments. When I use the request and response objects found in
>>> the screen widget context as arguments for the
>>> ObjectType.getInstance(...) method, an exception is thrown -
>>> because the objects don't implement the correct interfaces:
>>>
>>> java.lang.NoSuchMethodException:
>>> org
>>> .ofbiz
>>> .widget
>>> .html
>>> .HtmlFormRenderer
>>> .<init>(org.apache.catalina.connector.RequestFacade,
>>> org.apache.catalina.connector.ResponseFacade).
>>>
>>> Those classes implement the javax.servlet.ServletRequest and
>>> javax.servlet.ServletResponse interfaces - which are the super
>>> interfaces of the ones needed for the constructor.
>>>
>>> I'm stuck. I don't know where to go from here.
>>>
>>> Any ideas?
>>>
>>> -Adrian
Re: Need help from a Java guru
Posted by Adrian Crum <ad...@hlmksw.com>.
Thanks David! I'll try your suggestion.
Regarding the Dojo support strategy I had in mind: it has been mentioned
in the past that something like that could be implemented by extending
the existing HTML rendering classes. I agree with that view, since these
libraries simply add attributes and such to regular HTML. Hence the
factory method - a properties file specifies which rendering classes to
use. It works the same way as the FreeMarkerWorker loading transforms thing.
I hadn't gotten to the widget XML side of things yet. The ideas I've had
so far try to keep within the constraint that the widget XML files
should be rendering-platform independent. I don't have any specifics
yet, but the general idea I had in mind was to keep the existing widget
elements, but have an additional element attribute that allows
developers to pass library-specific data to the rendering classes.
Anyways, I was planning on submitting my current work to Jira for review
and comment. Let me work out this one problem, submit the patch to Jira,
and then we can work out how to support Dojo, Ajax, etc. Does that sound
okay?
-Adrian
David E Jones wrote:
>
> You should be able to cast the ones you pass in, but I'm still not
> totally sure how you're doing this.
>
> Could you send a code snippet or just commit the code you're working on
> in an inactive state (ie not called by anything)?
>
> BTW, in general for the AJAX stuff my thought was to add new widget
> elements to the screen definition for new types of UI elements, like an
> AJAX combo-box that does server-side lookups as the user is typing
> things in. I think we already have another combobox that is
> pre-populated when the page is loaded, but I'd rather have these be
> different in the screen definition XML so that both could be used and it
> would be easy to switch between them.
>
> In other words, I don't know if there is any place where we would
> override the default functionality, I'd rather add these as new features
> with new XML elements (or attributes to extend existing ones) and make
> them otherwise independent of the existing stuff.
>
> -David
>
>
> On Feb 15, 2008, at 8:50 AM, Adrian Crum wrote:
>
>> I'm working on modifying the screen widgets to support Dojo (or any
>> other third party library). I set up the widgets to get their
>> rendering classes from a factory method instead of using the new
>> operator. The factory method uses the ObjectType.getInstance(...)
>> methods to create the class instances.
>>
>> Everything works great except for one thing. Some of the rendering
>> classes have constructors that take
>>
>> javax.servlet.http.HttpServletRequest
>> javax.servlet.http.HttpServletResponse
>>
>> arguments. When I use the request and response objects found in the
>> screen widget context as arguments for the ObjectType.getInstance(...)
>> method, an exception is thrown - because the objects don't implement
>> the correct interfaces:
>>
>> java.lang.NoSuchMethodException:
>> org.ofbiz.widget.html.HtmlFormRenderer.<init>(org.apache.catalina.connector.RequestFacade,
>> org.apache.catalina.connector.ResponseFacade).
>>
>> Those classes implement the javax.servlet.ServletRequest and
>> javax.servlet.ServletResponse interfaces - which are the super
>> interfaces of the ones needed for the constructor.
>>
>> I'm stuck. I don't know where to go from here.
>>
>> Any ideas?
>>
>> -Adrian
>
>
Re: Need help from a Java guru
Posted by Adrian Crum <ad...@hlmksw.com>.
David,
I solved the problem. The code I mentioned is in this Jira issue:
https://issues.apache.org/jira/browse/OFBIZ-1648
-Adrian
David E Jones wrote:
>
> You should be able to cast the ones you pass in, but I'm still not
> totally sure how you're doing this.
>
> Could you send a code snippet or just commit the code you're working on
> in an inactive state (ie not called by anything)?
>
> BTW, in general for the AJAX stuff my thought was to add new widget
> elements to the screen definition for new types of UI elements, like an
> AJAX combo-box that does server-side lookups as the user is typing
> things in. I think we already have another combobox that is
> pre-populated when the page is loaded, but I'd rather have these be
> different in the screen definition XML so that both could be used and it
> would be easy to switch between them.
>
> In other words, I don't know if there is any place where we would
> override the default functionality, I'd rather add these as new features
> with new XML elements (or attributes to extend existing ones) and make
> them otherwise independent of the existing stuff.
>
> -David
>
>
> On Feb 15, 2008, at 8:50 AM, Adrian Crum wrote:
>
>> I'm working on modifying the screen widgets to support Dojo (or any
>> other third party library). I set up the widgets to get their
>> rendering classes from a factory method instead of using the new
>> operator. The factory method uses the ObjectType.getInstance(...)
>> methods to create the class instances.
>>
>> Everything works great except for one thing. Some of the rendering
>> classes have constructors that take
>>
>> javax.servlet.http.HttpServletRequest
>> javax.servlet.http.HttpServletResponse
>>
>> arguments. When I use the request and response objects found in the
>> screen widget context as arguments for the ObjectType.getInstance(...)
>> method, an exception is thrown - because the objects don't implement
>> the correct interfaces:
>>
>> java.lang.NoSuchMethodException:
>> org.ofbiz.widget.html.HtmlFormRenderer.<init>(org.apache.catalina.connector.RequestFacade,
>> org.apache.catalina.connector.ResponseFacade).
>>
>> Those classes implement the javax.servlet.ServletRequest and
>> javax.servlet.ServletResponse interfaces - which are the super
>> interfaces of the ones needed for the constructor.
>>
>> I'm stuck. I don't know where to go from here.
>>
>> Any ideas?
>>
>> -Adrian
>
>
Re: Need help from a Java guru
Posted by David E Jones <jo...@hotwaxmedia.com>.
You should be able to cast the ones you pass in, but I'm still not
totally sure how you're doing this.
Could you send a code snippet or just commit the code you're working
on in an inactive state (ie not called by anything)?
BTW, in general for the AJAX stuff my thought was to add new widget
elements to the screen definition for new types of UI elements, like
an AJAX combo-box that does server-side lookups as the user is typing
things in. I think we already have another combobox that is pre-
populated when the page is loaded, but I'd rather have these be
different in the screen definition XML so that both could be used and
it would be easy to switch between them.
In other words, I don't know if there is any place where we would
override the default functionality, I'd rather add these as new
features with new XML elements (or attributes to extend existing ones)
and make them otherwise independent of the existing stuff.
-David
On Feb 15, 2008, at 8:50 AM, Adrian Crum wrote:
> I'm working on modifying the screen widgets to support Dojo (or any
> other third party library). I set up the widgets to get their
> rendering classes from a factory method instead of using the new
> operator. The factory method uses the ObjectType.getInstance(...)
> methods to create the class instances.
>
> Everything works great except for one thing. Some of the rendering
> classes have constructors that take
>
> javax.servlet.http.HttpServletRequest
> javax.servlet.http.HttpServletResponse
>
> arguments. When I use the request and response objects found in the
> screen widget context as arguments for the
> ObjectType.getInstance(...) method, an exception is thrown - because
> the objects don't implement the correct interfaces:
>
> java.lang.NoSuchMethodException:
> org
> .ofbiz
> .widget
> .html
> .HtmlFormRenderer
> .<init>(org.apache.catalina.connector.RequestFacade,
> org.apache.catalina.connector.ResponseFacade).
>
> Those classes implement the javax.servlet.ServletRequest and
> javax.servlet.ServletResponse interfaces - which are the super
> interfaces of the ones needed for the constructor.
>
> I'm stuck. I don't know where to go from here.
>
> Any ideas?
>
> -Adrian