Pier v. Plone
jason.johnson.081 at gmail.com
Thu Aug 16 06:13:20 MEST 2007
On 8/15/07, Jimmie Houchin <j.squeak at cyberhaus.us> wrote:
> Yes. But that is why I posted. Does the community desire to over time
> work in such a direction. If core Pier could move to and become =+ Plone
> core, then we can start talking. Add-ons and products can come when the
> machinery supports the basic usability and building blocks equal to and
> better than Plone.
And don't just look at Plone. Joomla is very nice as well with all
sorts of cool features and add ons (e.g. for the less technical
members of your web site team you can set up specific email addresses
that if they send mail to the Joomla website the mail gets turned into
an article with a template you configure to display it)
I can't imagine the answer being anything but "yes of course!". Pier
can and should compete in the CMS world.
As was mentioned in this thread, with Joomla, and I'm sure Plone and
everything else out there, you can get all kinds of components and
load them into your site to add new features. But there is always the
issue of trying to integrate them. And in some cases you have to do
complicated configurations of different software stacks.
In Pier we have all the integration of a homogeneous system. Pier can
run any component made for Pier *or* Seaside. So if someone writes
things for base Seaside, or even some other framework under Seaside
Pier can potentially use it. And with the Pier #call:/#answer:
scheme, as well as normal message sending, composability really can be
a matter of simply sending a message to a component to do it's job.
And for building new components, I don't know what the Joomla or Plone
frameworks look like but it's hard for me to imagine them being easier
to make something new then Seasides, i.e. simply create a normal
model-domain object and put a render method, or just a Magritte
description to display it!
I also personally think that in Seaside we have a much better chance
to avoid the configuration nightmare of some of these things. No
config files! One should be able to configure and change anything
from the code or inside the website itself.
We could even have a component that generates apache rewrite rules for
your site. :)
More information about the smallwiki