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
