myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Vieujot <svieu...@apache.org>
Subject Re: MYFACES-152: ResponseWriter.endDocument() abuse breaks ADF Faces and Facelets
Date Tue, 27 Sep 2005 17:41:20 GMT
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 anyway.

This code to parse the input isn't too hard. Some very good tools like
SiteMesh work like this and are very reliable & fast, so I don't see
that as a problem.
So, in the end, I'm not sure those t:head & t:body tags are really
useful to solve this problem.

On Tue, 2005-09-27 at 17:07 +0200, Martin Marinschek wrote:

> 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 the whole output for these strings
> - there are just too many possibilities. With a clearly defined call
> to startElement, we know the position!
> 
> regards,
> 
> Martin
> 
> On 9/27/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> >  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 rendered out -
> > untouched!
> >
> > As soon as the JSF processing starts, we start caching the response.
> > When the t:body element is closed, we write out the cached data.
> >
> > Our existing filter might work unchanged, if I don't have any problems
> > in my reasoning...
> >
> > Sounds reasonable?
> >
> >
> > On 9/27/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> > > On Tue, 2005-09-27 at 15:55 +0200, Martin Marinschek wrote:
> > > 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.
> > >
> > > Not having a separate filter would be good, but I don't know how this can
> > > be done, as any HTML rendered before the JSF components would be lost.
> > >
> > >
> > > Wait a minute - we could set the insert position by setting request
> > > parameters which the filter reads, right?
> > >
> > > Sure !
> > >
> > >
> > >
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 9/27/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> > > > So, If I understand you well, the t:head for example would render
> > > something
> > > > like :
> > > > <head><!-- Hello, I'm the tomahawk head Start -->
> > > > ...
> > > > <!-- Hello, I'm the tomahawk head End --></head>
> > > >
> > > > And the extensions filter would first search for the "<!-- Hello, I'm
> > the
> > > > tomahawk head Start -->" to get the insert position.
> > > > If he doesn't find it, it would fallback on the current parsing.
> > > >
> > > > Is that it ?
> > > >
> > > >
> > > > On Tue, 2005-09-27 at 15:40 +0200, Martin Marinschek wrote:
> > > > 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 rendering of the javascript for
> > > > commandLinks...
> > > >
> > > > If we don't find a way to fix this problem, we won't be able to use
> > > > the ADF components with MyFaces apps, nor will facelets be properly
> > > > working.
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 9/27/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> > > > > 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 an application is made to work with
the
> > > RI,
> > > > > and then the user switches to MyFaces to use just a few components
he
> > > > needs,
> > > > > he should not have to redesign his pages.
> > > > > Right now, in such a case you just setup the extensions filter, an
add
> > > the
> > > > > MyFaces' tag where you want it.
> > > > > If you also had to redesign your pages to have a t:head & t:body,
it
> > > would
> > > > > be quite a penalty for MyFaces switchers.
> > > > > That's what I meant by "you could not include just a t:component
in a
> > > page
> > > > > that would otherwise for fine with the RI".
> > > > >
> > > > > I was also wondering how this can be done.
> > > > > If you are rendering an inputSuggestAjax for example, you'll need
to
> > > > > include the js in the head.
> > > > > But the t:head should already be rendered.
> > > > > So I don't know how you're going to change a component that's already
> > > > > rendered.
> > > > >
> > > > > I once looked at something similar for the fileUpload, to add
> > > > automatically
> > > > > the proper encrypt method to the form, but I didn't find any good
> > > solution
> > > > > that wouldn't work as the extension filter (i.e. by parsing the
> > > generated
> > > > > HTML).
> > > > >
> > > > > Sylvain.
> > > > >
> > > > >
> > > > > On Tue, 2005-09-27 at 14:53 +0200, Martin Marinschek wrote:
> > > > > 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 here.
> > > > >
> > > > > With using MyFaces, he won't get the functionality if he doesn't
use
> > > > > t:head or t:body. It will still work, he just won't have the extras.
> > > > >
> > > > > regards,
> > > > >
> > > > > Martin
> > > > >
> > > > >
> > > > >
> > > > > On 9/27/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> > > > > > 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
> > > > > > t:component in a page that would otherwise for fine with the
RI.
> > > > > >
> > > > > > Sylvain.
> > > > > >
> > > > > >
> > > > > > On Tue, 2005-09-27 at 12:33 +0200, Martin Marinschek wrote:
> > > > > > 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 component?
> > > > > >
> > > > > > With this approach, we could also support including component
> > > > > > resources in the header much better, as we have a clear marker
for
> > the
> > > > > > major areas of the HTML page...
> > > > > >
> > > > > > regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > http://www.irian.at
> > > > > Your JSF powerhouse -
> > > > > JSF Trainings in English and German
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > > Your JSF powerhouse -
> > > > JSF Trainings in English and German
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > > Your JSF powerhouse -
> > > JSF Trainings in English and German
> > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> > Your JSF powerhouse -
> > JSF Trainings in English and German
> >
> >
> 
> 
> --
> 
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German

Mime
View raw message