Ok Josh, I'll take you up on that. :) I submitted a patch on TAP5-1413
https://issues.apache.org/jira/browse/TAP5-1413

Please let me know if I submitted it right.  I want to make sure I'm
submitting patches that can actually be used.

Also, I'd love to see this patch get included sometime as I think it
would help with Tapestry branding:
https://issues.apache.org/jira/browse/TAP5-1323


Mark

On Fri, Jan 14, 2011 at 12:06 PM, Josh Canfield <[email protected]> wrote:
>> I believe that is what is happening, but does anyone know if this
>> "should" work?  I want to make sure I'm not taking advantage of
>> something that is just a side effect and may disappear in the future.
>
> The docs for MultiZoneUpdate say:
>  A mapping from <em>client-side zone ids</em> to objects that can
> render the content for that zone on the client.
>
> It accepts any object that can be coerced into a RenderCommand. A
> String can be coerced into a Renderable, which can be coerced to a
> Block, which is a RenderCommand. This is intentional so you aren't
> running into a side effect. If you want to be really really sure,
> check the source for the unit tests and if one doesn't exist for this
> use case submit a patch and I'll check it in. :)
>
> Josh
>
> On Fri, Jan 14, 2011 at 8:40 AM, Mark <[email protected]> wrote:
>>>> It turns out there is a simple way to do this. So simple I was
>>>> overlooking it. When you create a multizone update you give it the
>>>> client id and the zone you wish to update.  The zone will render with
>>>> the present context. However, you can also simply give it a string
>>>> with the contents you want rendered.
>>>
>>> I guess this is the built-in coercion from String to Block.
>>
>> I believe that is what is happening, but does anyone know if this
>> "should" work?  I want to make sure I'm not taking advantage of
>> something that is just a side effect and may disappear in the future.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to