[jsr-314-open] [C036-ElInResources] CLOSED:

[Alexander Smirnov]

On 10/08/2009 07:04 AM, Ed Burns wrote:
>>>>>> On Sun, 04 Oct 2009 19:46:28 -0700, Alaxander Smirnov<asmirnov at exadel.com>  said:
>
> AS>  I think processing of EL expressions should  not be part of
> AS>  Resource#getInputStream, at least, not for generic resource.
> AS>  It would be better to move implementation into resource Renderer, and
> AS>  provide some meta-information which should be used for particular
> AS>  resource. That would clear divide responsibility between Resource object
> AS>  that should only load content from library, and Renderer that knows how
> AS>  to send that content to a client.
>
> I understand the seductive pull of the "resource renderer" concept here
> but I must point out that we tried to design the resource handler system
> that way intially and threw it out in favor of our current, more flat,
> approach.  Rather than have per-content-type Renderers, we just went
> with a system that made it easy to decorate the ResourceHandler and
> override createResource() to take action based on the request content
> type.  Because my interest in this issue *right now* is to have
> something put into the ChangeLog that applies to 2.0, I don't want to
> entertain this concept any more on this thread.
Oops, I missed the purpose of 
ResourceHandler#getRendererTypeForResourceName . Sorry about that, I 
kept in mind existing RichFaces resource handling architecture that 
divides resource library access / rendering between two classes, so I 
had no doubt about that method purpose :-)
>
> LB>  ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
I've already voted +1 for ELEvaluatedInCSSOnly.
>
>>>>>> On Fri, 02 Oct 2009 20:44:56 +0000, lincolnbaxter at gmail.com said:
>
> LB>  +1
>
> JD>  +1
>
> JL>  +1
>
> TG>  +1
>
> Since there appears to be support for this option, this is the one I
> will codify in the "proposed change" section of the ChangeLog.  Although
> I like Imre's suggestion of using a CSS at-rule to tell the system to
> scan for EL or not, I think it's overkill considering these files are
> cached by the system anyway.  Threfore, the text in
> Resource.getInputStream() will include
>
> The implementation must ensure that EL expressions that are included in
> CSS resources are evaluated as the stream is being read.  This enables
> CSS resources to refer to other CSS resources in resource libraries, for
> example: @import url(#resource['this:layout.css']}); Users must be aware
> of the implications of caching when including EL expressions in this
> way.
>
> Ed
>
>