You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2007/10/26 10:52:47 UTC
[research] resource dependency framework
Hi!
Sorry for the lenghty mail!! Maybe something for the upcoming MyFaces
Commons project.
To get rid of the AddResource oddities I thought about introducing a new
"resource dependency framework".
1) DefaultAddResource is slow in performance and I don't like it to
buffer the output at all
2) StreamingAddResource is a little bit better, but requires to cache
the styles requested on the server which is somehow tricky
3) DojoAddResource (in the sandbox) is a hack too
Also, solution 2 and 3 lazily request resources, which you might
sometimes see in rendering glitches on the client side, be it that the
page renders choppy due to script loading in the mid of the page, or
that the browser has to load the css and until then the visual
representation is not correct.
The idea is (if running in an environment which allows this (JSF >= 1.2,
facelets) to:
a) scan the JSF tree after it has been created and before it is going to
be rendered
b) collect the required resources during creation of the tree
both ways might require view-framework dependent hooks.
It is a shame that even in JSF 1.2 or Facelets there is no place defined
in the spec where to get access to the view once built but not rendered
yet. Maybe someone can bring this up in JSF 2.0?
Also b might need some investigation if this is somehow pluggable, might
also depend on the used framework.
For this to work I'd like to introduce a new interface called something
like org.apache.myfaces.commons.renderkit.html.HtmlResourceDependencies
with a method like
public ResourceInfo[] getResources(UIComponent component)
where ResourceInfo is something like
ResourceInfo
{
String resource;
ResourcePosition position; (HEADER_BEGIN, BODY_END, not sure about
BODY_ONLOAD)
}
The Renderer has to implement that interface then.
With either a or b the getResources() method will be called and all the
required resources are collected.
Then, with help of our t:document, t:documentHead, t:documentBody (maybe
we need one more) it should be possible to render the resources at the
correct places.
Since all this happens during or after the compile-time of the view -
and depending how your view-framework is configured
(facelets.BUILD_BEFORE_RESTORE=true|false) all this might not work well
if the resources required depends on component value bindings. But
normally I think resources are static things, so it should be possible
to workaround that limitation.
To make resource requesting work even in pure JSF 1.1 environments I'd
enhance our default AddResource with
AddResource.loadResources(HtmlResourceDependencies renderer)
with everything setup correctly this is a noop, else it delegates to 1-3.
What do you think, is it all worth it?
Ciao,
Mario
Re: [research] resource dependency framework
Posted by Matthias Wessendorf <ma...@apache.org>.
JSR 314 says:
First class support for bundling and delivering static resources
associated with a component: images, stylesheets, scripts, etc. Should
be able to specify default locations for resources.
Two options:
-start impl and move to faces² asap
-wait
On 10/26/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> Sorry for the lenghty mail!! Maybe something for the upcoming MyFaces
> Commons project.
>
> To get rid of the AddResource oddities I thought about introducing a new
> "resource dependency framework".
> 1) DefaultAddResource is slow in performance and I don't like it to
> buffer the output at all
> 2) StreamingAddResource is a little bit better, but requires to cache
> the styles requested on the server which is somehow tricky
> 3) DojoAddResource (in the sandbox) is a hack too
>
> Also, solution 2 and 3 lazily request resources, which you might
> sometimes see in rendering glitches on the client side, be it that the
> page renders choppy due to script loading in the mid of the page, or
> that the browser has to load the css and until then the visual
> representation is not correct.
>
>
> The idea is (if running in an environment which allows this (JSF >= 1.2,
> facelets) to:
> a) scan the JSF tree after it has been created and before it is going to
> be rendered
> b) collect the required resources during creation of the tree
>
> both ways might require view-framework dependent hooks.
> It is a shame that even in JSF 1.2 or Facelets there is no place defined
> in the spec where to get access to the view once built but not rendered
> yet. Maybe someone can bring this up in JSF 2.0?
> Also b might need some investigation if this is somehow pluggable, might
> also depend on the used framework.
>
> For this to work I'd like to introduce a new interface called something
> like org.apache.myfaces.commons.renderkit.html.HtmlResourceDependencies
> with a method like
>
> public ResourceInfo[] getResources(UIComponent component)
>
> where ResourceInfo is something like
>
> ResourceInfo
> {
> String resource;
> ResourcePosition position; (HEADER_BEGIN, BODY_END, not sure about
> BODY_ONLOAD)
> }
>
> The Renderer has to implement that interface then.
> With either a or b the getResources() method will be called and all the
> required resources are collected.
> Then, with help of our t:document, t:documentHead, t:documentBody (maybe
> we need one more) it should be possible to render the resources at the
> correct places.
>
> Since all this happens during or after the compile-time of the view -
> and depending how your view-framework is configured
> (facelets.BUILD_BEFORE_RESTORE=true|false) all this might not work well
> if the resources required depends on component value bindings. But
> normally I think resources are static things, so it should be possible
> to workaround that limitation.
>
> To make resource requesting work even in pure JSF 1.1 environments I'd
> enhance our default AddResource with
> AddResource.loadResources(HtmlResourceDependencies renderer)
> with everything setup correctly this is a noop, else it delegates to 1-3.
>
> What do you think, is it all worth it?
> Ciao,
> Mario
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [research] resource dependency framework
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
>> The idea is (if running in an environment which allows this (JSF >=
>> 1.2, facelets) to:
>> a) scan the JSF tree after it has been created and before it is going
>> to be rendered
>> b) collect the required resources during creation of the tree
> Both possibilities are in wrong place - if all resources were to be
> caught, it has to scan tree after all modifications - after
> INVOKE_APPLICATION phase.
Yep, then it might work in an phase listener for the postback, but not
for the initial rendering. Maybe we have to differentiate. But as I
said, I think those resource should be rather static and simply are
configured by the component then.
>> The Renderer has to implement that interface then.
> Implementing interface would break TCK test of JSF spec.
I meant the concrete Renderer e.g. HtmlCalendarRenderer.
> Wouldn't simple splitting output of whole page to 3 (or 4) independend
> chunks do the trick (HTML example):
> 1st for whole head w/o finnishing </head> tag
> 2nd starting with </head> <body> to the inserting spot for styles (not
> sure of this splitting)
> 3rd for whole body w/o ending tag </body>
> 4th ending body + html tags
You still have to buffer the output, no?
I don't like buffering. It slows things down and the very most important
thing for a webapp is to start rendereing so the page transitions on the
client happen soon.
Ciao,
Mario
Re: [research] resource dependency framework
Posted by Matthias Wessendorf <ma...@apache.org>.
> > The Renderer has to implement that interface then.
> Implementing interface would break TCK test of JSF spec.
custom renderer. those aren't "bound" to TCK
-M
> > With either a or b the getResources() method will be called and all
> > the required resources are collected.
> > Then, with help of our t:document, t:documentHead, t:documentBody
> > (maybe we need one more) it should be possible to render the resources
> > at the correct places.
> >
> > Since all this happens during or after the compile-time of the view -
> > and depending how your view-framework is configured
> > (facelets.BUILD_BEFORE_RESTORE=true|false) all this might not work
> > well if the resources required depends on component value bindings.
> > But normally I think resources are static things, so it should be
> > possible to workaround that limitation.
> >
> > To make resource requesting work even in pure JSF 1.1 environments I'd
> > enhance our default AddResource with
> > AddResource.loadResources(HtmlResourceDependencies renderer)
> > with everything setup correctly this is a noop, else it delegates to 1-3.
> >
> Wouldn't simple splitting output of whole page to 3 (or 4) independend
> chunks do the trick (HTML example):
> 1st for whole head w/o finnishing </head> tag
> 2nd starting with </head> <body> to the inserting spot for styles (not
> sure of this splitting)
> 3rd for whole body w/o ending tag </body>
> 4th ending body + html tags
>
> Adding resources was simple appending style's output to relevant chunk then.
> After all resources included and finnishing encoding all components,
> simple combining of all chunks would make a whole page's output.
>
> Best regards,
> Zdenek
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Re: [research] resource dependency framework
Posted by Sochor Zdeněk <zd...@ataco.cz>.
Hi,
quite interesting ideas, but they have few glitches (inside).
Mario Ivankovits napsal(a):
> Hi!
>
> Sorry for the lenghty mail!! Maybe something for the upcoming MyFaces
> Commons project.
>
> To get rid of the AddResource oddities I thought about introducing a
> new "resource dependency framework".
> 1) DefaultAddResource is slow in performance and I don't like it to
> buffer the output at all
> 2) StreamingAddResource is a little bit better, but requires to cache
> the styles requested on the server which is somehow tricky
> 3) DojoAddResource (in the sandbox) is a hack too
>
> Also, solution 2 and 3 lazily request resources, which you might
> sometimes see in rendering glitches on the client side, be it that the
> page renders choppy due to script loading in the mid of the page, or
> that the browser has to load the css and until then the visual
> representation is not correct.
>
>
> The idea is (if running in an environment which allows this (JSF >=
> 1.2, facelets) to:
> a) scan the JSF tree after it has been created and before it is going
> to be rendered
> b) collect the required resources during creation of the tree
Both possibilities are in wrong place - if all resources were to be
caught, it has to scan tree after all modifications - after
INVOKE_APPLICATION phase.
>
> both ways might require view-framework dependent hooks.
> It is a shame that even in JSF 1.2 or Facelets there is no place
> defined in the spec where to get access to the view once built but not
> rendered yet. Maybe someone can bring this up in JSF 2.0?
> Also b might need some investigation if this is somehow pluggable,
> might also depend on the used framework.
>
> For this to work I'd like to introduce a new interface called
> something like
> org.apache.myfaces.commons.renderkit.html.HtmlResourceDependencies
> with a method like
>
> public ResourceInfo[] getResources(UIComponent component)
>
> where ResourceInfo is something like
>
> ResourceInfo
> {
> String resource;
> ResourcePosition position; (HEADER_BEGIN, BODY_END, not sure about
> BODY_ONLOAD)
> }
>
> The Renderer has to implement that interface then.
Implementing interface would break TCK test of JSF spec.
> With either a or b the getResources() method will be called and all
> the required resources are collected.
> Then, with help of our t:document, t:documentHead, t:documentBody
> (maybe we need one more) it should be possible to render the resources
> at the correct places.
>
> Since all this happens during or after the compile-time of the view -
> and depending how your view-framework is configured
> (facelets.BUILD_BEFORE_RESTORE=true|false) all this might not work
> well if the resources required depends on component value bindings.
> But normally I think resources are static things, so it should be
> possible to workaround that limitation.
>
> To make resource requesting work even in pure JSF 1.1 environments I'd
> enhance our default AddResource with
> AddResource.loadResources(HtmlResourceDependencies renderer)
> with everything setup correctly this is a noop, else it delegates to 1-3.
>
Wouldn't simple splitting output of whole page to 3 (or 4) independend
chunks do the trick (HTML example):
1st for whole head w/o finnishing </head> tag
2nd starting with </head> <body> to the inserting spot for styles (not
sure of this splitting)
3rd for whole body w/o ending tag </body>
4th ending body + html tags
Adding resources was simple appending style's output to relevant chunk then.
After all resources included and finnishing encoding all components,
simple combining of all chunks would make a whole page's output.
Best regards,
Zdenek