Hi.
In my opinion, this is rather a tricky way to shut yourself in the head.
Well, I am still alive (without hole in my head ... but hey .... whats
happening .... its getting darke.......r..... ) ;-)
Yeah, me too. But puzzled a bit, you know...
The main goal StreamingAddResource tried to address was, to avoid any
additional buffering which will delay the delivery of the page. Since
there are different needs from different users this is why you can
replace the implementation as you would like to.
With DefaultAddResource main delay was to re-parse the response and output
scripts where they should be. I don't think buffering as is is a heavy burden.
It's just something like ~50kb written into a buffer and then this buffer
flushed into the output stream, this are milliseconds!
Think from the other side. Having that 123/header.css you have to intercept this
URL, try to reassociate this 123 with some map of stylesheet locations, manage
all this stuff in a thread-safe and deadlock-free manner and so on. Do you
consider this overhead? I'm not pretty sure what's better.
Yes, I am intending to implement an own AddResource, but first I'd like to
understand what am I missing and what you guys were thinking, your experience is
very valuable. And me, I might be mistaken.
Why not simply pre-render body in a buffer (gathering the
styles/scripts for the header or whatever), and then happily render
the head with all the gathered resources? A combination of
document/head/body components could easily do it. You only need a some
tens of kbs buffer to pre-render the body...
I am not sure, if it is really possible to do this.
Say:
<t:document>
<t:documentHead>
</t:documentHead>
<t:documentBody>
</t:documentBody>
</t:document>
JSF will sequentially render the tags, means, you cant "buffer the body
and then happily render the head" the head has already been rendered
before the body.
Ok, the question is if it is legal to render body into a buffer before the head?
Since <head/> and <body/> will appear in the right order in the resulting
document, who cares in which order they were rendered?
Well, I can surely imagine a situation when this is true - but this is a rather
special behaviour, I think.
You have to buffer in t:document, data will be gathered within
t:documentBody, but you have to add stylesheets and script in
t:documentHead.
This means, you again have to parse the buffer gathered in t:document
and find the <head> stuff.
This solution is nothing better than the DefaultAddResource which will
parse the buffer the same way, or do you have another idea?
My idea was to do the following:
1. In the document renderer, look for documentHead and documentBody children of
the document component.
2. document renderer overtakes rendering of the children.
3. We create a new ResponseWriter which writes into a buffer.
4. document renderer renders document body with the created writer (not the
original one)
5. <html>
6. render documentHead
7. write what was rendered into the buffer.
8. </html>
Do I get it wrong somewhere? You can first render children into a buffer, then
simply use this buffer when you need it, can't you?
Sure, you can buffer the head AND the body, but this will just reduce
the amout of bytes to parse.
What you also can try to do is to discard the first rendering of
documentHead, means:
1) Render Document
2) Render Head (discard output)
3) Render Body in buffer
4) Render Head (not with output)
5) Send body buffer
But see, it will be tricky again, no? ;-) And nobody guarantees you that
all tags within renderHead are able to handle this kind of "double
invocation", though, this shouldn't really be a problem.
I don't get why head should be rendered twice.
Of course the approach has limitations. That is:
1. You have to use t:document/t:documentHead/t:documentBody structure.
Precisely. document must have exactly two children, documentHead and document body.
2. You explicitly allow body to be processed before the head.
That's it. In my opinion, these are no hard limitations. These are no
limitations at all!
As far as I know, weblet only handles the delivery of resources, not the
way how and where to place the link within the page, so in the end, its
not much of help, no?
Yes, Weblets do only resource delivery, but this functionality is implemented
more convenient than MyFaces analogs. I once tried to use MyFaces resource
delivery with an own component... It's not that easy when you're not in the
org.apache.myfaces.custom packages. Have to reimplement *ResourceLoaders and so
on. Not easy. Not component developer friendly.
So I'd like to use good things from both worlds. Weblets for resource delivery.
AddResource to add resources. That's the idea, at least.
Bye.
/lexi
