Proper modeling of parameters and impact to page refresh ... (SVN 13393)

[Bob Morley]

We ran into a problem where we have now properly modeled all  
parameters to controller requests with the "parameter" element; for  
example here is a properly modeled link ...

         <menu-item name="Items" title="${uiLabelMap.Items}">
             <link target="ViewSalesOrder">
              <parameter param-name="orderId" from-
field="parameters.orderId"/>
             </link>
         </menu-item>

What ofbiz does when it attempts to render this link, is determine if  
it should render it as an anchor or with a hidden form.  The  
determining factor here is if the controller request "ViewSalesOrder"  
has an event defined.  If it has an event, it must render as a hidden  
form for security reasons.  In this case, ViewSalesOrder will call an  
event to properly create and save the ShoppingCart object into the  
session.  As a result, we now render this as a POST instead of a GET  
(when the parameters were defined as query string arguments).

After this happens, there may be a number of things that happen to the  
page that require us to do a page refresh.  This is typically done as  
part of a modal box operation.  What we had done in the past was use  
the document.location.href to refresh the page.  Now that these  
navigation links are rendered as POSTs this no longer works, and a  
number of bugs had been created around "missing orderId" and similar  
problems as part of that refresh.

Our solution right now was to fix how we do a refresh page.  I have  
created a "reloadPage" javascript snippet that gets rendered on all  
Emforium themed pages in the footer.  This uses the request to build a  
proper request to reload the page with the url, parameters, and  
request method.  The modal box inclusion now uses this function  
instead of its own location.href refreshing mechanism.  A number of  
parameters that were setting this success function directly have been  
removed in favor of this new method.

This was checked in as part of revision 13393 and has resolved a few  
tickets such as EMF-3403.

There should be no direct developer impact.  After an svn refresh you  
may be assigned tickets that were related to this problem and have now  
been fixed.  Please let me know if you have any questions or concerns.


Robert Morley
Senior Software Developer
Emforium Group Inc.
ALL-IN Software™
519-772-6824 ext 220
[hidden email]

[Marc Morin]

Not sure you wanted to post this to dev@ofbiz mailing list!!!!

Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
[hidden email]

----- "Robert Morley" <[hidden email]> wrote:

> We ran into a problem where we have now properly modeled all  
> parameters to controller requests with the "parameter" element; for  
> example here is a properly modeled link ...
>
>          <menu-item name="Items" title="${uiLabelMap.Items}">
>              <link target="ViewSalesOrder">
>               <parameter param-name="orderId" from-
> field="parameters.orderId"/>
>              </link>
>          </menu-item>
>
> What ofbiz does when it attempts to render this link, is determine if
>
> it should render it as an anchor or with a hidden form.  The  
> determining factor here is if the controller request "ViewSalesOrder"
>
> has an event defined.  If it has an event, it must render as a hidden
>
> form for security reasons.  In this case, ViewSalesOrder will call an
>
> event to properly create and save the ShoppingCart object into the  
> session.  As a result, we now render this as a POST instead of a GET
>
> (when the parameters were defined as query string arguments).
>
> After this happens, there may be a number of things that happen to the
>  
> page that require us to do a page refresh.  This is typically done as
>
> part of a modal box operation.  What we had done in the past was use
>
> the document.location.href to refresh the page.  Now that these  
> navigation links are rendered as POSTs this no longer works, and a  
> number of bugs had been created around "missing orderId" and similar
>
> problems as part of that refresh.
>
> Our solution right now was to fix how we do a refresh page.  I have  
> created a "reloadPage" javascript snippet that gets rendered on all  
> Emforium themed pages in the footer.  This uses the request to build a
>  
> proper request to reload the page with the url, parameters, and  
> request method.  The modal box inclusion now uses this function  
> instead of its own location.href refreshing mechanism.  A number of  
> parameters that were setting this success function directly have been
>
> removed in favor of this new method.
>
> This was checked in as part of revision 13393 and has resolved a few
>
> tickets such as EMF-3403.
>
> There should be no direct developer impact.  After an svn refresh you
>
> may be assigned tickets that were related to this problem and have now
>  
> been fixed.  Please let me know if you have any questions or
> concerns.
>
>
> Robert Morley
> Senior Software Developer
> Emforium Group Inc.
> ALL-IN Software™
> 519-772-6824 ext 220
> [hidden email]

[Scott Gray-2]

But since you did, can I just say that the event handlers aren't really intended for data preparation which should be done in the view handling :-)

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 27/04/2010, at 10:53 AM, Marc Morin wrote:

