sorry site-conf.xsd is the xsd i was refering to.
It forces you to have >=1 response elements instead of >= 0 response elements
inside request-map.
Was suggesting that should be changed. the snippets below were from
site-conf.xsd
I also feel it should be a good idea to have a base class for JSON that is
something like this.
public abstract class BaseJSONEventHandler implements EventHandler {
// invoke json and end request map processing.
public final String invoke
(Event event, RequestMap requestMap, HttpServletRequest request,
HttpServletResponse response)
throws EventHandlerException
{
invokeJSONRequest(event, requestMap, request, response);
// terminate processing
return null;
}
public abstract void invokeJSONRequest
(Event event, RequestMap requestMap, HttpServletRequest request,
HttpServletResponse response)
throws EventHandlerException;
}
Harmeet
----- Original Message -----
From: "Harmeet Bedi" <[email protected]>
To: [email protected]
Sent: Thursday, July 23, 2009 9:34:06 PM GMT -05:00 US/Canada Eastern
Subject: Re: Standard practice for a controller's json event
It seems like ofbiz has a bit of support.
If event returns null request map processing does not seem to proceed to
response elements.
However the xsd forces you to allow request-map to have >= 0 response elements
instea do of current >= 1 response elements.
Perhaps xsd should be changed
From:
<xs:element name="request-map">
<xs:complexType>
<xs:sequence>
...
<xs:element maxOccurs="unbounded" ref="response"/>
</xs:sequence>
<xs:attributeGroup ref="attlist.request-map"/>
</xs:complexType>
</xs:element>
To:
<xs:element name="request-map">
<xs:complexType>
<xs:sequence>
...
<xs:element minOccurs="0" maxOccurs="unbounded" ref="response"/>
</xs:sequence>
<xs:attributeGroup ref="attlist.request-map"/>
</xs:complexType>
</xs:element>
This may be a good thing in any case as it allows events to be complete
handlers from xsd point of view instead of forcing response of type="none" in
chain.
Harmeet
----- Original Message -----
From: "Bob Morley" <[email protected]>
To: [email protected]
Sent: Thursday, July 23, 2009 1:46:44 PM GMT -05:00 US/Canada Eastern
Subject: Standard practice for a controller's json event
We have run into a problem related to a pattern that our company has
established with regards to handling json events. We have a pattern
something like this ...
<request-map uri="doStuff">
<event type="jsonservice" invoke="doCoolStuff" />
<response name="success" type="request" value="doRelatedCoolStuff" />
</request-map>
The trouble is with the nature of the json event -- it wraps up the results
from the service/event that is called and streams that back in the response.
The browser gets the JSON result from doCoolStuff and then has the
opportunity to perform another operation before "doRelatedCoolStuff" has
completed.
Naturally there is an easy fix to ensure that the second request's logic is
properly contained in "doCoolStuff"; what I am wondering is if there is
something we can do from a infrastructure perspective that would prevent
people from establishing this pattern in the future. I wonder if there are
any situations where you would want the response to an initial JSON request
to be anything other than of type "none"?
--
View this message in context:
http://www.nabble.com/Standard-practice-for-a-controller%27s-json-event-tp24631007p24631007.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
