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
>
>
>
--
View this message in context: http://www.nabble.com/Cant-get-ajax-event-on-woodstock-button-tp15718766p15754027.html
Sent from the Project Woodstock - Dev mailing list archive at Nabble.com.