> Not sure you wanted to post this to dev@ofbiz mailing list!!!!
>
> Marc Morin
> Emforium Group Inc.
> ALL-IN Software
> 519-772-6824 ext 201
> [hidden email]
>
> ----- "Robert Morley" <[hidden email]> wrote:
>
>> We ran into a problem where we have now properly modeled all  
>> parameters to controller requests with the "parameter" element; for  
>> example here is a properly modeled link ...
>>
>>         <menu-item name="Items" title="${uiLabelMap.Items}">
>>             <link target="ViewSalesOrder">
>>             <parameter param-name="orderId" from-
>> field="parameters.orderId"/>
>>             </link>
>>         </menu-item>
>>
>> What ofbiz does when it attempts to render this link, is determine if
>>
>> it should render it as an anchor or with a hidden form.  The  
>> determining factor here is if the controller request "ViewSalesOrder"
>>
>> has an event defined.  If it has an event, it must render as a hidden
>>
>> form for security reasons.  In this case, ViewSalesOrder will call an
>>
>> event to properly create and save the ShoppingCart object into the  
>> session.  As a result, we now render this as a POST instead of a GET
>>
>> (when the parameters were defined as query string arguments).
>>
>> After this happens, there may be a number of things that happen to the
>>
>> page that require us to do a page refresh.  This is typically done as
>>
>> part of a modal box operation.  What we had done in the past was use
>>
>> the document.location.href to refresh the page.  Now that these  
>> navigation links are rendered as POSTs this no longer works, and a  
>> number of bugs had been created around "missing orderId" and similar
>>
>> problems as part of that refresh.
>>
>> Our solution right now was to fix how we do a refresh page.  I have  
>> created a "reloadPage" javascript snippet that gets rendered on all  
>> Emforium themed pages in the footer.  This uses the request to build a
>>
>> proper request to reload the page with the url, parameters, and  
>> request method.  The modal box inclusion now uses this function  
>> instead of its own location.href refreshing mechanism.  A number of  
>> parameters that were setting this success function directly have been
>>
>> removed in favor of this new method.
>>
>> This was checked in as part of revision 13393 and has resolved a few
>>
>> tickets such as EMF-3403.
>>
>> There should be no direct developer impact.  After an svn refresh you
>>
>> may be assigned tickets that were related to this problem and have now
>>
>> been fixed.  Please let me know if you have any questions or
>> concerns.
>>
>>
>> Robert Morley
>> Senior Software Developer
>> Emforium Group Inc.
>> ALL-IN Software™
>> 519-772-6824 ext 220
>> [hidden email]

[Bob Morley]

Scott Gray-2 wrote

But since you did, can I just say that the event handlers aren't really intended for data preparation which should be done in the view handling :-)

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 27/04/2010, at 10:53 AM, Marc Morin wrote:

> Not sure you wanted to post this to dev@ofbiz mailing list!!!!

Ahh crap my mistake heh!  Scott -- I agree and will look closer at what we are doing here.  We had an number of formerly navigation (anchor) links that got converted to hidden form when we changed how they were being represented in xml for the screen/form.  I suspect Ofbiz might have the same ... any controller request that is a simple page render should not have an "event" coded or it would exhibit this behaviour.

[Scott Gray-2]

On 28/04/2010, at 12:19 AM, Bob Morley wrote:

> Scott Gray-2 wrote:
>>
>> But since you did, can I just say that the event handlers aren't really
>> intended for data preparation which should be done in the view handling
>> :-)
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 27/04/2010, at 10:53 AM, Marc Morin wrote:
>>
>>> Not sure you wanted to post this to dev@ofbiz mailing list!!!!
>>
>
> Ahh crap my mistake heh!  Scott -- I agree and will look closer at what we
> are doing here.  We had an number of formerly navigation (anchor) links that
> got converted to hidden form when we changed how they were being represented
> in xml for the screen/form.  I suspect Ofbiz might have the same ... any
> controller request that is a simple page render should not have an "event"
> coded or it would exhibit this behaviour.

If the hidden form links are being generated by OFBiz's widget code then you can usually specify the type of link that is generated instead of using the default auto type which exhibits this behaviour.  POSTed parameters are only an enforced requirement of service events so as long as you're using a different type of event then GET requests should be fine.

Regards
Scott

[Bob Morley]

On Apr 27, 2010, at 8:29 AM, Scott Gray wrote:

>
> If the hidden form links are being generated by OFBiz's widget code  
> then you can usually specify the type of link that is generated  
> instead of using the default auto type which exhibits this  
> behaviour.  POSTed parameters are only an enforced requirement of  
> service events so as long as you're using a different type of event  
> then GET requests should be fine.
>

Yep that was the original solution but we did not want to go through  
the entire application and find all "navigation" links to mark them  
with link-type="anchor" (or whatever the grammar is).  I think your  
original point is what I am going to look into further; perhaps having  
something that is really a navigation link having a controller request  
that includes an "event" is wrong in the first place.  That logic  
could be moved into the screen which would also avoid this whole  
problem, make our links bookmark-able again, etc etc.  Thanks for your  
input!