Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]

[Felix Knecht <fe...@apache.org>]

> Take a look at sitemap[1] in cocoon-forms-impl; there is following
> snippet:
>
>   <map:match pattern="resource/external/forms/**.js">
>     <map:read
> src="resource://org/apache/cocoon/forms/resources/{1}.js"
> type="servletLinkRewriter"/>
>   </map:match>
>
> It matches all request for js files so in your case you would need to
> create more specific matcher (for paths related to HTMLArea) and you
> are done.

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?

Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]

[Felix Knecht <fe...@otego.com>]

> 
> 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-dev&m=118521471104518&w=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
> 

Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]

[Grzegorz Kossakowski <gk...@apache.org>]

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]

[Grzegorz Kossakowski <gk...@apache.org>]

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]

[Sylvain Wallez <sy...@apache.org>]

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]

[Carsten Ziegeler <cz...@apache.org>]

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
cziegeler@apache.org

Re: Set depraction for client side javascripts

[Carsten Ziegeler <cz...@apache.org>]

Felix Knecht wrote:
>> 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...
>>
>>   
> I'm not quite sure but I think this [1] is the discussion about it.
> Reading across I think at that time the problem was how to debug sitemap
> and/or propagate messages in case of sitemap errors. When I'm right it
> ended up in a deal to use cocoon stack trace [2] only and then see what
> happens.
> 
> They way map:log would be used in this case is IMO different than the
> usecase at that time.
> 
> WDYT about challenge the deal? Do we need nowadays the feature of map:log?
> 
:) I think, map:log and an action are identical in functionality and
identical in the amount of text you have to type to create the log
statement.

So I would say, if someone wants to extend the sitemap, fine...if
someone wants to go the faster way, and add the action, fine as well.
The action has the advantage that it can be/should be easily added to
2.1.x as well.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: Set depraction for client side javascripts

[Felix Knecht <fe...@apache.org>]

> 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...
>
>   
I'm not quite sure but I think this [1] is the discussion about it.
Reading across I think at that time the problem was how to debug sitemap
and/or propagate messages in case of sitemap errors. When I'm right it
ended up in a deal to use cocoon stack trace [2] only and then see what
happens.

They way map:log would be used in this case is IMO different than the
usecase at that time.

WDYT about challenge the deal? Do we need nowadays the feature of map:log?

[1] http://marc.info/?t=107388969000001&r=1&w=2
[2] http://marc.info/?l=xml-cocoon-dev&m=107413092717327&w=2

Felix

Re: Set depraction for client side javascripts [WAS: Re: Move from HTMLArea to Xinha]

[Sylvain Wallez <sy...@apache.org>]

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]

[Carsten Ziegeler <cz...@apache.org>]

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
cziegeler@apache.org