cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Goupinets <ngoupin...@openskysolutions.ca>
Subject Re: [Portal] Cocon 2.1.7 upgrade breaks CachingURICoplets
Date Fri, 22 Jul 2005 14:29:25 GMT
Hi Jean-Christophe,

Thank you very much for your reply. The thread, link to which you 
included, solves the problem completely.

Sincerely,
Nick.

Jean-Christophe Kermagoret wrote:
> I have the following in my forms in the cocoon portal :
> <form action="portal" ...>
>     <input type="hidden" name="cocoon-portal-event" value="19">
>     <input type="hidden" name="cocoon-portal-action" value="1">
> 
> cocoon-portal-event and cocoon-portal-action are hidden fields, not a 
> query string that seems to be ignored.
> 
> I followed this code snippet :
> http://www.mail-archive.com/users@cocoon.apache.org/msg24454.html
> 
> HTH
> 
> Nick Goupinets a écrit :
> 
>> Hello,
>>
>> After going through some more debugging, I think I figured out why 
>> continuation is not resumed: coplet content is taken from cache. 
>> That's not much of a relief because now I am faced with the question 
>> why cache is not refreshed.
>>
>> I've done some more debugging in order to resolve this new issue. It 
>> looks like when portal event processing chain is started, 
>> ActionCounterEventAspect class can not locate "cocoon-portal-action" 
>> request parameter when processing the problematic coplet. This forces 
>> it not to continue processing chain. Thus coplet is not refreshed :(.
>>
>> I attempted to check if this parameter is present in the request 
>> object. It looks like it's not, in case there is 
>> enctype="multipart/form-data" attribute present in the form tag 
>> ("cocoon-portal-action" parameter can be found however in the string 
>> returned by Request.getRequestQuery() method).
>>
>> In case I remove this enctype attribute from the form, coplet starts 
>> working like charm, except file uploads will not be functional.
>>
>> Is is a bug or am I doing something wrong? Some (any?) feedback to 
>> this problem is greatly appreciated.
>>
>> Thank you very much in advance.
>>
>> Sincerely,
>>
>> Nick Goupinets.
>>
>> P.S.
>>
>> Request parameters for coplet that works fine (no enctype):
>> =============================================================
>> Request URI          : /TaporMain/portal/portal
>> Request Query        : null
>> cocoon-portal-action : 1
>> cocoon-portal-event  : 7
>> useToolOnText - Use Tool on Source Text
>> cocoon-portal-event - 7
>> link -
>> continuation-id - 3b265b105b5167651d3a5a29266f7d6d4668837d
>> forms_submit_id -
>> texts - 1
>> tools - 3
>> cocoon-portal-action - 1
>> =============================================================
>>
>> Request parameter for the coplet that doesn't work (enctype present):
>> =============================================================
>> Request URI          : /TaporMain/portal/portal
>> Request Query        : cocoon-portal-action=2&cocoon-portal-event=8
>> cocoon-portal-action : null
>> cocoon-portal-event  : null
>> forms_submit_id - selectForClientSide
>> selectForClientSide - bench_htmlInput
>> htmlTag - body
>> optionSeletion -
>> mytexts_htmlInput - 1
>> sorting - 1
>> continuation-id - 4042555c305f6f6369091a02604c313c2e71415e
>> resultWindow - true
>> listOption - all
>> outFormat - html
>> =============================================================
>>
>> Form snippet for the coplet that doesn't work:
>> =============================================================
>> <form enctype="multipart/form-data" name="toolBrokerForm" 
>> method="post" onsubmit="forms_onsubmit(); " 
>> action="portal?cocoon-portal-action=5&cocoon-portal-event=8">
>> <div>
>> <input name="forms_submit_id" type="hidden">
>> </div>
>> ....
>> =============================================================
>>
>> If I remove enctype attribute from the form, everything starts working 
>> just fine. Here are the request parameters for the coplet that didn't 
>> work (cocoon-portal-action and cocoon-portal-event are present)
>> =============================================================
>> Request URI          : /TaporMain/portal/portal
>> Request Query        : null
>> cocoon-portal-action : 6
>> cocoon-portal-event  : 8
>> forms_submit_id -
>> selectForClientSide - upload_htmlInput
>> context - 1
>> contextLength - 5
>> htmlTag - body
>> continuation-id - 12777d5936373c6e76086d4811332a0a16287b77
>> cocoon-portal-action - 6
>> toolBrokerSubmit - Submit
>> pattern - a
>> upload_htmlInput - view-deschampsxlii.xml
>> cocoon-portal-event - 8
>> resultWindow - true
>> outFormat - html
>> =============================================================
>>
>>
>> Nick Goupinets wrote:
>>
>>> Hi everybody,
>>>
>>> I am trying to upgrade our project that is based on the portal block 
>>> from Cocoon 2.1.5 to Cocoon 2.1.7. Right now I run into a very 
>>> annoying problem which I have no idea how to solve: All of 
>>> CachingURICoplets that use CForms stop functioning after form gets 
>>> shown. It just looks as if continuation is not resumed.
>>>
>>> Here is an example. When the following code is executed:
>>>
>>> =====================================================
>>> cocoon.load("resource://org/apache/cocoon/forms/flow/javascript/Form.js"); 
>>>
>>>
>>> var toolBrokerInst = null;
>>>
>>> // called from the sitemap
>>> function toolBroker(userID, toolID, showDataBench, textUrl) {
>>>   print("STARTED ToolBroker");
>>>   if (toolID == '' || toolID == null) {
>>>     toolID = cocoon.session.getAttribute("toolID");
>>>     ...
>>>     }
>>>   if (toolID != null){
>>>     try {
>>>       toolBrokerInst = cocoon.getComponent( .... );
>>>       cocoon.session.removeAttribute("toolID");
>>>       showFormForTool(userID, toolName, newWin, showDataBench, textUrl);
>>>     } finally {
>>>       cocoon.releaseComponent(toolBrokerInst);
>>>     }
>>>   } else {
>>>     print("CALLING SEND PAGE");
>>>     cocoon.sendPage("selectATool");
>>>   }
>>> }
>>>
>>> function showFormForTool(userID,
>>>     toolName,
>>>     newWin,
>>>     showDataBench,
>>>     textUrl){
>>>
>>>   print("STARTED ShowFormForTool");
>>>   ...     var form = new Form("cocoon:/"
>>>    +toolName+"-definition?inputType="
>>>    +inputType+"&textTypes="
>>>    +textTypes+"&showDataBench="
>>>    +showDataBench);
>>>
>>>   var textID = cocoon.session.getAttribute("textID");
>>>   form.lookupWidget("resultWindow").setValue(true);
>>>   print("SHOWING FORM FROM ShowFormForTool");
>>>   form.showForm(toolName+"-display?inputType="
>>>     +inputType+"&addSourceText="
>>>     +addSourceTextFlag+"&newWin="+newWin);
>>>   print("RETRUNED TO ShowFormForTool SUCCESSFULLY");
>>>   ...
>>> }
>>>
>>> =====================================================
>>>
>>> It produces this output:
>>>
>>> =====================================================
>>> STARTED ToolBroker
>>> CALLING SEND PAGE
>>> STARTED ToolBroker
>>> STARTED ShowFormForTool
>>> SHOWING FORM FROM ShowFormForTool
>>> =====================================================
>>>
>>> Initially, when portal tab containing the coplet is displayed, first 
>>> 2 lines are printed:
>>>
>>> STARTED ToolBroker
>>> CALLING SEND PAGE
>>>
>>> After that, when the session var's are set properly, the remaining 3 
>>> lines are printed. However, at this point it doesn't matter what 
>>> happens inside of the coplet, nothing else gets printed (where there 
>>> should be "RETRUNED TO ShowFormForTool SUCCESSFULLY") on the console 
>>> or changes in the coplet.
>>>
>>> Logs don't show any errors or give any clues what can go wrong. 
>>> Additionally, the same version of the coplet works perfectly fine on 
>>> Cocoon 2.1.5.
>>>
>>> If there was anybody who had similar problems when upgrading, I would 
>>> appreciate it very much if you can share the solution or at least 
>>> point me in the right direction.
>>>
>>> Thank you very much in advance.
>>>
>>> Sincerely,
>>> Nick Goupinets.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message