"Anytime you reference a layout component in EL (e.g., ${body} as in
your sample files) then that component has to be evaluated and buffered
as a string."
OK, sounds logical.
But why use EL if it stops the layout from streaming? I know it's the
only way to reference a layout-component from the layout-definition
while you are within a layout-render. But this would not be necessary if
an extra tag would be introduced for referring to the layout-component.
That would also fix, the current confusing dual usage of the current
layout-component tag, because the tag currently addresses two
semantically different things:
a) It's a tag that defines the layout-component in a lay-out definition
(kind of incoming parameter).
b) It's a tag to reference layout-components from a layout-renderer
(kind of outgoing parameter).
This dual nature of the layout-component tag leads to confusion and
hence creates unnecessary complexity. Thus why not use two separate tag
names, for two semantically different things? One tag for defining the
layout-component in a layout-definition (the current layout-component
name). An other tag for referring to a layout-component in a
layout-renderer (this would be a new tag, for example named
layout-component-reference).
Does this make sense? Is this even possible? Does this make full
streaming layouts possible?
On 08-06-10 3:46, Ben Gunter wrote:
> Great to hear the layouts are rendering properly for you now. The goal
> was to make them behave as closely as possible to the 1.5.3 release. The
> new code does behave a little differently from 1.5.3 in some cases, but
> I think those differences are actually improvements over the last
> release. I know there was one case (though I can't recall it at the
> moment) where 1.5.3 would not handle nesting the way I expected it to,
> but the new code handles it just fine. The new layout tags play nicely
> with form tags now, for example, when a layout definition contains a
> form tag and a layout component contains a partial form. Also, things
> execute in the order one expects them to, which definitely wasn't the
> case before. In 1.5.3 all the component tags executed first and then the
> definition tag executed, which threw people off sometimes.
>
> The layout tags do stream directly to output now when used in the
> simplest fashion. That is, just straight use of the layout-definition,
> layout-render and layout-component tags. When you use the "decorator
> pattern," as Freddy describes in his book, then streaming isn't really
> an option sometimes. Anytime you reference a layout component in EL
> (e.g., ${body} as in your sample files) then that component has to be
> evaluated and buffered as a string. The good news is that components are
> only evaluated and buffered like that on-demand. The object you're
> referencing isn't a String but an Object whose toString() method renders
> the component to a string and returns it. So the buffering only happens
> when it's actually needed, and only what *must* be buffered is buffered.
>
> -Ben
>
> On Mon, Jun 7, 2010 at 6:26 PM, kdeveloper
> <k-no-s...@a4consulting.nl
> <mailto:k-no-s...@a4consulting.nl>> wrote:
>
> Ben,
>
> The Stripes 1.5.4 beta R1252 seems to render the layouts in my projects
> just as the 1.5.3 release version. I will do some more checks later this
> week.
>
> Do these layout now render directly to the servlet output stream?
>
> -Karen
>
>
> On 08-06-10 0:09, kdeveloper wrote:
> >
> > Pre-build Stripes 1.5.4 (R1252) can be downloaded here:
> >
> > http://kdeveloper.com/stripes-1-5-4-beta/
> >
> >
> > On 07-06-10 22:53, Ben Gunter wrote:
> >> I believe this is fixed with my most recent commit. Everybody please
> >> test out the latest 1.5.x branch and let me know how it goes.
> >>
> >> -Ben
> >>
> >> On Mon, Jun 7, 2010 at 8:44 AM, Ben Gunter
> >> <gunter...@gmail.com
> <mailto:gunter...@gmail.com>
> >> <mailto:gunter...@gmail.com
> <mailto:gunter...@gmail.com>>> wrote:
> >>
> >> Excellent, thank you. I'll do some testing/bug hunting with
> these
> >> and get back to you.
> >>
> >> -Ben
> >>
> >>
> >> On Mon, Jun 7, 2010 at 8:31 AM, kdeveloper
> >> <k-no-s...@a4consulting.nl
> <mailto:k-no-s...@a4consulting.nl>
> >> <mailto:k-no-s...@a4consulting.nl
> <mailto:k-no-s...@a4consulting.nl>>> wrote:
> >>
> >> Ben,
> >>
> >> I've made as simple as possible JSP files that can
> reproduce the
> >> layout
> >> rendering problem in Stripes 1.5.4 beta (R1250). The
> three layers of
> >> layout's seems crucial in reproducing the failure.
> >>
> >>
> >>
> >> testPage.jsp:
> >>
> >> <%...@taglib prefix="s"
> >> uri="http://stripes.sourceforge.net/stripes.tld"; %>
> >> [testPage-begin]
> >> <s:layout-render name="/testPageLayout.jsp">
> >> <s:layout-component name="body">
> >> [testPage-body]
> >> </s:layout-component>
> >> </s:layout-render>
> >> [testPage-end]
> >>
> >>
> >>
> >> testPageLayout.jsp:
> >>
> >> <%...@taglib prefix="s"
> >> uri="http://stripes.sourceforge.net/stripes.tld"; %>
> >> <s:layout-definition>
> >> [testPageLayout-begin]
> >> <s:layout-render name="/testPageIntermediateLayout.jsp">
> >> <s:layout-component name="body">
> >> [testPageLayout-preBody]
> >> ${body}
> >> [testPageLayout-postBody]
> >> </s:layout-component>
> >> </s:layout-render>
> >> [testPageLayout-end]
> >> </s:layout-definition>
> >>
> >>
> >> testPageIntermediateLayout.jsp:
> >>
> >> <%...@taglib prefix="s"
> >> uri="http://stripes.sourceforge.net/stripes.tld"; %>
> >> <s:layout-definition>
> >> [Intermediate-begin]
> >> <s:layout-render name="/testPageSuperLayout.jsp">
> >> <s:layout-component name="body">
> >> [IntermediateLayout-preBody]
> >> ${body}
> >> [IntermediateLayout-postBody]
> >> </s:layout-component>
> >> </s:layout-render>
> >> [Intermediate-end]
> >> </s:layout-definition>
> >>
> >>
> >> testPageSuperLayout.jsp
> >>
> >> <%...@taglib prefix="s"
> >> uri="http://stripes.sourceforge.net/stripes.tld"; %>
> >> <s:layout-definition>
> >> [SuperLayout-begin]
> >> ${body}
> >> [SuperLayout-end]
> >> </s:layout-definition>
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
>
>
>
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
