Personally, I've never found the dual nature of <s:layout-component>
confusing. Maybe that's just me. Whatever the case, adding a new tag isn't
an option for 1.5.4 because it's not backward-compatible. And after all the
work I've put in to get this streaming stuff working, I'm not interested in
yet another overhaul. I just don't think it's necessary.
Now, about streaming vs. buffering. Usually, when something gets buffered by
these tags, it's only a small chunk. And that usually doesn't matter anyway
because the page already has a buffer and when the tags' buffer gets flushed
it probably just goes to the page buffer. Obviously, there are exceptions;
otherwise, this never would have been a problem.
However, I figured it would be good to be able to stream everything even
using decorators so I made a little tweak a few days ago. You can now
reference a previous definition of a component within a component tag by
embedding a component tag having the same name. If you do that then there is
no need to render to a string, so the tags can just stream directly to
output. What that means is that in your layouts, you can change ${body} to
<s:layout-component name="body" /> and it will stream instead of buffer. For
example:
<s:layout-component name="body">
<table><tr><td>${body}</td></tr></table>
</s:layout-component>
becomes
<s:layout-component name="body">
<table><tr><td><s:layout-component name="body" /></td></tr></table>
</s:layout-component>
So there. Now you can stream to your heart's content. And as a bonus, you
get yet another context in which you can use the layout-content tag. :)
-Ben
On Tue, Jun 8, 2010 at 12:18 PM, kdeveloper <k-no-s...@a4consulting.nl>wrote:
> "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
>
------------------------------------------------------------------------------
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
