In the project I'm currently porting from 1.4.x to 6.6.0 I've
run into an issue with Wicket pages which stream binary data
into the WebResponse (e.g. ZIP archives created on the fly).

First thing I found was that obviously I *have* to create
templates for these pages even though they are not going to be
used for anything. 

The second thing is more serious: when writing to the response I
get an IllegalStateException as the template code has already
been written to it. This can be circumvented by calling
Response.reset() before Response.write() in my code. However in
development mode I still get an ISE as in Page.onAfterRender()
there's this code here:

| if (getApplication().getDebugSettings().isOutputMarkupContainerClassName())
| {
|     String className = Classes.name(getClass());
|     getResponse().write("<!-- Page Class ");
|     getResponse().write(className);
|     getResponse().write(" END -->\n");
| }
                                                                                
                                                                }
Now of course I can write:

| @Override
| protected void onAfterRender() {
|   try { super.onAfterRender(); } catch (IllegalStateException e) { }
| }

... but I guess we agree that while this works it is far from nice.

I am not sure if I understand correctly what the above code is
trying to tell me. Does it mean that I am simply not supposed to
deliver my ZIP files by a Wicket page that way? 

If with today's Wicket version there's a different or even better
way to do this, which one would that be?

Else, would there be any harm in making the Page class more
friendly to this kind of use, by e.g. putting the above
if-statement into an overridable method and adding an option to
the Component class to tell it that there's no markup for it and
it should simply not expect any?

Cheers,

M'bert

-- 
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+= 
My Hovercraft is full of eels!

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to