15 Aug
2007
15 Aug
'07
12:09 p.m.
Some remarks to the statements of Taun.
- rg performance - I don't see performance problems with a well
configured Plone 2.5.x environment when using CacheFu with Apache. If
this isn't enough you can use Squid or Varnish. A prerequisite is of
course enough RAM (>= 1 GB). Of course Plone is known, not being the
fastest.
- rg Software Stack - with 2.5.3 and the upcoming 3.0 release you have
the universal installer that takes care about all the dependencies of
your libraries. Anyway, I never run in problems on Debian based systems
with simply install with apt-get what you read in the install files.
I don't see that Pier can reach the the functionality that Plone
delivers today in near or mid future. If you make a list with
requirements what you need for your app and Plone covers most of them
*out of the box* then go with Plone. If you have, let's say 50% what is
not covered out of the box then it's a different picture. Of course you
can do everything with Plone and some developers do, but this doesn't
make always sense.
My idea is to use *both*. Plone and Seaside. Use Plone for everything
that's easy to use out of the box and use Seaside for requirements that
would need special python programming. It should be possible to bring
both together with either http://plone.org/products/htmlproxy (a proxy
based integration) or http://plone.org/products/windowz/releases (iFrame
based integration).
I haven't tried this approach but it's on my todo list.
regards,
Franz Josef
Taun schrieb:
Jimmie, I have been agonizing over the same choice for
months. For now, I am sticking with
Plone for my clients.
I have worked with Smalltalk since the late 80's and Plone since it's inception
on top of
CMF for Zope.
Plone Cons -
Past performance - Historically, I have had major performance problems with Plone
including memory leaks leading to repeated server restarts on an almost hourly basis
under
heavy loads. Performance has improved but I am still concerned for the site I am
currently
creating using Plone.
Software Stack - This is my biggest complaint. The Plone stack is too dependent on C
libraries and python modules and zope adapters. For example, connecting Plone to
postresql
requires a postgresql adapter which consists of a stack in C, python and Zope. Like most
OpenSource, all the versions have to be compatible. Just the out of the box stack is
python C virtual machine binary -> python libraries -> Zope -> CMF -> Plone
-> Plone
Standard Products. Addon products such as PIL (imaging library) add a 3 layer stack of C
module, python module and Zope module.
Development environment doesn't hold a candle to Seaside.
Plone Pros -
Very active community.
Tons of interesting Products.
Workflow and security model very easy to customise.
Easy to add custom products with ArchGenXML and ArgoUML.
Very Easy to add custom content types with ArchGenXML and ArgoUML.
**Visual Tools like ArgoUML/ArchGenXML are what are really missing from Squeak. You
use
ArgoUML to create a UML class diagram for your product or content type. You then run
ArchGenXML to create a Plone product from the class diagram. I am currently using this
process to create a site with 8 custom content types with cross references and it is
very
easy.
http://plone.org/documentation/tutorial/archgenxml-getting-started
Squeak Cons -
The flip side of all of the Plone Pros.
Squeak Pros -
I much prefer Smalltalk to Python.
I prefer the Smalltalk environment to any Python IDE.
I think people write better Smalltalk tools/objects than Python programs.
I prefer the architecture and tools of Seaside to Plone.
Much shorter stack - Smalltalk VM -> Smalltalk source -> Seaside -> Magritte
-> Pier.
Fewer C module dependencies for add-on products/objects.
Personal Conclusion -
Zope/Plone feels like a framework where you are locked into the frame.
Smalltalk/Seaside feels like a great tool box to help you build whatever you want.
Unfortunately, I would have to build Plone when that is about all I need.
If one only needs the functionality provided by Zope, Seaside is the better choice
for
me. I would be more productive and have a better end product with Seaside versus Zope.
I chose painful but functional Plone over Fun but less functional Pier based on the
Plone Workflow model, ArchGenXML for products and many available 3rd party products.
I really hope to be able to make a different choice in the future.
Taun
Jimmie Houchin wrote:
Hello,
I am exploring my options for a couple of websites. I am a big fan of
Squeak, Seaside and Pier. But I have been exploring and learning about
Plone.
There is a tremendous amount of energy and work behind Plone and
products available for it. Plone 3.0 is about to be released. They have
put a lot of work into UI usability and into a lot of areas which are
nice to not necessarily implement yourself.
That said, I don't really have a grasp as to how far Pier is from
Plone-like abilities for both the end user and the developer.
One thing I am looking at is the Plone4Artist product which implements a
very sweet package for multimedia and Plone.
http://www.plone4artists.com/
I do very much like Squeak over Python.
In general I like Seaside/Pier over Zope/Plone.
I know that Lukas has used Zope/Plone, but I don't know how current his
knowledge is.
How far is Pier from offering a competitive experience to end users and
developers with regard to something like Plone?
Is there any interest in the community of competing in that sphere?
Or do most here happily use Seaside/Pier as a toolbox and the bigger
application type CMS isn't on the radar?
And initially I speak as to a basic Plone 3.0 out-of-the-box
capabilities and user/developer experience. Not necessarily the plethora
of add-on products. Those can come later if the out-of-the-box
experience is compelling enough.
Naively it seems that content types are easier to develop in Pier as
opposed to Plone.
I just don't know how much I could build on Pier towards a Plone-like
experience in the time it takes to do some things in Plone. And I really
don't know how much of the machinery that makes Plone what it is, is in
Pier. Or the effort to get there.
Comments regarding my questions above or most anything relevant to Pier
v. Plone 3.0 are greatly appreciated.
Thanks.
Jimmie
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki