Ideally, it would be nice if the button did this for you -- feel free to
file an issue/RFE for the button. I'll have to defer your indeterminate
progress bar question to Animesh.
Dan
stuartr wrote:
> Dan , thats exactly what I implemented but didnt like the model. Just doesnt
> feel right.
> HOwever it does work,
>
> What Im finding a problem with is the indeterminate progress bar. Works fine
> with determinate when
> I change the state of the bar within the backing bean, but with
> indeterminate, I change the state and
> nothing happens on the client side.
> I checked the JSON msg using firebug and the state just sits at not_started.
> The status message binding
> works without a problem, but when I get the lookup to the widget at the
> backend, nothing I do to it such as setLogMessage(.... setTaskState(...
> etc has any effect on the client.
>
>
> Trying out some test programs to get to bottom of this but I just dont have
> any more slack on the project
> to experiment.
>
> BTW : Well done on the performance upgrade in the latest release, what a
> difference.
> and also, thanks for the fix on the bubble popping up in the wrong position
> on screen.
>
>
>
>
>
>
>
>
> Dan Labrecque wrote:
>
>> One thing you have to keep in mind is that the button runs through the
>> entire JSF life cycle. The last phase of the JSF life cycle is always
>> the rendering phase -- even when values are found to be invalid.
>> Depending on the navigation rules defined in the faces-config.xml file,
>> the user is typically forwarded to another page or the current page is
>> refreshed.
>>
>> In order to achieve the functionality you're looking for, you might
>> consider using a hidden field and a value change event. When the user
>> clicks the button, call the submit() function of the hidden field. The
>> value is submitted asynchronously and if the value has changed, an event
>> will be fired for your backing bean to listen to. The page will not
>> refresh because we have overridden the rendering phase here. Instead of
>> re-rendering the hidden field, we return some JSON data indicating
>> success or failure. You can actually subscribe to the "submit.endTopic"
>> event if you're interested in using that to kick off the progress bar.
>>
>> Typically, this type of behavior can be applied to anything that holds
>> an HTML element value. It's difficult to support this for a button
>> because it does not actually submit anything. Although, I'll take a look
>> and see if there is something we can do here. We may be able to trick it
>> into submitting a special hidden field, for example.
>>
>> Dan
>>
>> stuartr wrote:
>>
>>> Can someone point me in the right direction to allow me to NOT re-render
>>> a
>>> page when I click a button
>>> All I want to do is
>>> 1. Onclick, fire off an event to the backing bean to start something .
>>> 2. popup a div showing a progress bar widget.
>>> 3. let the popup div have a STOP button that will send a stop to the back
>>> end using ajax.
>>>
>>> I dont want an page re-rendering and I know I can do this simply in the
>>> non
>>> woodstock world.
>>> However, surely there must be a method of doing this within woodstock
>>> button
>>> widgets .
>>>
>>> I succesfully use the update() on other areas of my apps to dynamically
>>> change things on the display
>>> and guessed that woodstock must have a layer that I can access to invoke
>>> a
>>> method on the backing bean.
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
>> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>>
>>
>>
>>
>
>