> 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 <mark-li...@xeric.net> 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: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
