You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Lars Huttar <la...@sil.org> on 2004/01/22 21:45:11 UTC
centralized location for pointers to 3rd-party components?
Hi all,
I was recently reading the article
http://www.arielpartners.com/arielpartners/content/public/home/public/topics/technology/technologyR
eviews/zopeVsCocoon
in which the following quote caught my attention:
"There is an amazingly large set of Zope plugins available at Zope.org -- 655 at last count. Third
party integrations/extensions are starting to appear for Cocoon, but they are still largely
experimental. This difference is not due merely to issues such as a lack of developer "critical
mass" or project size. The Zope community has leveraged Zope's ability to administer and add
website content through the web to make it easy for community members to add and maintain
documentation and download areas for their own extension products. Cocoon does not yet have an
official channel setup for maintaining and distributing add-ons, which means the only ones that are
generally available are those that are officially part of the Cocoon project. Since most community
members do not have write access to the project archives, this severely limits growth in this area.
It is interesting to note that the Zope web site does not actually host any of the development
projects for the third-party add-ons, it merely acts as a catalog or clearing house for them."
The above was written Nov. 2002; some of it is doubtless out of date.
Nevertheless, as I search for a centralized list of third-party
Cocoon add-ons, I come up empty. All I found was an item on the
Cocoon wiki wishlist (http://wiki.cocoondev.org/Wiki.jsp?page=Wishlist)
wishing for one.
I added a comment seconding the motion.
It would be great to have a centralized place where third-party
add-ons are listed; it could be searchable by keyword and category;
the status of each project and a link to its homepage could be
presented there. This could include official Cocoon components as
well as third-party, experimental ones: the idea is to have a "one-stop
shop" for the components you need. There could be short descriptions,
links to documentation, compatibility notes, and even reviews
and ratings ("don't use this component!").
My thought was to just add a wiki page, "ComponentsList", and encourage
people to add pointers to their own projects to this page.
Of course that would only be a beginning... we'd ideally want
a formal database of projects, like on SourceForge or
http://zope.org/Products/all_products, which someone would
have to host and maintain.
Maybe someone would need to write a Cocoon application to
manage the list.
However, to get this catalog off the ground, maybe the best start
is just an easy wiki page.
The result would be that it would be easier for Cocoon users to find
out about the custom components that are available. This would mean
less reinventing of the wheel, and more collaboration on common
needs. And less ammo for those who would say Zope is better than
Cocoon. :-)
Any thoughts?
Has this been done or started anywhere, and I missed it?
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: centralized location for pointers to 3rd-party components?
Posted by Lars Huttar <la...@sil.org>.
Thanks for your reply.
> For such a component catalog you need a real component
> architecture. At
> the moment the integration of components is more or less
> difficult and
> must be done by hand. From the Cocoon community point I think
> we should
> wait for the 2.2 release and its real block architecture.
>
> Joerg
But wouldn't it still be useful to have such a list growing,
at least an informal one? It could always be superseded once
the new component architecture came out.
Isn't it already possible for someone to write a custom transformer
that will also be useful to someone else?
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: centralized location for pointers to 3rd-party components?
Posted by Joerg Heinicke <jo...@gmx.de>.
For such a component catalog you need a real component architecture. At
the moment the integration of components is more or less difficult and
must be done by hand. From the Cocoon community point I think we should
wait for the 2.2 release and its real block architecture.
Joerg
On 22.01.2004 21:45, Lars Huttar wrote:
> Hi all,
>
> I was recently reading the article
> http://www.arielpartners.com/arielpartners/content/public/home/public/topics/technology/technologyR
> eviews/zopeVsCocoon
> in which the following quote caught my attention:
>
> "There is an amazingly large set of Zope plugins available at Zope.org -- 655 at last count. Third
> party integrations/extensions are starting to appear for Cocoon, but they are still largely
> experimental. This difference is not due merely to issues such as a lack of developer "critical
> mass" or project size. The Zope community has leveraged Zope's ability to administer and add
> website content through the web to make it easy for community members to add and maintain
> documentation and download areas for their own extension products. Cocoon does not yet have an
> official channel setup for maintaining and distributing add-ons, which means the only ones that are
> generally available are those that are officially part of the Cocoon project. Since most community
> members do not have write access to the project archives, this severely limits growth in this area.
> It is interesting to note that the Zope web site does not actually host any of the development
> projects for the third-party add-ons, it merely acts as a catalog or clearing house for them."
>
> The above was written Nov. 2002; some of it is doubtless out of date.
> Nevertheless, as I search for a centralized list of third-party
> Cocoon add-ons, I come up empty. All I found was an item on the
> Cocoon wiki wishlist (http://wiki.cocoondev.org/Wiki.jsp?page=Wishlist)
> wishing for one.
> I added a comment seconding the motion.
>
> It would be great to have a centralized place where third-party
> add-ons are listed; it could be searchable by keyword and category;
> the status of each project and a link to its homepage could be
> presented there. This could include official Cocoon components as
> well as third-party, experimental ones: the idea is to have a "one-stop
> shop" for the components you need. There could be short descriptions,
> links to documentation, compatibility notes, and even reviews
> and ratings ("don't use this component!").
>
> My thought was to just add a wiki page, "ComponentsList", and encourage
> people to add pointers to their own projects to this page.
> Of course that would only be a beginning... we'd ideally want
> a formal database of projects, like on SourceForge or
> http://zope.org/Products/all_products, which someone would
> have to host and maintain.
> Maybe someone would need to write a Cocoon application to
> manage the list.
>
> However, to get this catalog off the ground, maybe the best start
> is just an easy wiki page.
>
> The result would be that it would be easier for Cocoon users to find
> out about the custom components that are available. This would mean
> less reinventing of the wheel, and more collaboration on common
> needs. And less ammo for those who would say Zope is better than
> Cocoon. :-)
>
> Any thoughts?
> Has this been done or started anywhere, and I missed it?
>
> Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: centralized location for pointers to 3rd-party components?
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
My understanding is that ComponentHaus is going to be both a web site
and the software underlying it. It will serve as a clearinghouse for
components and allow things like finding all dependencies for a
component, searching for a component based on functionality, etc. Upon
further thought I think your idea is both simpler and easier to
implement. Why not start it in the wiki and go from there?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/
Lars Huttar wrote:
>So ComponentHaus is a piece of software designed to manage
>a clearinghouse for components, and could be used to track
>Cocoon components? (I.e. ComponentHaus is not a web site
>for Cocoon components?)
>
>Lars
>
>
>
>>-----Original Message-----
>>From: Ryan Hoegg [mailto:rhoegg@isisnetworks.net]
>>Sent: Thursday, January 22, 2004 2:56 PM
>>To: users@cocoon.apache.org
>>Subject: Re: centralized location for pointers to 3rd-party
>>components?
>>
>>
>>I'm not sure if efforts are already underway. However, there
>>has been
>>some recent activity in the spice sandbox to set up a
>>"componenthaus",
>>which would have some of these properties. It's being
>>discussed on the
>>jcontainer-interest mailing list [1]
>>
>>--
>>Ryan Hoegg
>>ISIS Networks
>>http://www.isisnetworks.net/
>>
>>[1] http://www.jcontainer.org/mail-lists.html
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: centralized location for pointers to 3rd-party components?
Posted by Lars Huttar <la...@sil.org>.
So ComponentHaus is a piece of software designed to manage
a clearinghouse for components, and could be used to track
Cocoon components? (I.e. ComponentHaus is not a web site
for Cocoon components?)
Lars
> -----Original Message-----
> From: Ryan Hoegg [mailto:rhoegg@isisnetworks.net]
> Sent: Thursday, January 22, 2004 2:56 PM
> To: users@cocoon.apache.org
> Subject: Re: centralized location for pointers to 3rd-party
> components?
>
>
> I'm not sure if efforts are already underway. However, there
> has been
> some recent activity in the spice sandbox to set up a
> "componenthaus",
> which would have some of these properties. It's being
> discussed on the
> jcontainer-interest mailing list [1]
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net/
>
> [1] http://www.jcontainer.org/mail-lists.html
>
> Lars Huttar wrote:
>
> >Hi all,
> >
> >I was recently reading the article
> >http://www.arielpartners.com/arielpartners/content/public/hom
e/public/topics/technology/technologyR
> >eviews/zopeVsCocoon
> >in which the following quote caught my attention:
> >
> >"There is an amazingly large set of Zope plugins available
> at Zope.org -- 655 at last count. Third
> >party integrations/extensions are starting to appear for
> Cocoon, but they are still largely
> >experimental. This difference is not due merely to issues
> such as a lack of developer "critical
> >mass" or project size. The Zope community has leveraged
> Zope's ability to administer and add
> >website content through the web to make it easy for
> community members to add and maintain
> >documentation and download areas for their own extension
> products. Cocoon does not yet have an
> >official channel setup for maintaining and distributing
> add-ons, which means the only ones that are
> >generally available are those that are officially part of
> the Cocoon project. Since most community
> >members do not have write access to the project archives,
> this severely limits growth in this area.
> >It is interesting to note that the Zope web site does not
> actually host any of the development
> >projects for the third-party add-ons, it merely acts as a
> catalog or clearing house for them."
> >
> >The above was written Nov. 2002; some of it is doubtless out of date.
> >Nevertheless, as I search for a centralized list of third-party
> >Cocoon add-ons, I come up empty. All I found was an item on the
> >Cocoon wiki wishlist
(http://wiki.cocoondev.org/Wiki.jsp?page=Wishlist)
>wishing for one.
>I added a comment seconding the motion.
>
>It would be great to have a centralized place where third-party
>add-ons are listed; it could be searchable by keyword and category;
>the status of each project and a link to its homepage could be
>presented there. This could include official Cocoon components as
>well as third-party, experimental ones: the idea is to have a "one-stop
>shop" for the components you need. There could be short descriptions,
>links to documentation, compatibility notes, and even reviews
>and ratings ("don't use this component!").
>
>My thought was to just add a wiki page, "ComponentsList", and encourage
>people to add pointers to their own projects to this page.
>Of course that would only be a beginning... we'd ideally want
>a formal database of projects, like on SourceForge or
>http://zope.org/Products/all_products, which someone would
>have to host and maintain.
>Maybe someone would need to write a Cocoon application to
>manage the list.
>
>However, to get this catalog off the ground, maybe the best start
>is just an easy wiki page.
>
>The result would be that it would be easier for Cocoon users to find
>out about the custom components that are available. This would mean
>less reinventing of the wheel, and more collaboration on common
>needs. And less ammo for those who would say Zope is better than
>Cocoon. :-)
>
>Any thoughts?
>Has this been done or started anywhere, and I missed it?
>
>Lars
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: centralized location for pointers to 3rd-party components?
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
I'm not sure if efforts are already underway. However, there has been
some recent activity in the spice sandbox to set up a "componenthaus",
which would have some of these properties. It's being discussed on the
jcontainer-interest mailing list [1]
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/
[1] http://www.jcontainer.org/mail-lists.html
Lars Huttar wrote:
>Hi all,
>
>I was recently reading the article
>http://www.arielpartners.com/arielpartners/content/public/home/public/topics/technology/technologyR
>eviews/zopeVsCocoon
>in which the following quote caught my attention:
>
>"There is an amazingly large set of Zope plugins available at Zope.org -- 655 at last count. Third
>party integrations/extensions are starting to appear for Cocoon, but they are still largely
>experimental. This difference is not due merely to issues such as a lack of developer "critical
>mass" or project size. The Zope community has leveraged Zope's ability to administer and add
>website content through the web to make it easy for community members to add and maintain
>documentation and download areas for their own extension products. Cocoon does not yet have an
>official channel setup for maintaining and distributing add-ons, which means the only ones that are
>generally available are those that are officially part of the Cocoon project. Since most community
>members do not have write access to the project archives, this severely limits growth in this area.
>It is interesting to note that the Zope web site does not actually host any of the development
>projects for the third-party add-ons, it merely acts as a catalog or clearing house for them."
>
>The above was written Nov. 2002; some of it is doubtless out of date.
>Nevertheless, as I search for a centralized list of third-party
>Cocoon add-ons, I come up empty. All I found was an item on the
>Cocoon wiki wishlist (http://wiki.cocoondev.org/Wiki.jsp?page=Wishlist)
>wishing for one.
>I added a comment seconding the motion.
>
>It would be great to have a centralized place where third-party
>add-ons are listed; it could be searchable by keyword and category;
>the status of each project and a link to its homepage could be
>presented there. This could include official Cocoon components as
>well as third-party, experimental ones: the idea is to have a "one-stop
>shop" for the components you need. There could be short descriptions,
>links to documentation, compatibility notes, and even reviews
>and ratings ("don't use this component!").
>
>My thought was to just add a wiki page, "ComponentsList", and encourage
>people to add pointers to their own projects to this page.
>Of course that would only be a beginning... we'd ideally want
>a formal database of projects, like on SourceForge or
>http://zope.org/Products/all_products, which someone would
>have to host and maintain.
>Maybe someone would need to write a Cocoon application to
>manage the list.
>
>However, to get this catalog off the ground, maybe the best start
>is just an easy wiki page.
>
>The result would be that it would be easier for Cocoon users to find
>out about the custom components that are available. This would mean
>less reinventing of the wheel, and more collaboration on common
>needs. And less ammo for those who would say Zope is better than
>Cocoon. :-)
>
>Any thoughts?
>Has this been done or started anywhere, and I missed it?
>
>Lars
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org