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 2006/03/01 20:15:37 UTC
AddResource interface changes
Hi!
Now that I would like to do something with AddResource I though I take
the change to simply its interface.
Currently we have a punch of methods to implement, but only a handful of
them are in use.
Also that we now know that we can add scripts all around in the html
file we can get rid of the most of the positionInfos.
Also the css stuff can ONLY by added to the header. Here I think it
makes no sense to provide a method to add the style at the current
position in html, even if it works, it is not required, is it?
So I think the interface can be something like that:
addStyleSheet(context, uri)
addStyleSheet(context, ResourceHandler)
adds the stylesheet to the header
addInlineStyleSheet(context, uri)
adds the style to the header
addJavaScript(context, uri)
addJavaScript(context, ResourceHandler)
inserts the java script - depending on the used AddResource
implementation to the header (current behaviour) or delegates to
addJavaScriptHere
addJavaScriptHere(context, uri)
inserts the java script - depending on the used AddResource implementation
With the methods above it is not possible to simulate Position.BODY_END,
but no one uses it.
Please let me know if you think its still required to have the above
methods with "Class myfacesCustomComponent" - no one uses it, so why
keep it?
In fact I didnt find a usage of the ResourceHandler, so if you ask me
I'll remove it too.
I hope this is not too radical, its just a question to make my work
simpler ;-)
Ciao,
Mario
Re: AddResource interface changes
Posted by Sean Schofield <se...@gmail.com>.
Yes no problems with discussion now.
On 3/1/06, Martin Marinschek <ma...@gmail.com> wrote:
> I need to tell you again that I really love your suggestion, Mario.
>
> That will help us a lot. sigh of relief.
>
> regards,
>
> Martin
>
> On 3/1/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> > > Please let me know if you think its still required to have the above
> > > methods with "Class myfacesCustomComponent" - no one uses it, so why
> > > keep it?
> > >
> > Unhappily the new project layout eclipse thought is is not used, but
> > indeed it IS used.
> > So my cleanup wont be that drastic as more methods are used than I
> > thought first.
> > Sorry for the noise :-(
> >
> > ---
> > Mario
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: AddResource interface changes
Posted by Martin Marinschek <ma...@gmail.com>.
I need to tell you again that I really love your suggestion, Mario.
That will help us a lot. sigh of relief.
regards,
Martin
On 3/1/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > Please let me know if you think its still required to have the above
> > methods with "Class myfacesCustomComponent" - no one uses it, so why
> > keep it?
> >
> Unhappily the new project layout eclipse thought is is not used, but
> indeed it IS used.
> So my cleanup wont be that drastic as more methods are used than I
> thought first.
> Sorry for the noise :-(
>
> ---
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: AddResource interface changes
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Please let me know if you think its still required to have the above
> methods with "Class myfacesCustomComponent" - no one uses it, so why
> keep it?
>
Unhappily the new project layout eclipse thought is is not used, but
indeed it IS used.
So my cleanup wont be that drastic as more methods are used than I
thought first.
Sorry for the noise :-(
---
Mario
Re: AddResource interface changes
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Simon!
>
> I'm not sure about your proposal to add script links inline. IF there is
> no other reason for the extensions filter to buffer output then I'm in
> favour, ie if you can get your funky CSS-linking proposal to work.
>
:-) For sure, all this requires the CSS thing gets up and running.
> However if the extensions filter *has* to buffer in order to output CSS
> links, then I'm in favour of emitting script links into the head also.
> It's tidier.
>
+1 If we still have the buffer, I wont change anything of the current
behaviour.
> One thing I would like to see changed is the functionality that inserts
> script into the body tag's onload attribute. This can more cleanly be
> done via inline script emitted into the document body that goes
> something like this:
> <script>
> var oldOnload =document.onload;
> document.onload=function() {
> oldOnload();
> // new code goes here
> }
> </script>
>
Yes, I forgot to mention this. Its already on the todo list :-)
Ciao,
Mario
Re: AddResource interface changes
Posted by Mario Ivankovits <im...@apache.org>.
Hi Sean!
> Please no non-essential changes to shared until after we release core.
>
Ok.
I just wanted to start the discussion as I thought it would get rather
controversal.
Before I start refactoring some technical aspects have to be solved. So
its no problem to wait until it getting hot ;-)
---
Mario
Re: AddResource interface changes
Posted by Sean Schofield <se...@gmail.com>.
Please no non-essential changes to shared until after we release core.
I'd rather not make a Shared branch and we're on the verge of a core
releaes. Bug fixes are welcome (the sooner the better.)
We can always branch but I feel like we can resolve the bugs in the
next few days and save the trouble and confusion.
Sean
On 3/1/06, Simon Kitching <sk...@apache.org> wrote:
> On Wed, 2006-03-01 at 20:15 +0100, Mario Ivankovits wrote:
> > Hi!
> >
> > Now that I would like to do something with AddResource I though I take
> > the change to simply its interface.
> > Currently we have a punch of methods to implement, but only a handful of
> > them are in use.
> >
> > Also that we now know that we can add scripts all around in the html
> > file we can get rid of the most of the positionInfos.
>
> I'm not sure about your proposal to add script links inline. IF there is
> no other reason for the extensions filter to buffer output then I'm in
> favour, ie if you can get your funky CSS-linking proposal to work.
>
> However if the extensions filter *has* to buffer in order to output CSS
> links, then I'm in favour of emitting script links into the head also.
> It's tidier.
>
>
> > Also the css stuff can ONLY by added to the header. Here I think it
> > makes no sense to provide a method to add the style at the current
> > position in html, even if it works, it is not required, is it?
>
> +1
>
> > With the methods above it is not possible to simulate Position.BODY_END,
> > but no one uses it.
>
> +1
>
> > Please let me know if you think its still required to have the above
> > methods with "Class myfacesCustomComponent" - no one uses it, so why
> > keep it?
> > In fact I didnt find a usage of the ResourceHandler, so if you ask me
> > I'll remove it too.
>
> I believe the myfacesCustomComponent and ResourceHandler methods are
> intended to allow user code (eg custom subclasses of tomahawk
> components) to be able to use the AddResource/extensionsfilter
> functionality. By default, only classes in packages under
> org.apache.myfaces are permitted to use AddResource.
>
> >
> > I hope this is not too radical, its just a question to make my work
> > simpler ;-)
>
> I agree AddResource could do with some polishing.
>
> One thing I would like to see changed is the functionality that inserts
> script into the body tag's onload attribute. This can more cleanly be
> done via inline script emitted into the document body that goes
> something like this:
> <script>
> var oldOnload =document.onload;
> document.onload=function() {
> oldOnload();
> // new code goes here
> }
> </script>
>
> Cheers,
>
> Simon
>
>
Re: AddResource interface changes
Posted by Simon Kitching <sk...@apache.org>.
On Wed, 2006-03-01 at 20:15 +0100, Mario Ivankovits wrote:
> Hi!
>
> Now that I would like to do something with AddResource I though I take
> the change to simply its interface.
> Currently we have a punch of methods to implement, but only a handful of
> them are in use.
>
> Also that we now know that we can add scripts all around in the html
> file we can get rid of the most of the positionInfos.
I'm not sure about your proposal to add script links inline. IF there is
no other reason for the extensions filter to buffer output then I'm in
favour, ie if you can get your funky CSS-linking proposal to work.
However if the extensions filter *has* to buffer in order to output CSS
links, then I'm in favour of emitting script links into the head also.
It's tidier.
> Also the css stuff can ONLY by added to the header. Here I think it
> makes no sense to provide a method to add the style at the current
> position in html, even if it works, it is not required, is it?
+1
> With the methods above it is not possible to simulate Position.BODY_END,
> but no one uses it.
+1
> Please let me know if you think its still required to have the above
> methods with "Class myfacesCustomComponent" - no one uses it, so why
> keep it?
> In fact I didnt find a usage of the ResourceHandler, so if you ask me
> I'll remove it too.
I believe the myfacesCustomComponent and ResourceHandler methods are
intended to allow user code (eg custom subclasses of tomahawk
components) to be able to use the AddResource/extensionsfilter
functionality. By default, only classes in packages under
org.apache.myfaces are permitted to use AddResource.
>
> I hope this is not too radical, its just a question to make my work
> simpler ;-)
I agree AddResource could do with some polishing.
One thing I would like to see changed is the functionality that inserts
script into the body tag's onload attribute. This can more cleanly be
done via inline script emitted into the document body that goes
something like this:
<script>
var oldOnload =document.onload;
document.onload=function() {
oldOnload();
// new code goes here
}
</script>
Cheers,
Simon