Standard practice for a controller's json event

[Bob Morley]

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"?

[Harmeet Bedi]

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" <[hidden email]>
To: [hidden email]
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.

[Harmeet Bedi]

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" <[hidden email]>
To: [hidden email]
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" <[hidden email]>
To: [hidden email]
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.