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.

Reply via email to