Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]
Felix Knecht pisze:
I propose to have a a parameter we can set in the sitemap for readers
indicating that the read resource is deprecated.
This parameter will be read in the o.a.c..r.AbstractReader and log a
warning in case of (is a System.out.println also needed?).
map:match pattern=resource/external/forms/**.js
map:read src=resource://org/apache/cocoon/forms/resources/{1}.js
type=servletLinkRewriter
map:parameter name=deprecated value=true/
/map:match
WDYT?
Hmm, what if deprecated resource is generated by pipeline? I wonder why we
can't use an action.
Deprecation informing is orthogonal to reading deprecated resource so I think we should not mix these things up. Also, notice that in this
specific case servletLinkRewriter reader is used, but in other it may be plain resource reader. Does it make sense to include this
functionality in all possible readers?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]
Felix Knecht pisze:
I propose to have a a parameter we can set in the sitemap for readers
indicating that the read resource is deprecated.
This parameter will be read in the o.a.c..r.AbstractReader and log a
warning in case of (is a System.out.println also needed?).
map:match pattern=resource/external/forms/**.js
map:read src=resource://org/apache/cocoon/forms/resources/{1}.js
type=servletLinkRewriter
map:parameter name=deprecated value=true/
/map:match
Felix, I see that you are going to deprecate HTMLArea right now. Have you seen
Reinhard's response[1], especially this:?
What others think about it? Do we need a vote?
yes please so that the decision gets explicit to everybody who doesn't follow
each mail thread in every detail.
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74250
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]
Felix Knecht wrote:
Take a look at sitemap[1] in cocoon-forms-impl; there is following
I propose to have a a parameter we can set in the sitemap for readers
indicating that the read resource is deprecated.
This parameter will be read in the o.a.c..r.AbstractReader and log a
warning in case of (is a System.out.println also needed?).
map:match pattern=resource/external/forms/**.js
map:read src=resource://org/apache/cocoon/forms/resources/{1}.js
type=servletLinkRewriter
map:parameter name=deprecated value=true/
/map:match
I think this is should not go into the reader. It is not the task of the
reader to inform you about deprecated sources (going down this path
would require to add this logic to generators etc. as well).
I think a separate component is the way to go - and yes, I think this is
an ideal case for the unfamous action component :)
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]
Carsten Ziegeler wrote:
Felix Knecht wrote:
Take a look at sitemap[1] in cocoon-forms-impl; there is following
I propose to have a a parameter we can set in the sitemap for readers
indicating that the read resource is deprecated.
This parameter will be read in the o.a.c..r.AbstractReader and log a
warning in case of (is a System.out.println also needed?).
map:match pattern=resource/external/forms/**.js
map:read src=resource://org/apache/cocoon/forms/resources/{1}.js
type=servletLinkRewriter
map:parameter name=deprecated value=true/
/map:match
I think this is should not go into the reader. It is not the task of the
reader to inform you about deprecated sources (going down this path
would require to add this logic to generators etc. as well).
I think a separate component is the way to go - and yes, I think this is
an ideal case for the unfamous action component :)
Or a new map:log statement we talked about a long time ago, e.g.
map:log level=warn msg={1} is deprecated/
Nothing that can be done with an action though...
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]
Sylvain Wallez wrote:
Or a new map:log statement we talked about a long time ago, e.g.
map:log level=warn msg={1} is deprecated/
Yeah, sounds good as well - this statement has the advantage that it's
always configured and it looks a little bit nicer.
Nothing that can be done with an action though...
^^^
Nice typo :)
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Or a new map:log statement we talked about a long time ago, e.g.
map:log level=warn msg={1} is deprecated/
Yeah, sounds good as well - this statement has the advantage that it's
always configured and it looks a little bit nicer.
Nothing that can be done with an action though...
^^^
Nice typo :)
Ooops, actions are so evil that they induce typos :-P
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]
Felix, I see that you are going to deprecate HTMLArea right now. No. Have you seen Reinhard's response[1], especially this:? Yes. There are also others who think that not even depracation is needed [2]. For now I'm just going to implement a LogAction. [2] http://marc.info/?l=xml-cocoon-devm=118521471104518w=2 Felix What others think about it? Do we need a vote? yes please so that the decision gets explicit to everybody who doesn't follow each mail thread in every detail. [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74250
