Zsolt Koppany wrote:

Setting flush="true" inside of iterate throws an Exception.

Zsolt

Yes, exactly:
Can't insert page '/layouts/imageIcon.jsp' : Illegal to flush within a custom tag

That's why I set the flush attribute explicitly to "false" in beta 2. Is there
any way to fix this behavior with the iterate tag ? Otherwise I have to use a scriptlet for
the iteration, which I think is a big flaw.

Thanks,
Malte

On Tue, 2003-01-07 at 17:28, Cedric Dumoulin wrote:

Hi,

The PageContext.include(uri) documentation says:
"The current JspWriter "out" for this JSP is flushed as a side-effect of this call, prior to processing the include".
So, the old implementation was doing a flush regardless of the insert's flush value.
The new implementation now use RequestDispatcher.include(), which doesn't perform any flush ...

The implementation has changed in order to centralize all include calls in one customizable place. The behavior change is not intentional. Have you try to set flush=true in the insert tag ?

Cedric

Malte Gaudig wrote:


Hi there !

I've encountered a similar problem while "upgrading" from struts 1.1 b2 to
b3.
In my case the tiles:insert was nested inside a logic:iterate tag. Since
the tiles:insert tag is used inside the logic tag the attribute flush must
be set to true:

table
tr
td
logic:iterate
tiles:insert definition="a.X" flush="false"/
/logic:iterate
/td
/tr
/table

All inserted tiles appear on top of the page and not inside the table. On
beta 2 this all worked out fine. I've tested it with tomcat 4.0.6 and
4.1.18 get the same results.

Now I've tracked down the problem and it seems that the last change in the
class org.apache.struts.taglib.tiles.InsertTag is responsible for this
behaviour.
In the method doInclude the call

pageContext.include(page);

was replaced by

TilesUtil.doInclude(page,(HttpServletRequest)pageContext.getRequest(),
(HttpServletResponse)pageContext.getResponse(),
pageContext.getServletContext());

which is just an internal call to

request.getRequestDispatcher( uri ).include(request, response);

But why they behave differently I cannot tell, since I'm not the best
servlet expert.

Maybe someone can enlighten me, what the difference in the implementation is
and
why it was done. Or is there a workaround ?

Thanks,
Malte




-----Original Message-----
From: James Mitchell <[EMAIL PROTECTED]>
Subject: Odd Tiles Behavior with 2003-01-01 Nightly Build
Date: Thu, 2 Jan 2003 21:11:34 -0500
Content-Type: text/plain;
charset="US-ASCII"

That certainly does sound strange. I don't recall hearing anything like
this in the past.

Can you describe your settings with a bit more detail?
Have you made any configuration changes recently? (or using another
container)



--
James Mitchell
Software Engineer/Open Source Evangelist
http://www.open-tools.org

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but
when you do, it blows away your whole leg."
- Bjarne Stroustrup




-----Original Message-----
From: Paul Hodgetts, Agile Logic [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 02, 2003 9:07 PM
To: [EMAIL PROTECTED]
Subject: Odd Tiles Behavior with 2003-01-01 Nightly Build


I have a tiles application that was running fine on a
nightly build from 2002-12-03. I just installed the
nightly build from 2003-01-01. My tiles:insert sections
are now being inserted at the top of the HTML document
instead of at the point of the insert. E.g., instead of:

head
body
table
tr
td inserted tile 1 /td
td inserted tile 2 /td
/tr
/table
/body

I get:

inserted tile 1
inserted tile 2
head
body
table
tr
td /td
td /td
/tr
/table
/body

Weirdness. I've scanned the mailing list and release notes
for something related to this, but I couldn't find anything.
Any ideas?

Thanks,
Paul




--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>





--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to