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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
