Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4236E238.40403@apache.org>
Date: Tue, 15 Mar 2005 14:25:12 +0100
From: Sylvain Wallez <sylvain@apache.org>
Organization: Anyware Technologies
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [cforms] Widget states in request-scoped forms
References: <4235F7BC.9000605@apache.org> <20050314234358.GB23086@localhost>
In-Reply-To: <20050314234358.GB23086@localhost>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tim Larson wrote:

>On Mon, Mar 14, 2005 at 09:44:44PM +0100, Reinhard Poetz wrote:
>  
>
>>Today I've tried to run a form that uses the widget state "INVISIBLE" and 
>>when the form state is saved in the request. (my experiments are based on 
>>the form1 action example)
>>
>>If I use the event framework to change the state from ACTIVE to INVISIBLE, 
>>toggling works, but the value of the changed widget gets lost.
>>
>>Looking at the samples I can't figure out ...
>>
>>- How can a widget have the state "INVISIBLE"? Where is this information 
>>stored, or better from where is it read?
>>
>>- If I'm right and the described behavior (losing the values of INVISIBLE 
>>widgets) is a bug, how can it be fixed? Any ideas?
>>    
>>
>
>I do not know if it is the same bug or not, but I re-encountered the bug
>that made me temporarily change fireEvents to be public so it could be
>called from flowscript (iirc it was reverted when I forgot how to trigger
>the bug.)
>

That's me who reverted this as I did not understood the need for making 
it public.

>The bug is that the firing of events sometimes get delayed
>until after showForm returns, causing very strange behavior.  Sorry I
>have not had time yet to track down the source of the problem.
>  
>

Ok. Let's wait until 2.1.7 is out and we will then add some code to 
check if there are some buffered when there normally should be none, and 
throw an exception in that case. That should quickly show where the 
problem is :-)

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director