myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: MYFACES-152: ResponseWriter.endDocument() abuse breaks ADF Faces and Facelets
Date Wed, 28 Sep 2005 06:58:05 GMT
Ok, good.

As of today, it is easy to break the ExtensionFilter - I just need to
change from

<head to < head

and it won't work anymore, right?

regards,

Martin

On 9/27/05, Thomas Spiegl <thomas.spiegl@gmail.com> wrote:
> IMHO parsing the markup and inserting the necessary scripts would not have a
> great impact on performance. Doing the search with regular expressions is
> really fast.
>
>
>
> On 9/27/05, Sylvain Vieujot <svieujot@apache.org> wrote:
> > 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
> >
> >
>
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Mime
View raw message