You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Felix Knecht (JIRA)" <ji...@apache.org> on 2007/07/22 17:50:06 UTC
[jira] Closed: (COCOON-2091) Move from HTMLArea to Xinha
[ https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Knecht closed COCOON-2091.
--------------------------------
Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
- Added xinha and needed stylesheets to cocoon-forms-impl
- Added sample to cocoon-forms-sample
The xinha license seems to be still the same license htmlarea used (htmlarea license). As this license has already be used and is also listed in the legal folder I don't see any problems concerning the license.
Feel free to reopen if any error occur.
> Move from HTMLArea to Xinha
> ---------------------------
>
> Key: COCOON-2091
> URL: https://issues.apache.org/jira/browse/COCOON-2091
> Project: Cocoon
> Issue Type: Task
> Components: Blocks: Forms
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Felix Knecht
> Assignee: Felix Knecht
> Fix For: 2.2-dev (Current SVN)
>
>
> The used HTMLArea as webbased editor is no longer actively maintained [1]. We should switch to Xinha [2]. It's an Opensource WYSIWYG HTML editor with a licence [3] based on BSD license.
> Can somebody with more knowledge have a look at the license and agree if it's usable for cocoon?
> [1] http://www.dynarch.com/projects/htmlarea/
> [2] http://xinha.python-hosting.com/
> [3] http://xinha.python-hosting.com/wiki/Licence
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (COCOON-2091) Move from HTMLArea to Xinha
Posted by Felix Knecht <fe...@apache.org>.
Grzegorz Kossakowski schrieb:
> Felix Knecht (JIRA) pisze:
>> [
>> https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Felix Knecht closed COCOON-2091. --------------------------------
>>
>> Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN)
>>
>> - Added xinha and needed stylesheets to cocoon-forms-impl - Added
>> sample to cocoon-forms-sample
>>
>> The xinha license seems to be still the same license htmlarea used
>> (htmlarea license). As this license has already be used and is also
>> listed in the legal folder I don't see any problems concerning the
>> license.
>>
>> Feel free to reopen if any error occur.
>
> I haven't tested your changes but I would like to something more general.
>
> I wonder if you have not hurried up too much with this change. Even
> though Xinha is an obvious replacement for HTMLArea they are _not_ the
> same projects. I think that if someone wants to switch to a new
> project she should give others a few days for comments, raising
> concerns etc. Of course, I think that formal vote would be overkill in
> this case.
>
> It's especially valid in this case because Rice proposed to use Dojo's
> editor as an alternative. I was going to raise the same issue but
> wanted to do some research before so I could add some value to the
> discussion. Unfortunately, I have not had enough time to do it.
>
> Felix, all in all, I'm not against this particular change and speaking
> honestly I _am_ happy that we finally moved to Xinha but I couldn't
> resist commenting general practise.
>
Re: Move from HTMLArea to Xinha
Posted by Felix Knecht <fe...@apache.org>.
I was completely at the wrong corner. I saw a kind of DebugFilter you
can add and thought your talking about this kind of (servlet)-filter :-(
This make things much clearer.
Thanks
> Felix Knecht pisze:
>>> Thanks to servlet-service-fw migration in CForms we can be pretty sure
>>> that files will be accessed through our matcher.
>>
>> I'm not uptodate with the servlet-service-fw. Can you point me to this
>> matcher please?
>
> 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.
>
>> Not sure if this is the case, but when we need to add a specific
>> 'deprecation'-filter to the web.xml we can't garantee this filter is
>> used and therefore we can make sure, that the depraction message is
>> print out somewhere.
>
> I'm not sure what filter you are talking about. Could you explain?
>
> [1]
> http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/COB-INF/sitemap.xmap
>
>
Re: Set depraction for client side javascripts [WAS: Re: Move from
HTMLArea to Xinha]
Posted by 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]
Posted by 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]
Posted by 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]
Posted by 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]
Posted by 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
Posted by 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
Posted by 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]
Posted by 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]
Posted by 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
Set depraction for client side javascripts [WAS: Re: Move from HTMLArea
to Xinha]
Posted by 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: Move from HTMLArea to Xinha
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
>> Thanks to servlet-service-fw migration in CForms we can be pretty sure
>> that files will be accessed through our matcher.
>
> I'm not uptodate with the servlet-service-fw. Can you point me to this
> matcher please?
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.
> Not sure if this is the case, but when we need to add a specific
> 'deprecation'-filter to the web.xml we can't garantee this filter is
> used and therefore we can make sure, that the depraction message is
> print out somewhere.
I'm not sure what filter you are talking about. Could you explain?
[1] http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/resources/COB-INF/sitemap.xmap
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Move from HTMLArea to Xinha
Posted by Felix Knecht <fe...@apache.org>.
>
> Thanks to servlet-service-fw migration in CForms we can be pretty sure
> that files will be accessed through our matcher.
I'm not uptodate with the servlet-service-fw. Can you point me to this
matcher please?
Not sure if this is the case, but when we need to add a specific
'deprecation'-filter to the web.xml we can't garantee this filter is
used and therefore we can make sure, that the depraction message is
print out somewhere.
Felix
Re: Move from HTMLArea to Xinha
Posted by Felix Knecht <fe...@apache.org>.
Reinhard Poetz schrieb:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz pisze:
>>>
>>> Once we had a deprecation logger but I don't think that the
>>> infrastructure for it is still in place.
>>
>> Do you talk about client or server logger?
>
> server logger. IIRC there was a log target named "deprecated". Maybe
> Carsten knows more.
It still exists: org.apache.cocoon.util.Deprecation
>
>> I think that we could create special matcher for HTMLArea resources
>> and put a simple action (DeprecateAction?) that would produce a
>> deprecation warning each time HTMLArea resource is accessed.
>> Thanks to servlet-service-fw migration in CForms we can be pretty
>> sure that files will be accessed through our matcher.
>
I think this is a far better idea than trying to 'implement a special
feature' that the client side executed scripts log some deprecation
messages into the servers log.
Re: Move from HTMLArea to Xinha
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz schrieb:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz pisze:
>>>
>>> Once we had a deprecation logger but I don't think that the
>>> infrastructure for it is still in place.
>>
>> Do you talk about client or server logger?
>
> server logger. IIRC there was a log target named "deprecated". Maybe
> Carsten knows more.
>
It's still there: o.a.c.util.Deprecation.
I think this needs some changes to avoid the dependency to avalon logkit
though.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Move from HTMLArea to Xinha
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz pisze:
>>
>> Once we had a deprecation logger but I don't think that the
>> infrastructure for it is still in place.
>
> Do you talk about client or server logger?
server logger. IIRC there was a log target named "deprecated". Maybe Carsten
knows more.
> I think that we could create special matcher for HTMLArea resources and
> put a simple action (DeprecateAction?) that would produce a deprecation
> warning each time HTMLArea resource is accessed.
> Thanks to servlet-service-fw migration in CForms we can be pretty sure
> that files will be accessed through our matcher.
good idea!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Move from HTMLArea to Xinha
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
>
> Once we had a deprecation logger but I don't think that the
> infrastructure for it is still in place.
Do you talk about client or server logger?
I think that we could create special matcher for HTMLArea resources and put a simple action (DeprecateAction?) that would produce a
deprecation warning each time HTMLArea resource is accessed.
Thanks to servlet-service-fw migration in CForms we can be pretty sure that files will be accessed through our matcher.
WDYT?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Move from HTMLArea to Xinha
Posted by Reinhard Poetz <re...@apache.org>.
Felix Knecht wrote:
>> If you we are already in this area. What about deprecating HTMLArea?
>> The project is not maintained any more so I think it would be very
>> wise to deprecate HTMLArea, especially when we have replacement for
>> it, already.
>>
>> 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.
>> Felix, could you handle deprecation work (it consists mainly of adding
>> entry in changes.xml and comments in code)?
>
> Well, I'll take the chance and try to.
> As all of the scripts are executed on client side (and I don't think
> it's a good idea to have a popup there saying it's depracated) where
> would it be best place except the changes.xml to have a printout that it
> is deprecated?
Once we had a deprecation logger but I don't think that the infrastructure for
it is still in place.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Move from HTMLArea to Xinha
Posted by Felix Knecht <fe...@apache.org>.
>
> If you we are already in this area. What about deprecating HTMLArea?
> The project is not maintained any more so I think it would be very
> wise to deprecate HTMLArea, especially when we have replacement for
> it, already.
>
> What others think about it? Do we need a vote?
>
> Felix, could you handle deprecation work (it consists mainly of adding
> entry in changes.xml and comments in code)?
Well, I'll take the chance and try to.
As all of the scripts are executed on client side (and I don't think
it's a good idea to have a popup there saying it's depracated) where
would it be best place except the changes.xml to have a printout that it
is deprecated?
Re: Move from HTMLArea to Xinha
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
> I corrected the summary and description of the issue.
>
> Do you think it's ok this way?
Yes, Felix, it's now a lot clearer. Thanks!
If you we are already in this area. What about deprecating HTMLArea? The project is not maintained any more so I think it would be very wise
to deprecate HTMLArea, especially when we have replacement for it, already.
What others think about it? Do we need a vote?
Felix, could you handle deprecation work (it consists mainly of adding entry in changes.xml and comments in code)?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Move from HTMLArea to Xinha
Posted by Felix Knecht <fe...@apache.org>.
I corrected the summary and description of the issue.
Do you think it's ok this way?
Re: Move from HTMLArea to Xinha
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
> Reinhard Poetz schrieb:
>> Grzegorz Kossakowski wrote:
>> Was htmlarea removed completly or is it just a styling option whether
>> I want to use Xinha or Htmlarea?
>
> It's just a styling option you have (xinha instead of htmlarea) and no
> real replacement has be done. You can use both at the moment, it depends
> on the styling option you use.
Ok, I'm fine with it. I'll evaluate Dojo's alternative as soon as time permits but if others are willing to do the same, don't back out.
> I agree, 'replacment' was definitely the wrong term. It's an addition
> that you now have the choice which one you want to use.
Then, I think it's better to change issue's summary.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Move from HTMLArea to Xinha
Posted by Felix Knecht <fe...@apache.org>.
> Then I don't see a problem (as long as Xinha resources are not loaded
> from every form ... haven't had time to look into the implementation
> yet).
>
It's more or less exactly the same implementations as for htmlarea.
Please reopen the issue if it's going wrong.
Re: Move from HTMLArea to Xinha
Posted by Reinhard Poetz <re...@apache.org>.
Felix Knecht wrote:
> Reinhard Poetz schrieb:
>> Was htmlarea removed completly or is it just a styling option whether
>> I want to use Xinha or Htmlarea?
>
> It's just a styling option you have (xinha instead of htmlarea) and no
> real replacement has be done. You can use both at the moment, it depends
> on the styling option you use.
> I agree, 'replacment' was definitely the wrong term. It's an addition
> that you now have the choice which one you want to use.
Then I don't see a problem (as long as Xinha resources are not loaded from every
form ... haven't had time to look into the implementation yet).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Move from HTMLArea to Xinha
Posted by Felix Knecht <fe...@apache.org>.
Reinhard Poetz schrieb:
> Grzegorz Kossakowski wrote:
>> Felix Knecht (JIRA) pisze:
>>> [
>>> https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>>> ]
>>>
>>> Felix Knecht closed COCOON-2091. --------------------------------
>>>
>>> Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN)
>>>
>>> - Added xinha and needed stylesheets to cocoon-forms-impl - Added
>>> sample to cocoon-forms-sample
>>>
>>> The xinha license seems to be still the same license htmlarea used
>>> (htmlarea license). As this license has already be used and is also
>>> listed in the legal folder I don't see any problems concerning the
>>> license.
>>>
>>> Feel free to reopen if any error occur.
>>
>> I haven't tested your changes but I would like to something more
>> general.
>>
>> I wonder if you have not hurried up too much with this change. Even
>> though Xinha is an obvious replacement for HTMLArea they are _not_
>> the same projects. I think that if someone wants to switch to a new
>> project she should give others a few days for comments, raising
>> concerns etc. Of course, I think that formal vote would be overkill
>> in this case.
>>
>> It's especially valid in this case because Rice proposed to use
>> Dojo's editor as an alternative. I was going to raise the same issue
>> but wanted to do some research before so I could add some value to
>> the discussion. Unfortunately, I have not had enough time to do it.
>>
>> Felix, all in all, I'm not against this particular change and
>> speaking honestly I _am_ happy that we finally moved to Xinha but I
>> couldn't resist commenting general practise.
>
> Was htmlarea removed completly or is it just a styling option whether
> I want to use Xinha or Htmlarea?
It's just a styling option you have (xinha instead of htmlarea) and no
real replacement has be done. You can use both at the moment, it depends
on the styling option you use.
I agree, 'replacment' was definitely the wrong term. It's an addition
that you now have the choice which one you want to use.
>
> Without having a deprecation period I'm against a complet removal of
> htmlarea as users might have their own configurations (e.g. Daisy Wiki).
>
Move from HTMLArea to Xinha
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Felix Knecht (JIRA) pisze:
>> [
>> https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Felix Knecht closed COCOON-2091. --------------------------------
>>
>> Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN)
>>
>> - Added xinha and needed stylesheets to cocoon-forms-impl - Added
>> sample to cocoon-forms-sample
>>
>> The xinha license seems to be still the same license htmlarea used
>> (htmlarea license). As this license has already be used and is also
>> listed in the legal folder I don't see any problems concerning the
>> license.
>>
>> Feel free to reopen if any error occur.
>
> I haven't tested your changes but I would like to something more general.
>
> I wonder if you have not hurried up too much with this change. Even
> though Xinha is an obvious replacement for HTMLArea they are _not_ the
> same projects. I think that if someone wants to switch to a new project
> she should give others a few days for comments, raising concerns etc. Of
> course, I think that formal vote would be overkill in this case.
>
> It's especially valid in this case because Rice proposed to use Dojo's
> editor as an alternative. I was going to raise the same issue but wanted
> to do some research before so I could add some value to the discussion.
> Unfortunately, I have not had enough time to do it.
>
> Felix, all in all, I'm not against this particular change and speaking
> honestly I _am_ happy that we finally moved to Xinha but I couldn't
> resist commenting general practise.
Was htmlarea removed completly or is it just a styling option whether I want to
use Xinha or Htmlarea?
Without having a deprecation period I'm against a complet removal of htmlarea as
users might have their own configurations (e.g. Daisy Wiki).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [jira] Closed: (COCOON-2091) Move from HTMLArea to Xinha
Posted by Felix Knecht <fe...@apache.org>.
Sorry, I hit the wrong button, so former reply doesn't has any changes :-(
> I haven't tested your changes but I would like to something more general.
>
> I wonder if you have not hurried up too much with this change. Even
> though Xinha is an obvious replacement for HTMLArea they are _not_ the
> same projects. I think that if someone wants to switch to a new
> project she should give others a few days for comments, raising
> concerns etc. Of course, I think that formal vote would be overkill in
> this case.
>
> It's especially valid in this case because Rice proposed to use Dojo's
> editor as an alternative. I was going to raise the same issue but
> wanted to do some research before so I could add some value to the
> discussion. Unfortunately, I have not had enough time to do it.
>
> Felix, all in all, I'm not against this particular change and speaking
> honestly I _am_ happy that we finally moved to Xinha but I couldn't
> resist commenting general practise.
Well, that's what I'm of course lacking as newbie , the general practise.
I just had some time left last weekend and that was the result. It's not
in fact a replacement, you should be able to use it in parallel. Don't
hesitate to open the discussion you had in mind. I can undo my changes
if this hinders a discussion about it.
Anyway I think the discussion should be raised and from my POV it's not
bad to give a user different implementations of editors he can use.
I agree that the title of the issues I raised/fixed/closed may be not
absolutely correct, because I didn't replaced it.
So let's raise the discussion about (another or the) replacement for
HTMLArea.
Felix
Re: [jira] Closed: (COCOON-2091) Move from HTMLArea to Xinha
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Grzegorz Kossakowski wrote:
> Felix Knecht (JIRA) pisze:
>> [
>> https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>>
>> Felix Knecht closed COCOON-2091. --------------------------------
>>
>> Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN)
>>
>> - Added xinha and needed stylesheets to cocoon-forms-impl - Added
>> sample to cocoon-forms-sample
>>
>> The xinha license seems to be still the same license htmlarea used
>> (htmlarea license). As this license has already be used and is also
>> listed in the legal folder I don't see any problems concerning the
>> license.
>>
>> Feel free to reopen if any error occur.
>
> I haven't tested your changes but I would like to something more general.
>
> I wonder if you have not hurried up too much with this change. Even
> though Xinha is an obvious replacement for HTMLArea they are _not_ the
> same projects. I think that if someone wants to switch to a new project
> she should give others a few days for comments, raising concerns etc. Of
> course, I think that formal vote would be overkill in this case.
>
> It's especially valid in this case because Rice proposed to use Dojo's
> editor as an alternative. I was going to raise the same issue but wanted
> to do some research before so I could add some value to the discussion.
> Unfortunately, I have not had enough time to do it.
>
> Felix, all in all, I'm not against this particular change and speaking
> honestly I _am_ happy that we finally moved to Xinha but I couldn't
> resist commenting general practise.
In the past we've used the "code rules" rule. So as long as there isn't
any API change that needs discussion or features being removed without a
deprecation process established I'm fine and happy with what Felix did.
Thanks alot!
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)
iD8DBQFGpPFELNdJvZjjVZARAtEHAJ4h53+WKihyobq2H7e1paO8DPqPmwCdE/6z
rPJi2ibZlx9RbpOw2K/7b1s=
=JuN8
-----END PGP SIGNATURE-----
Re: [jira] Closed: (COCOON-2091) Move from HTMLArea to Xinha
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht (JIRA) pisze:
> [ https://issues.apache.org/jira/browse/COCOON-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Felix Knecht closed COCOON-2091. --------------------------------
>
> Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN)
>
> - Added xinha and needed stylesheets to cocoon-forms-impl - Added sample to cocoon-forms-sample
>
> The xinha license seems to be still the same license htmlarea used (htmlarea license). As this license has already be used and is also
> listed in the legal folder I don't see any problems concerning the license.
>
> Feel free to reopen if any error occur.
I haven't tested your changes but I would like to something more general.
I wonder if you have not hurried up too much with this change. Even though Xinha is an obvious replacement for HTMLArea they are _not_ the
same projects. I think that if someone wants to switch to a new project she should give others a few days for comments, raising concerns
etc. Of course, I think that formal vote would be overkill in this case.
It's especially valid in this case because Rice proposed to use Dojo's editor as an alternative. I was going to raise the same issue but
wanted to do some research before so I could add some value to the discussion. Unfortunately, I have not had enough time to do it.
Felix, all in all, I'm not against this particular change and speaking honestly I _am_ happy that we finally moved to Xinha but I couldn't
resist commenting general practise.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/