You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Torsten Schlabach <ts...@apache.org> on 2005/03/28 21:20:19 UTC
Taking a fresh view at editors
Hi again,
besides the recent dicussion about a potential CForms editor to edit
arbitraty XML form based (in other words: non-WYSIWYG), I found that
there is a lot going on regarding the old and famous topic of
WYSIWYG-(X)HTML or even XML editors ... A quick summary from my personal
point of view.
1. BXE
There is something called BXE 2.0 (alpha, beta, at least not stable
AFAIK. I am currently looking at it. It nevertheless looks promising. I
had some trouble with their demos because if you just check it down and
start it, they give you four links on the index.html page to four
examples that are broken. The fifth example (which works) isn't there on
the start page. I learned on their user's list today they want to fix
this. (The index.html page, not yet the four broken samples.)
The promise of BXE 2.0 is that you can edit arbitraty XML in WYSIWYG
mode using the same XSLT you will use later for rendering. As I never in
my life saw an editor that lived up to this promise (I have been
researching this a lot in DocBook land) and as I think this is something
like the quadrature of the circle anyway I am natually skeptic. But I am
willing to give them a try. (There was also someone who said: "This will
will still be around in 100 years from now. It lasted less than another
10 years IIRC.) The idea will be to prototype BXE 2.0 as a proof of
concept for a potential plugin architecture for Lenya.
The major downside for me personally is that BXE is Mozilla only. No IE,
no Opera, no Konquerer, no Safari. (Correct me if I am wrong.) For our
practical purposes this is as bad as if it was desktop software. But
we've had that.
Now to the more promising news ...
There was some rumor in Cocoon land that HTMLArea would be discontinued.
The threas is here:
http://marc.theaimsgroup.com/?t=111193756400006&r=1&w=2
This probably proofed wrong. We have had an idea to implement HTMLArea
anyway (see http://wiki.apache.org/lenya/1.4) but to me this still had
the problem that it was IE only again. I get sick and tired of this
browser specific stuff.
On the Cocoon list there was a number of WYSIWYG editors discussed that
might serve as an alternative to HTMLArea. Some were ruled out for
License imcompatibilities, but I think this is a Cocoon problem as they
want to embed it. We can reference it, can't we? If we manage to provide
a stable editor plugin API, we could even try to convince any of these
projects to package their editor as a Lenya plugin which would save us
some work and give us additional exposure as people who come from the
editor might upgrade to the full CMS later.
I have put he links to these editors together with some general remarks
on editors in the Wiki: http://wiki.apache.org/lenya/Editors
Please comment!
Regards,
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Torsten Schlabach wrote:
> 1. BXE
> The promise of BXE 2.0 is that you can edit arbitraty XML in WYSIWYG
> mode using the same XSLT you will use later for rendering. As I never in
> my life saw an editor that lived up to this promise (I have been
> researching this a lot in DocBook land) and as I think this is something
> like the quadrature of the circle anyway I am natually skeptic. But I am
> willing to give them a try. (There was also someone who said: "This will
> will still be around in 100 years from now. It lasted less than another
> 10 years IIRC.) The idea will be to prototype BXE 2.0 as a proof of
> concept for a potential plugin architecture for Lenya.
the old bxe (circa 2002) had the same architecture, as does xopus.
chregu can maybe comment on what has changed compared to those times.
> The major downside for me personally is that BXE is Mozilla only. No IE,
> no Opera, no Konquerer, no Safari. (Correct me if I am wrong.) For our
> practical purposes this is as bad as if it was desktop software. But
> we've had that.
i don't think the situation as described here
http://greg.abstrakt.ch/archives/2004/04/which_wysiwyg_e.html
has changed very much unfortunately.
that said, it may be possible to run bxe inside ie:
http://greg.abstrakt.ch/gallery/lenya/iemoz
as to kupu, the integration could be improved a lot. the most important
enhancement is to support arbitrary xml:
http://issues.apache.org/bugzilla/show_bug.cgi?id=33314
but also
http://issues.apache.org/bugzilla/show_bug.cgi?id=31989
http://issues.apache.org/bugzilla/show_bug.cgi?id=32764
http://issues.apache.org/bugzilla/show_bug.cgi?id=33338
http://issues.apache.org/bugzilla/show_bug.cgi?id=32349
> Now to the more promising news ...
>
> There was some rumor in Cocoon land that HTMLArea would be discontinued.
> The threas is here:
>
> http://marc.theaimsgroup.com/?t=111193756400006&r=1&w=2
also see
http://oscom.org/get-involved/mailing-lists/general/2005-March/thread.html#457
> On the Cocoon list there was a number of WYSIWYG editors discussed that
> might serve as an alternative to HTMLArea. Some were ruled out for
> License imcompatibilities, but I think this is a Cocoon problem as they
> want to embed it. We can reference it, can't we? If we manage to provide
> a stable editor plugin API, we could even try to convince any of these
> projects to package their editor as a Lenya plugin which would save us
> some work and give us additional exposure as people who come from the
> editor might upgrade to the full CMS later.
i am definitely in favour of making it much easier to integrate editors.
at the moment it is just too much work. bxe and kupu are already sharing
some code, so it is not necessary to do certain integration steps twice:
http://issues.apache.org/bugzilla/show_bug.cgi?id=33376
> I have put he links to these editors together with some general remarks
> on editors in the Wiki: http://wiki.apache.org/lenya/Editors
thanks, will take a look
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Christian Stocker <ch...@bitflux.ch>.
On 29.3.2005 0:08 Uhr, Gregor J. Rothfuss wrote:
> Christian Stocker wrote:
>
>>> The promise of BXE 2.0 is that you can edit arbitraty XML in WYSIWYG
>>> mode using the same XSLT you will use later for rendering.
>>
>>
>>
>> Ha, we never promised that ;)
>>
>> See http://wiki.bitfluxeditor.org/BXE_2.0/Introduction for some details
>> and http://wiki.bitfluxeditor.org/BXE_2.0/Getting_Started#The_XSLT_File
>> for some of the xslt limitations.
>>
>> Having said that, if you are aware of the limitations of the BXE XSLT
>> rendering and don't plan to use any XSLT-Processor specific stuff (no
>> idea, what lenya does in that regard) and therefore write your xslt
>> carefully, you can use the same xslt for BXE and your "real"
>> rendering.
>
>
> presumably, BXE 2.0 will have about the same limitations when it comes
> to XSL as XOPUS does:
>
> http://xopus.com/product/specifications.html
>
> these limitations strike me as quite reasonable. maybe that list can
> also serve as a reality check.
yeah, sounds like a reasonable list and it basically applies also to BXE
(not sure, if we already support all that elements under "Supported
Elements", but the usually used ones certainly ,) )
chregu
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Christian Stocker wrote:
>>The promise of BXE 2.0 is that you can edit arbitraty XML in WYSIWYG
>>mode using the same XSLT you will use later for rendering.
>
>
> Ha, we never promised that ;)
>
> See http://wiki.bitfluxeditor.org/BXE_2.0/Introduction for some details
> and http://wiki.bitfluxeditor.org/BXE_2.0/Getting_Started#The_XSLT_File
> for some of the xslt limitations.
>
> Having said that, if you are aware of the limitations of the BXE XSLT
> rendering and don't plan to use any XSLT-Processor specific stuff (no
> idea, what lenya does in that regard) and therefore write your xslt
> carefully, you can use the same xslt for BXE and your "real" rendering.
presumably, BXE 2.0 will have about the same limitations when it comes
to XSL as XOPUS does:
http://xopus.com/product/specifications.html
these limitations strike me as quite reasonable. maybe that list can
also serve as a reality check.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Christian Stocker <ch...@bitflux.ch>.
On 29.3.2005 23:26 Uhr, Torsten Schlabach wrote:
>>> but honestly, I
>>> didn't have to persuade companies with large installations until now.
>
> Try it, then re-think!
>
> But it's not just these poor people who don't own their desktops. It's
> much more than that. From my personal experience, it's a barrier to
I know all those arguments. Still doesn't give me more resources to
actually implement it for IE ;)
Thanks for the input anyways.
chregu
>
> - Occasional users. Some not so IT savvy people are reluctant to install
> a new software on their box. Think of people who don't do website
> editing for a living but maybe people in volunteer organisations who
> want to distribute the maintainance of their website.
> - Ad-Hoc editing. I am using a lot of different machines. At home I got
> used to using my laptop, same if I stay in a hotel room for at least
> some hours. But I often use public or other people's computers if I have
> some time to spare to check mail. And if someone is telling me in an
> email to make a change to the website I love beeing able to do it. That
> way I cannot forget it and the person is impressed how fast I did it.
> - Yes, it's always me bringing this up, but it's still a reality. In
> some countries (not only in Afghanistan, even in India) a lot of people
> don't have personal PCs but go to Internet cafes or have to book their
> seat in advance at the university's PC pool. If you know you have this
> machine for an hour, you're not spending half of it to download and
> install a piece of software.
>
> Actually, look at the popularity and adoption of webmail. And now
> imagine Yahoo mail or Hotmail would only work in a specific browser. Can
> you imagine it would habe hindered their popularity?
>
> Regards,
> Torsten
>
>
> Christian Stocker schrieb:
>
>> Hi
>>
>> On 28.3.2005 21:20 Uhr, Torsten Schlabach wrote:
>>
>>> Hi again,
>>>
>>> besides the recent dicussion about a potential CForms editor to edit
>>> arbitraty XML form based (in other words: non-WYSIWYG), I found that
>>> there is a lot going on regarding the old and famous topic of
>>> WYSIWYG-(X)HTML or even XML editors ... A quick summary from my personal
>>> point of view.
>>>
>>> 1. BXE
>>>
>>> There is something called BXE 2.0 (alpha, beta, at least not stable
>>> AFAIK.
>>
>>
>>
>> Certainly alpha, but all the important new features are basically there.
>> They certainly need more refinement and a lot of bugfixing, but it's a
>> start. And we should get to a beta release in a few weeks.
>>
>> I am currently looking at it. It nevertheless looks promising. I
>>
>>> had some trouble with their demos because if you just check it down and
>>> start it, they give you four links on the index.html page to four
>>> examples that are broken. The fifth example (which works) isn't there on
>>> the start page. I learned on their user's list today they want to fix
>>> this. (The index.html page, not yet the four broken samples.)
>>
>>
>>
>> The index.html is fixed, the non working examples are removed from the
>> branch.
>>
>>> The promise of BXE 2.0 is that you can edit arbitraty XML in WYSIWYG
>>> mode using the same XSLT you will use later for rendering.
>>
>>
>>
>> Ha, we never promised that ;)
>>
>> See http://wiki.bitfluxeditor.org/BXE_2.0/Introduction for some details
>> and http://wiki.bitfluxeditor.org/BXE_2.0/Getting_Started#The_XSLT_File
>> for some of the xslt limitations.
>>
>> Having said that, if you are aware of the limitations of the BXE XSLT
>> rendering and don't plan to use any XSLT-Processor specific stuff (no
>> idea, what lenya does in that regard) and therefore write your xslt
>> carefully, you can use the same xslt for BXE and your "real"
>> rendering.
>>
>> Another problem will be if you aggregate different XML documents and
>> then push them through the xslt-translation (let's say the sitetree part
>> and the actual content of a specific page. Again, I have no idea how
>> Lenya handles that ;)). BXE just takes in one XML document and gives you
>> that (edited) back. You would have to take it apart on the server side
>> again (and in the above example maybe making the sitetree stuff
>> uneditable, which is possible with BXE 2.0)
>>
>>
>>> As I never in
>>> my life saw an editor that lived up to this promise (I have been
>>> researching this a lot in DocBook land) and as I think this is something
>>> like the quadrature of the circle anyway I am natually skeptic. But I am
>>> willing to give them a try. (There was also someone who said: "This will
>>> will still be around in 100 years from now. It lasted less than another
>>> 10 years IIRC.) The idea will be to prototype BXE 2.0 as a proof of
>>> concept for a potential plugin architecture for Lenya.
>>
>>
>>
>> If we on the BXE side can help you with anything in making that plugin
>> architecture more easily for lenya, then we're glad to help you.
>>
>>
>>> The major downside for me personally is that BXE is Mozilla only. No IE,
>>> no Opera, no Konquerer, no Safari. (Correct me if I am wrong.) For our
>>> practical purposes this is as bad as if it was desktop software. But
>>> we've had that.
>>
>>
>>
>> I wouldn't say it's as bad as desktop software ;) Most people I have to
>> deal with don't have a problem with installing firefox (but honestly, I
>> didn't have to persuade companies with large installations until now.
>> Universities don't count ;) ) And firefox is at least available for all
>> major OS.
>>
>> The Gecko-in-IE solution should be further looked at maybe, but it's
>> certainly also not the solution for large companies ;)
>>
>> IE support would still be doable, from a technical point of view AFAICS,
>> but it would be a big task and we just don't have the resources for
>> doing that.
>>
>> And concerning the other browsers. AFAIK they don't have the necessary
>> architecture for doing *any* wysiwyg editing. But maybe I'm wrong and I
>> heard that the upcoming Safari will have XSLT and Page-Editing support.
>>
>> chregu
>>
>>
>>
>>> Now to the more promising news ...
>>>
>>> There was some rumor in Cocoon land that HTMLArea would be discontinued.
>>> The threas is here:
>>>
>>> http://marc.theaimsgroup.com/?t=111193756400006&r=1&w=2
>>>
>>> This probably proofed wrong. We have had an idea to implement HTMLArea
>>> anyway (see http://wiki.apache.org/lenya/1.4) but to me this still had
>>> the problem that it was IE only again. I get sick and tired of this
>>> browser specific stuff.
>>>
>>> On the Cocoon list there was a number of WYSIWYG editors discussed that
>>> might serve as an alternative to HTMLArea. Some were ruled out for
>>> License imcompatibilities, but I think this is a Cocoon problem as they
>>> want to embed it. We can reference it, can't we? If we manage to provide
>>> a stable editor plugin API, we could even try to convince any of these
>>> projects to package their editor as a Lenya plugin which would save us
>>> some work and give us additional exposure as people who come from the
>>> editor might upgrade to the full CMS later.
>>>
>>> I have put he links to these editors together with some general remarks
>>> on editors in the Wiki: http://wiki.apache.org/lenya/Editors
>>>
>>> Please comment!
>>>
>>> Regards,
>>> Torsten
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>>> For additional commands, e-mail: dev-help@lenya.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Torsten Schlabach wrote:
> - Yes, it's always me bringing this up, but it's still a reality. In
> some countries (not only in Afghanistan, even in India) a lot of people
> don't have personal PCs but go to Internet cafes or have to book their
> seat in advance at the university's PC pool. If you know you have this
> machine for an hour, you're not spending half of it to download and
> install a piece of software.
>
> Actually, look at the popularity and adoption of webmail. And now
> imagine Yahoo mail or Hotmail would only work in a specific browser. Can
> you imagine it would habe hindered their popularity?
i understand your concerns, but supporting ie and firefox in BXE is a
lot of work. until someone is prepared to fund this, it will likely not
happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Torsten Schlabach <ts...@apache.org>.
>> but honestly, I
>> didn't have to persuade companies with large installations until now.
Try it, then re-think!
But it's not just these poor people who don't own their desktops. It's
much more than that. From my personal experience, it's a barrier to
- Occasional users. Some not so IT savvy people are reluctant to install
a new software on their box. Think of people who don't do website
editing for a living but maybe people in volunteer organisations who
want to distribute the maintainance of their website.
- Ad-Hoc editing. I am using a lot of different machines. At home I got
used to using my laptop, same if I stay in a hotel room for at least
some hours. But I often use public or other people's computers if I have
some time to spare to check mail. And if someone is telling me in an
email to make a change to the website I love beeing able to do it. That
way I cannot forget it and the person is impressed how fast I did it.
- Yes, it's always me bringing this up, but it's still a reality. In
some countries (not only in Afghanistan, even in India) a lot of people
don't have personal PCs but go to Internet cafes or have to book their
seat in advance at the university's PC pool. If you know you have this
machine for an hour, you're not spending half of it to download and
install a piece of software.
Actually, look at the popularity and adoption of webmail. And now
imagine Yahoo mail or Hotmail would only work in a specific browser. Can
you imagine it would habe hindered their popularity?
Regards,
Torsten
Christian Stocker schrieb:
> Hi
>
> On 28.3.2005 21:20 Uhr, Torsten Schlabach wrote:
>
>>Hi again,
>>
>>besides the recent dicussion about a potential CForms editor to edit
>>arbitraty XML form based (in other words: non-WYSIWYG), I found that
>>there is a lot going on regarding the old and famous topic of
>>WYSIWYG-(X)HTML or even XML editors ... A quick summary from my personal
>>point of view.
>>
>>1. BXE
>>
>>There is something called BXE 2.0 (alpha, beta, at least not stable
>>AFAIK.
>
>
> Certainly alpha, but all the important new features are basically there.
> They certainly need more refinement and a lot of bugfixing, but it's a
> start. And we should get to a beta release in a few weeks.
>
> I am currently looking at it. It nevertheless looks promising. I
>
>>had some trouble with their demos because if you just check it down and
>>start it, they give you four links on the index.html page to four
>>examples that are broken. The fifth example (which works) isn't there on
>> the start page. I learned on their user's list today they want to fix
>>this. (The index.html page, not yet the four broken samples.)
>
>
> The index.html is fixed, the non working examples are removed from the
> branch.
>
>>The promise of BXE 2.0 is that you can edit arbitraty XML in WYSIWYG
>>mode using the same XSLT you will use later for rendering.
>
>
> Ha, we never promised that ;)
>
> See http://wiki.bitfluxeditor.org/BXE_2.0/Introduction for some details
> and http://wiki.bitfluxeditor.org/BXE_2.0/Getting_Started#The_XSLT_File
> for some of the xslt limitations.
>
> Having said that, if you are aware of the limitations of the BXE XSLT
> rendering and don't plan to use any XSLT-Processor specific stuff (no
> idea, what lenya does in that regard) and therefore write your xslt
> carefully, you can use the same xslt for BXE and your "real" rendering.
>
> Another problem will be if you aggregate different XML documents and
> then push them through the xslt-translation (let's say the sitetree part
> and the actual content of a specific page. Again, I have no idea how
> Lenya handles that ;)). BXE just takes in one XML document and gives you
> that (edited) back. You would have to take it apart on the server side
> again (and in the above example maybe making the sitetree stuff
> uneditable, which is possible with BXE 2.0)
>
>
>>As I never in
>>my life saw an editor that lived up to this promise (I have been
>>researching this a lot in DocBook land) and as I think this is something
>>like the quadrature of the circle anyway I am natually skeptic. But I am
>>willing to give them a try. (There was also someone who said: "This will
>>will still be around in 100 years from now. It lasted less than another
>>10 years IIRC.) The idea will be to prototype BXE 2.0 as a proof of
>>concept for a potential plugin architecture for Lenya.
>
>
> If we on the BXE side can help you with anything in making that plugin
> architecture more easily for lenya, then we're glad to help you.
>
>
>>The major downside for me personally is that BXE is Mozilla only. No IE,
>>no Opera, no Konquerer, no Safari. (Correct me if I am wrong.) For our
>>practical purposes this is as bad as if it was desktop software. But
>>we've had that.
>
>
> I wouldn't say it's as bad as desktop software ;) Most people I have to
> deal with don't have a problem with installing firefox (but honestly, I
> didn't have to persuade companies with large installations until now.
> Universities don't count ;) ) And firefox is at least available for all
> major OS.
>
> The Gecko-in-IE solution should be further looked at maybe, but it's
> certainly also not the solution for large companies ;)
>
> IE support would still be doable, from a technical point of view AFAICS,
> but it would be a big task and we just don't have the resources for
> doing that.
>
> And concerning the other browsers. AFAIK they don't have the necessary
> architecture for doing *any* wysiwyg editing. But maybe I'm wrong and I
> heard that the upcoming Safari will have XSLT and Page-Editing support.
>
> chregu
>
>
>
>>Now to the more promising news ...
>>
>>There was some rumor in Cocoon land that HTMLArea would be discontinued.
>>The threas is here:
>>
>>http://marc.theaimsgroup.com/?t=111193756400006&r=1&w=2
>>
>>This probably proofed wrong. We have had an idea to implement HTMLArea
>>anyway (see http://wiki.apache.org/lenya/1.4) but to me this still had
>>the problem that it was IE only again. I get sick and tired of this
>>browser specific stuff.
>>
>>On the Cocoon list there was a number of WYSIWYG editors discussed that
>>might serve as an alternative to HTMLArea. Some were ruled out for
>>License imcompatibilities, but I think this is a Cocoon problem as they
>>want to embed it. We can reference it, can't we? If we manage to provide
>>a stable editor plugin API, we could even try to convince any of these
>>projects to package their editor as a Lenya plugin which would save us
>>some work and give us additional exposure as people who come from the
>>editor might upgrade to the full CMS later.
>>
>>I have put he links to these editors together with some general remarks
>>on editors in the Wiki: http://wiki.apache.org/lenya/Editors
>>
>>Please comment!
>>
>>Regards,
>>Torsten
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Christian Stocker <ch...@bitflux.ch>.
Hi
On 28.3.2005 21:20 Uhr, Torsten Schlabach wrote:
> Hi again,
>
> besides the recent dicussion about a potential CForms editor to edit
> arbitraty XML form based (in other words: non-WYSIWYG), I found that
> there is a lot going on regarding the old and famous topic of
> WYSIWYG-(X)HTML or even XML editors ... A quick summary from my personal
> point of view.
>
> 1. BXE
>
> There is something called BXE 2.0 (alpha, beta, at least not stable
> AFAIK.
Certainly alpha, but all the important new features are basically there.
They certainly need more refinement and a lot of bugfixing, but it's a
start. And we should get to a beta release in a few weeks.
I am currently looking at it. It nevertheless looks promising. I
> had some trouble with their demos because if you just check it down and
> start it, they give you four links on the index.html page to four
> examples that are broken. The fifth example (which works) isn't there on
> the start page. I learned on their user's list today they want to fix
> this. (The index.html page, not yet the four broken samples.)
The index.html is fixed, the non working examples are removed from the
branch.
>
> The promise of BXE 2.0 is that you can edit arbitraty XML in WYSIWYG
> mode using the same XSLT you will use later for rendering.
Ha, we never promised that ;)
See http://wiki.bitfluxeditor.org/BXE_2.0/Introduction for some details
and http://wiki.bitfluxeditor.org/BXE_2.0/Getting_Started#The_XSLT_File
for some of the xslt limitations.
Having said that, if you are aware of the limitations of the BXE XSLT
rendering and don't plan to use any XSLT-Processor specific stuff (no
idea, what lenya does in that regard) and therefore write your xslt
carefully, you can use the same xslt for BXE and your "real" rendering.
Another problem will be if you aggregate different XML documents and
then push them through the xslt-translation (let's say the sitetree part
and the actual content of a specific page. Again, I have no idea how
Lenya handles that ;)). BXE just takes in one XML document and gives you
that (edited) back. You would have to take it apart on the server side
again (and in the above example maybe making the sitetree stuff
uneditable, which is possible with BXE 2.0)
> As I never in
> my life saw an editor that lived up to this promise (I have been
> researching this a lot in DocBook land) and as I think this is something
> like the quadrature of the circle anyway I am natually skeptic. But I am
> willing to give them a try. (There was also someone who said: "This will
> will still be around in 100 years from now. It lasted less than another
> 10 years IIRC.) The idea will be to prototype BXE 2.0 as a proof of
> concept for a potential plugin architecture for Lenya.
If we on the BXE side can help you with anything in making that plugin
architecture more easily for lenya, then we're glad to help you.
> The major downside for me personally is that BXE is Mozilla only. No IE,
> no Opera, no Konquerer, no Safari. (Correct me if I am wrong.) For our
> practical purposes this is as bad as if it was desktop software. But
> we've had that.
I wouldn't say it's as bad as desktop software ;) Most people I have to
deal with don't have a problem with installing firefox (but honestly, I
didn't have to persuade companies with large installations until now.
Universities don't count ;) ) And firefox is at least available for all
major OS.
The Gecko-in-IE solution should be further looked at maybe, but it's
certainly also not the solution for large companies ;)
IE support would still be doable, from a technical point of view AFAICS,
but it would be a big task and we just don't have the resources for
doing that.
And concerning the other browsers. AFAIK they don't have the necessary
architecture for doing *any* wysiwyg editing. But maybe I'm wrong and I
heard that the upcoming Safari will have XSLT and Page-Editing support.
chregu
>
> Now to the more promising news ...
>
> There was some rumor in Cocoon land that HTMLArea would be discontinued.
> The threas is here:
>
> http://marc.theaimsgroup.com/?t=111193756400006&r=1&w=2
>
> This probably proofed wrong. We have had an idea to implement HTMLArea
> anyway (see http://wiki.apache.org/lenya/1.4) but to me this still had
> the problem that it was IE only again. I get sick and tired of this
> browser specific stuff.
>
> On the Cocoon list there was a number of WYSIWYG editors discussed that
> might serve as an alternative to HTMLArea. Some were ruled out for
> License imcompatibilities, but I think this is a Cocoon problem as they
> want to embed it. We can reference it, can't we? If we manage to provide
> a stable editor plugin API, we could even try to convince any of these
> projects to package their editor as a Lenya plugin which would save us
> some work and give us additional exposure as people who come from the
> editor might upgrade to the full CMS later.
>
> I have put he links to these editors together with some general remarks
> on editors in the Wiki: http://wiki.apache.org/lenya/Editors
>
> Please comment!
>
> Regards,
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71
http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Michael Wechner <mi...@wyona.com>.
Torsten Schlabach wrote:
> >> What we really need to consider are desktop based editors, as for
> >> instance OpenOffice.org but also M$ Word
>
> Agree. What are you thinking of? Upload / dowload? Or rather the other
> way round: Download a source file through a usecase, edit it and
> upload the edited file again? I think this can't be it, right? (It
> would be easy to implement though.)
well, one of the major problems is the gap between the Browser and the
Desktop, meaning that one needs to switch between Browser and Desktop
Editor.
In the case of Mozilla one solution would be having the Lenya bar as XUL
application
(XPI), whereas actually the menubar itself would still be delivered from
the server.
The menubar would be activated by introspection. Since the Lenya menubar
would be an XPI one could configure within the XPI where the actual
Desktop editor is located and it could be started automagically.
Actually all of this has nothing to do in particular with Lenya and could
be done for any other CMS, but I will refer to Lenya here anyway
Basically it works as follows:
0) Assume one has installed the "Lenya XPI" within Mozilla/Firefox, whereas
installing an XPI is really very simple (basically one or two clicks and
that's it)
1) Browse to your favorite site/page
2) If this page is for instance Lenya powered, then it would include a
introspection
link within its header, e.g. <html><head><link href="introspection.xml" ...
3) Because of the introspection link the "Lenya XPI" is being activated,
whereas
the introspection.xml would be loaded and interpreted, e.g. "login here
in order to edit this page"
4) After login a XUL specific menu could be loaded, which for instance
contain a menu item saying "edit this page with OpenOffice.org or
Dreamweaver or whatever Desktop editor".
5) After clicking "edit with ..." the XML would be downloaded and passed
to the appropriate editor (this should be possible because the Lenya XPI
*should* have the rights to do this)
6) And then the problem starts .... How does the document get back in a
seamless manner!? I don't know! OpenOffice.org could be patched in order
to "save" it back
into the "Lenya XPI", but what about Word or Dreamweaver?....
>
> Also it's probably not realistic to embark on a Java Web Start like
> approach where you launch the desktop editor app from the browser and
> feed the document in.
>
> How about WebDAV? Wouldn't this be a quite elegant solution. If I get
> Redmond's strategy right than they think that you should be able to
> open a URL as if it was a file anyway and I think saving to WebDAV
> would also be a good concept for them.
>
> WDYT?
I don't think that WebDAV as it exists today is sufficient. At least
notification
would be necessary in order to communicate that something might not
worked out
as expected. But maybe I just don't have enough knowledge of WebDAV...
>
> Well, to some extend I can answer this question myself:
>
> http://lenya.apache.org/1_2_x/components/authoring/openoffice.html
>
> (Is this document new or have I just overlooked it so far?)
>
> What I am not so sure about is if "typical" desktop application such
> as Word, OpenOffice, DreamWeaver, etc. can or should be treated the
> same way as XUL / XAML apps. My initial feeling about this would be:
> No, there is a huge difference.
Word will be in XAML for sure some day and M$ will be able to integrate
their
stuff into the desktop even better. With the age of mobile computing and
being able to access the net from basically everywhere desktop
integration will be the key.
>
> Also in any discussion about editors we need to be clear on the goal!
> Is the goal for a Word integration to be able to make existing Word
> documents and display them in a site; probably keeping the original
> formatting that the document author has applied as much as XHTML
> permitts or would be try to (ab)use Word / OpenOffice as an X(HT)ML
> editor?
why not?
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Christian Egli <ch...@wyona.net>.
Hi Thorsten
Torsten Schlabach <ts...@apache.org> writes:
> >> What we really need to consider are desktop based editors, as for
> >> instance OpenOffice.org but also M$ Word
>
> Well, to some extend I can answer this question myself:
>
> http://lenya.apache.org/1_2_x/components/authoring/openoffice.html
>
> (Is this document new or have I just overlooked it so far?)
This document is way old and probably quite out of date. I would also
say that the ideas it describes have been interesting at the time but
now I would not follow that route anymore. I say this for the
following reasons:
* No WYSIWYG (the document will not look the same in OO.o as on the
website)
* No validation (OO.o will produce some xml, but this will most likely
not match the xml you want.)
The user will have a nice and working editor (OO.o) alright, but the
documents do not show up the same as they did in her editor. This is
not a recipe for happy users.
--
Christian Egli christian.egli@wyona.net +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Torsten Schlabach <ts...@apache.org>.
Michael Wechner wrote:
> But anyway, if we just think how long (how many years) it took us to
> build certain things within Lenya and Cocoon and other projects and if
> we don't do the planning now re the possibilities of XAML (and XUL) or
> related technologies, but rather just wait,
> then it will be too late for sure.
>
> I am not saying that XAML is the solution (XUL was first anyway ;-),
> but the current solutions just don't allow what actually should be
> possible and what I would call "seamless content management".
>
> It seems to me that we are trying to do the best out of the current
> situation, but at some point we need to make major step and leave the
> boundaries in order to create new ones ;-) but I think it's important
> to realize that this softare world is created by ourselves and we
> should shape it as we want it and it shouldn't shape ourselves.
I fully agree! One should not be too tactical. This has killed many
projects / products / companies. And it has often hit them hard and
very sudden because sticking to the well established works well for a
long time, but leads to a sudden death.
I found the difficulty often is to find out how to distribute the
limited energy available between
- what our customers (let's view Lenya users as that) need today to get
their job for their customers done (we still have TODOs in that area)
one one site and
- prototyping the future on the other.
If a project had unlimited resources, this is not really be an issue.
(You'll face other issues then, though.) But I wouldn't say we have
unlimited development resources in Lenya as of today.
Of course, making sure a project does not only deliver a good piece of
software that works well for the users but is at the same time
prototyping hot future topics (web desktop integration) might draw
attention and additional resources to the project though! And sometimes
even pure users choose a solution based on it's future proofnes.
Regards,
Torsten
Michael Wechner schrieb:
> Gregor J. Rothfuss wrote:
>
>>>
>>>
>>> What I am not so sure about is if "typical" desktop application such
>>> as Word, OpenOffice, DreamWeaver, etc. can or should be treated the
>>> same way as XUL / XAML apps. My initial feeling about this would be:
>>> No, there is a huge difference.
>>
>>
>>
>> i frankly don't understand where this fascination with vapourware
>> (XAML) comes from. it won't be relevant for years.
>>
>
> well, I don't think it's vapourware and it will be here sooner than I guess
> we could imagine.
>
> But anyway, if we just think how long (how many years) it took us to
> build certain
> things within Lenya and Cocoon and other projects and if we don't do the
> planning now
> re the possibilities of XAML (and XUL) or related technologies, but
> rather just wait,
> then it will be too late for sure.
>
> I am not saying that XAML is the solution (XUL was first anyway ;-), but
> the current solutions just don't allow what actually should be possible
> and what I would call "seamless content management".
>
> It seems to me that we are trying to do the best out of the current
> situation, but
> at some point we need to make major step and leave the boundaries in
> order to create new ones ;-) but I think it's important to realize that
> this softare world is created by ourselves and we should shape it as we
> want it and it shouldn't shape ourselves.
>
> It also seems to me that the software world tends to make the same
> mistake as for instance in physics where successfull models created by
> human beings are often interpreted as reality, whereas a model is a
> model and not the reality. And
> of course every physicist would like to find *the" model, but what if
> such a model
> doesn't exist in the first place because the laws of nature are also
> changing resp.
> other universes died because there laws didn't make much sense ;-)
>
> Michi
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
>>
>>
>> What I am not so sure about is if "typical" desktop application such
>> as Word, OpenOffice, DreamWeaver, etc. can or should be treated the
>> same way as XUL / XAML apps. My initial feeling about this would be:
>> No, there is a huge difference.
>
>
> i frankly don't understand where this fascination with vapourware
> (XAML) comes from. it won't be relevant for years.
>
well, I don't think it's vapourware and it will be here sooner than I guess
we could imagine.
But anyway, if we just think how long (how many years) it took us to
build certain
things within Lenya and Cocoon and other projects and if we don't do the
planning now
re the possibilities of XAML (and XUL) or related technologies, but
rather just wait,
then it will be too late for sure.
I am not saying that XAML is the solution (XUL was first anyway ;-), but
the current solutions just don't allow what actually should be possible
and what I would call "seamless content management".
It seems to me that we are trying to do the best out of the current
situation, but
at some point we need to make major step and leave the boundaries in
order to create new ones ;-) but I think it's important to realize that
this softare world is created by ourselves and we should shape it as we
want it and it shouldn't shape ourselves.
It also seems to me that the software world tends to make the same
mistake as for instance in physics where successfull models created by
human beings are often interpreted as reality, whereas a model is a
model and not the reality. And
of course every physicist would like to find *the" model, but what if
such a model
doesn't exist in the first place because the laws of nature are also
changing resp.
other universes died because there laws didn't make much sense ;-)
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Torsten Schlabach wrote:
> >> What we really need to consider are desktop based editors, as for
> >> instance OpenOffice.org but also M$ Word
>
> Agree. What are you thinking of? Upload / dowload? Or rather the other
> way round: Download a source file through a usecase, edit it and upload
> the edited file again? I think this can't be it, right? (It would be
> easy to implement though.)
not so easy actually. it needs to accomodate workflow and rc as well..
which, come to think about it, is now probably easier than it used to be.
> Also it's probably not realistic to embark on a Java Web Start like
> approach where you launch the desktop editor app from the browser and
> feed the document in.
infrae did this: http://www.zope.org/Members/infrae/DocmaServer
> How about WebDAV? Wouldn't this be a quite elegant solution. If I get
> Redmond's strategy right than they think that you should be able to open
> a URL as if it was a file anyway and I think saving to WebDAV would also
> be a good concept for them.
can already be done from office, although the abstraction leaks a bit,
but it works reasonably well. same for open office iirc.
> Well, to some extend I can answer this question myself:
>
> http://lenya.apache.org/1_2_x/components/authoring/openoffice.html
>
> (Is this document new or have I just overlooked it so far?)
>
> What I am not so sure about is if "typical" desktop application such as
> Word, OpenOffice, DreamWeaver, etc. can or should be treated the same
> way as XUL / XAML apps. My initial feeling about this would be: No,
> there is a huge difference.
i frankly don't understand where this fascination with vapourware (XAML)
comes from. it won't be relevant for years.
> Also in any discussion about editors we need to be clear on the goal! Is
> the goal for a Word integration to be able to make existing Word
> documents and display them in a site; probably keeping the original
> formatting that the document author has applied as much as XHTML
> permitts or would be try to (ab)use Word / OpenOffice as an X(HT)ML editor?
both. especially for larger documents (think DMS) the in browser editors
do not work so well.
i did play around with wordml2xhtml a while ago:
http://svn.apache.org/viewcvs.cgi/lenya/branches/BRANCH_1_2_X/src/webapp/lenya/import.xmap?rev=65627&view=markup
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Torsten Schlabach <ts...@apache.org>.
>> What we really need to consider are desktop based editors, as for
>> instance OpenOffice.org but also M$ Word
Agree. What are you thinking of? Upload / dowload? Or rather the other
way round: Download a source file through a usecase, edit it and upload
the edited file again? I think this can't be it, right? (It would be
easy to implement though.)
Also it's probably not realistic to embark on a Java Web Start like
approach where you launch the desktop editor app from the browser and
feed the document in.
How about WebDAV? Wouldn't this be a quite elegant solution. If I get
Redmond's strategy right than they think that you should be able to open
a URL as if it was a file anyway and I think saving to WebDAV would also
be a good concept for them.
WDYT?
Well, to some extend I can answer this question myself:
http://lenya.apache.org/1_2_x/components/authoring/openoffice.html
(Is this document new or have I just overlooked it so far?)
What I am not so sure about is if "typical" desktop application such as
Word, OpenOffice, DreamWeaver, etc. can or should be treated the same
way as XUL / XAML apps. My initial feeling about this would be: No,
there is a huge difference.
Also in any discussion about editors we need to be clear on the goal! Is
the goal for a Word integration to be able to make existing Word
documents and display them in a site; probably keeping the original
formatting that the document author has applied as much as XHTML
permitts or would be try to (ab)use Word / OpenOffice as an X(HT)ML editor?
I think there are very different usecases. (In the original sense of the
word where "usecase" means "this is a case where a user uses the system
to solve a problem".) What I'd tell people is: If you have 500 legacy
but well formatted documents in word (think of stock analysts reports
for example), you want to bring them online, the uses will expect the
same format as they are used to from Word / printed formatting anyway,
then stuff your Word documents into a directory and have Lenya render them.
If you are inventing writing the documents now at the same time you
start building the site, then get a clean XML structure for your data
(if possible based upon a DTD / Schema standardized in your industry),
edit in XML using an appropriate XML editor and render to your taste for
different channels.
Both use cases would probably require entirely different ways of
handling them effectively.
Another way of playing the Word game that comes to mind and would make a
lot of sense in large organisations would be to implement website
editing based on forms rendered as tables in word documents. A lot of
large organisations love this. They usually have a Word template which
you can use to request anything from a phone to web access up to a new
company car. So why not for website changes. We could then automatically
pick up these word documents from an email queue, extract the
requested changes to the website and apply them.
Sometimes you got to be visionary ... But somehow we've hat that. I
remember the time what I did not have Internet access but I only had
CompuServe. In these days there were email to ftp gateways. You could
use the (non-SMTP) CompuServe mail system to send a mail through the
Internet mail gateway (that one existed - other than the PPP gateway)
with instructions to list the directory content of an FTP server.
Five minutes later you got the listing back and you sent another mail
with instructions, what file you want and in what chunks. They finally
arrived in your mailbox UUencoded. All you had to do was to extract the
ASCII from the WinCIM (they did not have a safe function), put the
pieces together, UUdecode and ... there was you tar/zip file! The only
thing that I did't like at that time was that they charged you by the
size of the email you sent and received through the Internet mail gateway.
Ok, the past part was just for entertainment, but the first half was
meant serious. I just found that the ways people intend to use the
system are so different that even different people mean entirely
different things what you say "WYSIWG editing".
Regards,
Torsten
>> Also Daniel Glazman seems to work on a Mozilla/XUL based XML editor
>>
>> http://disruptive-innovations.com/newsfeed.html
>>
>> (see at the very bottom about project from Rice University)
I could not find anything more than just the one sentence saying that
they embark on that project. But nothing as to if it will be an open
source effort or about status. Or did I overlook something?
Regards,
Torsten
Michael Wechner schrieb:
> Torsten Schlabach wrote:
>
>>
>> I have put he links to these editors together with some general
>> remarks on editors in the Wiki: http://wiki.apache.org/lenya/Editors
>
>
>
> thanks for the page
>
>>
>> Please comment!
>
>
>
> What we really need to consider are desktop based editors, as for instance
> OpenOffice.org but also M$ Word
>
> Also Daniel Glazman seems to work on a Mozilla/XUL based XML editor
>
> http://disruptive-innovations.com/newsfeed.html
>
> (see at the very bottom about project from Rice University)
>
> Michi
>
>>
>> Regards,
>> Torsten
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>> For additional commands, e-mail: dev-help@lenya.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Michael Wechner <mi...@wyona.com>.
Torsten Schlabach wrote:
>
> I have put he links to these editors together with some general
> remarks on editors in the Wiki: http://wiki.apache.org/lenya/Editors
thanks for the page
>
> Please comment!
What we really need to consider are desktop based editors, as for instance
OpenOffice.org but also M$ Word
Also Daniel Glazman seems to work on a Mozilla/XUL based XML editor
http://disruptive-innovations.com/newsfeed.html
(see at the very bottom about project from Rice University)
Michi
>
> Regards,
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Taking a fresh view at editors
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2005-03-28 at 21:20 +0200, Torsten Schlabach wrote:
> Hi again,
>
> besides the recent dicussion about a potential CForms editor to edit
> arbitraty XML form based (in other words: non-WYSIWYG), I found that
> there is a lot going on regarding the old and famous topic of
> WYSIWYG-(X)HTML or even XML editors ... A quick summary from my personal
> point of view.
>
Thanks for the work you are doing Torsten, it is a nice summary.
Excellent. :)
The CForms editor seems to be the nice out of the box solution that we
from lenya will provide for editing pages. The rest should be a good API
for other (WYSIWYG-(X)HTML/XML) editors.
> ...
> The idea will be to prototype BXE 2.0 as a proof of
> concept for a potential plugin architecture for Lenya.
>
> The major downside for me personally is that BXE is Mozilla only. No IE,
> no Opera, no Konquerer, no Safari.
That is the reason why we should provide only a good documented
interface and no implementations in the future.
The recent user discussion about another WYSIWG editor made this very
clear.
>
> There was some rumor in Cocoon land that HTMLArea would be discontinued.
> The threas is here:
>
> http://marc.theaimsgroup.com/?t=111193756400006&r=1&w=2
>
> This probably proofed wrong. We have had an idea to implement HTMLArea
> anyway (see http://wiki.apache.org/lenya/1.4) but to me this still had
> the problem that it was IE only again. I get sick and tired of this
> browser specific stuff.
>
http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/org.apache.forrest.plugin.htmlArea/
Ross started this plugin a while ago but I think we from lenya could
create a use case for this plugin and juice it up. This way we can
extend forrest plugins with lenya power ;-).
>
> On the Cocoon list there was a number of WYSIWYG editors discussed that
> might serve as an alternative to HTMLArea. Some were ruled out for
> License imcompatibilities, but I think this is a Cocoon problem as they
> want to embed it. We can reference it, can't we? If we manage to provide
> a stable editor plugin API, we could even try to convince any of these
> projects to package their editor as a Lenya plugin which would save us
> some work and give us additional exposure as people who come from the
> editor might upgrade to the full CMS later.
>
IMO we should try to learn from forrest plugins and they from our
usecases-framework. I reckon the combination of both will be awesome and
will solve heaps problems for both projects. Lenya/forrest can share a
common plugin base that will extend cocoon.
> I have put he links to these editors together with some general remarks
> on editors in the Wiki: http://wiki.apache.org/lenya/Editors
>
> Please comment!
Nice work.
>
> Regards,
> Torsten
>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org