Franz Josef wrote:
Some remarks to the statements of Taun.
[snip
quote]
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 projects definitely require Python or Smalltalk programming.
So it seems your saying that if Plone the app can do what you want, then
use Plone. Because Plone for the user is fine. But if you have to put on
your developer hat and get dirty, then you are on a sliding scale on
which at some point things can tip over to Squeak/Seaside/Pier. Correct?
But this is what I was looking for. It seems that I could spend a fair
amount of time in Zope/Plone creating and editing a plethora of files
and that I could spend far less time doing similar programming in
Squeak. Spend the difference on developing the things in Pier I might
want that Plone has available. Over time that would continue lower the
point of enter for Seaside/Pier on the above sliding scale. :)
It might not be the near or mid future, but if we create a target and
start working towards it. It could eventually come to pass that Pier is
competitive at certain levels and a winner on several. Just depends on
what your looking for.
I think that the productivity in Squeak/Seaside/Pier could enable us to
intersect with and compare nicely in the CMS marketplace at some point
in the future. The Plone people are already making their list for what
they want in Plone 3.5.
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).
Okay. Here your talking about using Plone when you can be a user, and
using Pier when you need to be a developer. I can see some use cases
where this could be possible. But I would have to think about it.
Seems like it could become complicated if you have a user/member
database, authentication and such. Managing permissions to content
objects across two content systems seems potentially problematic.
Would require some thought.
Thanks for the reply.
Jimmie
[big snip]