[Zope-PTK] helping my decision
Wed, 19 Jul 2000 00:49:11 +0200 (CEST)
Hi, I have to build a portal as a practical part
to my master thesis(it's on portals).
Previously I intended to do it in zope with products
like GUF, Openticket, LocalFS, etc ...
Then I recognized that most of this parts are included
in PTK - so PTK looks to me like a package where all
this products are bundled and connected in some way ?!
Is it much effort to build a portal from PTK with the
following features (that means without coding python)?
- i have 4 roles : reading without contribution
member with permission to contribute
owner of my personal page
admin who has access to evertything
- members should be able to build there own (home-)page, which they own
- members can write and answer trouble tickets (like in Openticket)
- members can upload files to an area (local filesystem?)
which can also be viewed by readers
- members can give comments on this files, which can be read by
readers and members
- trouble tickets, comments and file-name must be searchable by
It's not that I don't like python - the opposite is true, but
as mentioned it takes a while to go into the code and that's
what I cannot afford, because of timelines. So what I want
to know: Is it easier to do all this in plain zope with products,
or is it *faster* to go with PTK ... ???
Any hints will be greatly appreciated ...
> Didier Georgieff wrote:
> > Steve Alexander wrote:
> > > It is usable, and it does mostly work.
> > That was my main concern.
> > > Just, there isn't much
> > > documentation, and it probably isn't clear how to proceed with designing
> > > a site that is too far different from the DemoPortal product supplied
> > > with the PTK.
> > OK. May be we can build an how-to in the process.
> > > You haven't said what your Zope experience and Python expertise is yet.
> > This portal will be for my spare time activity for putting together the net
> > community around Australian rock, in an "open-source" way 'share gig, date,
> > promo, etc ...) that are already in touch.
> > In the 'real' life i'm engaged in a big projet for government agencies in france and
> > we will use Zope for that.
> > So my Zope experience is quite new (6 weeks) but Zope is so powerfull that i
> > already built the shared adressbook quite easily (only DTML + ZSQL, no
> > Python expertise at all).
> > So i guess it will improve with the time, or at least i hope so ;-))
> At present, as soon as you get past the very surface level, PTK has a
> steep learning curve.
> I suggest you take the time to learn Python -- it doesn't take long, and
> it is a very elegant language. Try the Lutz and Ascher "Learning
> Python", published by O'Reilly.
> PTK is a complex Zope product. It uses some of the more advanced
> features of Zope. Although the code is fairly easy to follow, there
> isn't much documentation of the overall design. This makes getting into
> the PTK code more difficult.
> You'll find it easier if you've built Python products for Zope before.
> Take a look at the Boring product, or even one of the other useful
> products such as the Random products or Photo.
> There's some "esoteric knowledge" involved in understanding products
> like PTK, so be prepared to read lots of the mailing list archives, and
> try lots of experiments on the code to see what it does. Expect to spend
> time tracing through the code to see how it all hangs together.
> PTK uses various parts of the ZPatterns development framework. This is
> considered by many to be very esoteric and difficult to get into.
> The membership portions of PTK are based on LoginManager.
> You might want to spend some time looking into these.
> > > In fact, it would be really helpful if you can answer the questions I
> > > put to the last person to ask a similar question on this list:
> > > http://lists.zope.org/pipermail/zope-ptk/2000-June/001045.html
> > OK. I'll try to.
> > > What are you aiming to do?
> > this portal was inspired by the feeling that all of us (Australian
> > independant rock) with on-line presences are basically pissing into
> > the ocean in trying to get a decent audience, and I feel that we'd all
> > have a better chance of "success" if some of us formed a
> > collective, and pooled our resources.
> > Idea, was for the portal to essentially be a very cool and vital
> > zine, with updated news, gigs information and reports and really
> > good content, with an on-line shop, MP3s of the week and all that
> > kinda stuff, a really great links section, (search able) and streaming
> > audio of pre-recorded 'radio shows' of new releases and
> > interviews etc.
> > The Portal would be the absolute first stop for anybody wanting
> > info on Australian rock'n'roll.
> This sounds like a job for the not-quite-written-yet PTK-Squishdot
> combination. Perhaps Chris Withers can chime in here :-)
> > > How many users?
> > 10 millions of readers, but may be less than 20/30 "managers".
> Let's divide the users into three types:
> Readers: only read, never add content or comment on content
> Members: add content and comment on content
> Managers: vet some content before it is published, manage the site
> How many of each type of use do you need to support?
> Zope and PTK (using LoginManager) can handle loads and loads of users.
> There are some issues with PTK's arrangement of user's home folders that
> can cause a problem with many registered users on a PTK site. There are
> ways around this, and it will be fixed in a future PTK release. You
> might find you have to hack PTK internals to fix it, though.
> > > Do your users take on different roles?
> > Yes, but only for the "managers" with differents roles according to the section
> > they have the managing role.
> > > When do you aim to deliver a working version?
> > ASAP. But we all have already some web site working, mainly by hand.
> > Content is already there.
> If you're going to use PTK for this, you should be prepared to keep up
> with changing software. Although we'll try to keep new releases
> compatible with old data, inevitably there will be problems. Learn about
> external methods, and how you can update objects as needed.
> > I guess the first working version should have the news/gig announce/new record
> > announces/Listening section working.
> > And the rest will be added quietly while switching from the ancient web sites.
> I'm not sure what the Listening Section does, so I can't comment on
> If you're storing lots of MP3s, you should consider using LocalFS and
> Apache, so you can store them on the filesystem rather than in the ZODB.
> You can easily have news, gig announcements and record announcements
> with the current PTK and minimal labour.
> > > How critical is the timing of the project?
> > No real pressure because it's an "open" and cooperative portal but the decision
> > is NOW (technical architecture, design, hosting, switching, ...).
> Your requirements are very much aligned with what the PTK is about. That
> very much suggests you'd do well going with the PTK for this.
> Unfortunately, the PTK is young, ill documented and a bit hard to get
> into. Only you can decide whether that makes it too risky.
> You can always ask on the Zope-PTK list for free help. There's probably
> also knowledgeable folk around who would spend paid time consulting on a
> PTK project. You also have the source. So you have several options.
> > > What is your project team's background in developing software in Python?
> > at the moment the team is greatly composed by me ;-)
> > No python knowledge but other languages, so i can take the path.
> > > What is your project team's background in developing software usingZope?
> > Quite new, but now involved professionally so should go better in a while. (if not
> > i'll be fired ;-))
> > > How do you expect the system's requirements to evolve over the nextthree
> > months?
> > I don't understand. Which system ? PTK or my portal ?
> Your system.
> > I'm planning to add the missing functions i need as long as i know (and
> > understand) how to be in the PTK framework.
> > The main concern is to be able to develop now and NOT to have to rebuild from
> > scratch if major things changes. Small changes are unevitables and will be
> > managed.
> You should not have to rebuild from scratch. You might have to do some
> work keeping your data up to date with changes in the PTK.
> > > Do you need to interface with external systems for authentication?
> > Normally no. (see up there)
> > > Do you need to interface with databases other than the ZODB?
> > May be, but not for the first versions, i guess the functions can be handle in
> > ZODB nicely.
> Other than the MP3/large files issue, I think it can all live in ZODB.
> If you have very large membership, you might want to set that up in an
> external RDBMS.
> > Just an addition.
> > For my "professional" project, the responses are :
> > > Do you need to interface with external systems for authentication?
> > Yes. MySQL tables thru ZSQL.
> > Tables used and already designed for an application
> > that shared corporated "four 11" between 40 govnmt
> > agencies.
> Look into LoginManager for that.
> In summary: I think PTK is a good match for what you want. However,
> there are substantial risks because PTK is new, and evolving, and you're
> not very experienced with Zope and Python.
> Hope that helps.
> Steve Alexander
> Software Engineer
> Cat-Box limited
> Zope-PTK maillist - Zope-PTK@zope.org
> See http://www.zope.org/Products/PTK/Tracker for bug reports and feature requests