-- Forwarded message --
From: Thomas Spiegl [EMAIL PROTECTED]
Date: Sep 28, 2005 9:45 AM
Subject: Re: MYFACES-152: ResponseWriter.endDocument() abuse breaks
ADF Faces and Facelets
To: [EMAIL PROTECTED]
int flags = Pattern.CASE_INSENSITIVE | Pattern.DOTALL;
Pattern pattern
Hi *,
There is a long standing bug MYFACES-152
http://issues.apache.org/jira/browse/MYFACES-152
which needs our attention, for facelets and ADF faces compatibility.
What do you say to my suggestion to move writing these scripts to the
encodeEnd Method of a newly created t:head/t:body
+1 It seems a good solution to me, this would increase the flexibility
and would ease the pain when working with the HTML areas not covered
by the jsf components,
Regards,
Bruno
2005/9/27, Martin Marinschek [EMAIL PROTECTED]:
Hi *,
There is a long standing bug MYFACES-152
This would be great. I would prefer that all Javascript related methods
are placed in a .js script file or written in the header. This would
ease many things and we would have a clear code.
On Tue, 27 Sep 2005 12:33:20 +0200, Martin Marinschek
[EMAIL PROTECTED] wrote:
Hi *,
There is a
Hello Martin,
I'm not sure I understand this.
Would you require every page having a t:component to have t:head t:body components as well ?
If this is the case, it would be a lead to a lot ot other problems I think.
For example, it would break old pages. Also, you could not include just a
dev@myfaces.apache.org
Subject
Re: MYFACES-152: ResponseWriter.endDocument()
abuse breaks ADFFaces and Facelets
Hello Martin,
I'm not sure I understand this.
Would you require every page having a t:component to have t:head
t:body components as well ?
If this is the case, it would
I was waiting for your feedback here, Sylvain ;)
I know this is problematic, for the reasons you pointed out. As things
like addResource and the scroll-position javascript are special
MyFaces functionality anyways, the user won't have the special
features anyways with using the RI, so no change
What do you mean by he just won't have the extras ?
I think that if it's fully optional, it sure would bey good.
I mean if the page has t:head t:body, then it uses it, otherwise it works as today.
But if the t:head t:body are mandatory, then this is a problem.
About the RI, I meant that if
Basically, it would work very much like the approach we are using today.
So we would need to do some caching of the response, and parsing in
the statements as we go. We would have defined markers, though, and
wouldn't need to search through the whole markup!
We are doing this today for the
Yes, but ideally we would find a way to integrate it into the
life-cycle - not having a separate filter, with this we could
remember the insert position.
Wait a minute - we could set the insert position by setting request
parameters which the filter reads, right?
regards,
Martin
On 9/27/05,
I think it does.
So, basically, a phase listener would start the filter's job if the filter hasn't been configured. Right ?
I'm not 100% sure how it solves MYFACES-152 though.
On Tue, 2005-09-27 at 16:08 +0200, Martin Marinschek wrote:
Well, any HTML before the JSF components would just be
We could move the script generation from endDocument to encodeEnd in
t:head or t:body - tag...
With that we make sure that no scripts are outputted after the
document has already been closed!
Manfred suggests as a solution to parse the input for head - or body
tags, I don't like having to parse
Indeed, it could be generated them in t:head/body. But then we would have to set a request attribute, and in the filter, fallback on parsing the input if the request attribute hasn't been set.
So, to be compatible with pages without the t:head/body, we would have to do the code in the filter
13 matches
Mail list logo
