I think I understand it better now. I suspect that StreamPageContent was
intentionally not added as a valid component-event return type in the ajax
case. After all, StreamPageContent is designed to render an entire page.
(duh) So I've made my code return a plain old page (as we used to do) if
it sees an ajax request.
On Wed, Apr 17, 2013 at 5:28 PM, Bryan Lewis <jbryanle...@gmail.com> wrote:
> Recently I started using the StreamPageContent feature to show the user an
> error message without losing the original page's address. For example:
>
> Object onActivate(Policy p)
> {
> if (p == null) {
> return new StreamPageContent(ErrorPage.class, "Invalid item");
> }
> }
>
> My page layout contains a search component using a zone, merely to allow
> displaying a "no results found" message without having to redraw the entire
> page:
>
> <t:form t:id="searchForm" t:zone="searchZone" ...>
> <t:zone t:id="searchZone" id="searchZone">${error}</t:zone>
> ...
> </t:form>
>
> A problem occurred today when the two messages happened together, an
> invalid item (because it had been deleted while the user was sitting in the
> page) and a no-results search. This caused an ajax dump on the page (which
> the user described as "a bunch of weird colored boxes all over the place"
> :-) and an exception in the log:
>
> org.apache.tapestry5.runtime.ComponentEventException: A component event
> handler method returned the value
> org.apache.tapestry5.services.StreamPageContent@6e65603b. Return type
> org.apache.tapestry5.services.StreamPageContent can not be handled.
> availableValues: AvailableValues[Configured return types: java.lang.Class,
> java.lang.String,
> org.apache.tapestry5.Link,
> org.apache.tapestry5.StreamResponse,
> org.apache.tapestry5.ajax.MultiZoneUpdate,
> org.apache.tapestry5.json.JSONArray,
> org.apache.tapestry5.json.JSONObject,
> org.apache.tapestry5.runtime.Component,
> org.apache.tapestry5.runtime.RenderCommand,
> org.apache.tapestry5.services.HttpError]
>
>
> I can't find a work-around for me to catch this situation. Maybe
> StreamPageContent should be added to the set of configured return types?
>
> Thanks.
>
>
>
