Interaction betwen IAjaxRegionMarkupIdProvider, renderPlaceholderTag and visibility

[Paul Jackson <Pa...@cdl.co.uk>]

Hi,

 

I've just discovered what I think is a bug with
IAjaxRegionMarkupIdProvider. We are using it on a Behavior that provides
a border to form components (label, mandatory marker, etc), which for
the most part works great.

 

We have encountered a problem when toggling the visibility of a form
component with this behavior via ajax. 

 

The component is first sent out visible and the markup is all correct.

 

A change elsewhere on the page causes the component to be set to not
visible and redrawn via ajax. The ajax response contains a tag with a
markupid generated via renderPlaceholderTag. This does not take into
account the  IAjaxRegionMarkupIdProvider behaviour.

 

Another change happens on the page causing the component to become
visible, and the ajax replace can't happen because the component with
the correct markupId is not present.

 

I think the problem is that renderPlaceholderTag should be aware of
IAjaxRegionMarkupIdProvider behaviours on the component when creating
the markupid. Should I raise a issue for this?

 

Cheers,

Paul

</PRE>
<p style="font-family:'Arial';font-size:8pt">
**********************************************************************<br>
Please consider the environment - do you really need to print this email?<br>
<br>
This email is intended only for the person(s) named above and may contain private and confidential information. If it has come to you in error, please destroy and permanently delete any copy in your possession and contact us on +44 (0) 161 480 4420. The information in this email is copyright &copy; CDL Group Holdings Limited. We cannot accept any liability for any loss or damage sustained as a result of software viruses. It is your responsibility to carry out such virus checking as is necessary before opening any attachment.<br>
Cheshire Datasystems Limited uses software which automatically screens incoming emails for inappropriate content and attachments. If the software identifies such content or attachment, the email will be forwarded to our Technology Department for checking. You should be aware that any email which you send to Cheshire Datasystems Limited is subject to this procedure. <br>
Cheshire Datasystems Limited, Strata House, Kings Reach Road, Stockport SK4 2HD<br>
Registered in England and Wales with Company Number 3991057<br>
VAT registration: 727 1188 33</p>
<PRE> 

Re: Interaction betwen IAjaxRegionMarkupIdProvider, renderPlaceholderTag and visibility

[Martin Grigorov <mg...@apache.org>]

It sounds like bug, yes.
I'm not sure how easy is to support it, though.
renderPlaceholderTag() will need to iterate over all ajax behaviors and
check whether they have region...

Create a ticket with a quickstart and we'll see what can be made.
Thanks!

On Fri, Mar 25, 2011 at 1:31 PM, Paul Jackson <Pa...@cdl.co.uk>wrote:

> Hi,
>
>
>
> I've just discovered what I think is a bug with
> IAjaxRegionMarkupIdProvider. We are using it on a Behavior that provides
> a border to form components (label, mandatory marker, etc), which for
> the most part works great.
>
>
>
> We have encountered a problem when toggling the visibility of a form
> component with this behavior via ajax.
>
>
>
> The component is first sent out visible and the markup is all correct.
>
>
>
> A change elsewhere on the page causes the component to be set to not
> visible and redrawn via ajax. The ajax response contains a tag with a
> markupid generated via renderPlaceholderTag. This does not take into
> account the  IAjaxRegionMarkupIdProvider behaviour.
>
>
>
> Another change happens on the page causing the component to become
> visible, and the ajax replace can't happen because the component with
> the correct markupId is not present.
>
>
>
> I think the problem is that renderPlaceholderTag should be aware of
> IAjaxRegionMarkupIdProvider behaviours on the component when creating
> the markupid. Should I raise a issue for this?
>
>
>
> Cheers,
>
> Paul
>
> </PRE>
> <p style="font-family:'Arial';font-size:8pt">
> **********************************************************************<br>
> Please consider the environment - do you really need to print this
> email?<br>
> <br>
> This email is intended only for the person(s) named above and may contain
> private and confidential information. If it has come to you in error, please
> destroy and permanently delete any copy in your possession and contact us on
> +44 (0) 161 480 4420. The information in this email is copyright &copy;
> CDL Group Holdings Limited. We cannot accept any liability for any loss or
> damage sustained as a result of software viruses. It is your responsibility
> to carry out such virus checking as is necessary before opening any
> attachment.<br>
> Cheshire Datasystems Limited uses software which automatically screens
> incoming emails for inappropriate content and attachments. If the software
> identifies such content or attachment, the email will be forwarded to our
> Technology Department for checking. You should be aware that any email which
> you send to Cheshire Datasystems Limited is subject to this procedure. <br>
> Cheshire Datasystems Limited, Strata House, Kings Reach Road, Stockport SK4
> 2HD<br>
> Registered in England and Wales with Company Number 3991057<br>
> VAT registration: 727 1188 33</p>
> <PRE>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>