[Zope-PTK] PTK II

[Kapil Thangavelu]

Hello All,

I've followed the PTK project for some time... i've had some issues with
its design and philosophy but people are pretty gung ho on it and i
decided to lurk on this list instead. I've been implementing a Portal
toolkit/framework on my own, i realized that this is reimplementing the
wheel but I thought the fundamental assumptions of the two were two
different to be compatible. I cvs'd out a copy of the latest Zope/PTK
stuff and realized that i was being foolish to reimplent the work of
many others so I am going to layer my work over the PTK. But since the
discussion was going on regarding the design i thought i'd offer my
input... i might get flamed but hell i might learn something as well:)

Shane Hathaway wrote:
> 
> PTKers,
> 
> What do you think of the following direction for the development of
> PTK?
> 
> I envision PTK as not a framework but a toolkit.  A framework is a
> thing which is mostly built but needs customization.  It's like leasing
> office space.  A toolkit is less restrictive but more flexible.  It's
> like having the tools and materials to build your own office space.

I totally agree. 
 
> So PTKBase should be a toolkit while PTKDemo is a framework built from
> that toolkit.
> 
> As I look over PTKBase and PTKDemo, I see little evidence of
> separation.  I wanted to move the five basic content types from PTKBase
> to PTKDemo, but discovered that DiscussableItem inherits from Document,
> one of the content types.  This means either PTKBase would depend on
> PTKDemo or all the Discussable code gets moved to PTKDemo.
> "Discussable" should be a feature of PTKBase, not PTKDemo.  This is
> evidence of an architecture problem IMHO.
> 
> So I came up with an idea.  What we want to be able to do is have a set
> of "tools" at the base of the portal.  These tools would include:
> 
>   - Membership database
>   - Workflow attribute access
>   - Discussion access

I think this begs the question what is a portal and what is required of
a portal toolkit.

I've been working on intranet portals for the last few years. When I
think of a portal I think that fundamental to a portal toolkit are

	- User/Membership which includes the key problems of Session
Management, User Info (possible/probable integration with multiple
external systems), User Preferences for a site (with multiple options
for storage), and User Authentication (must have hooks for external
authentication), and User Permissions (with knowledge of heirarchial
groups).
	
	- Service building toolkit. An interface for services to interact and
find out about each other. IMO without casual knowledge of all services
on a portal it requires some type of service registry. Registry should
register services by name and view_type (discrete UI/content element),
and search interface parameters/type. 

	- A templating system for skin/ui/layout management. Any implementation
of the Portal requires it. This is site specific but without building
this into the toolkit it requires too many headaches on the part of the
site implementor to manage signifigant changes to a site layout and to
offer site customization to users. by including this in the toolkit
there is a standard for it. in otw this is a signifigant enough problem
domain that needs to be addressed by ALL site-implementations that
implementation to facilitate should be in the toolkit. 

beyond that all portal issues are in the domain of the site to
implement.
they have means to build their own services or pick from the services
currently being offered.

so what is a portal?

fundamentally to me a portal offers integration of distributed or
seperate resources to the preferences of its users and its purpose. It
offers services to these users to increase the value of the community in
they're work/lives.

perhaps this blurs the abstraction between a framework and toolkit...
but i'm more akin to think of a portal as service-centric system
designed for community members which requires that the toolkit be a
framework for developers to build/choose new services and customization
to build an actual site.
	
on top of this for a Zope Portal I think that

	- the services for the portal should be configurable from outside the
management interface.
	
	- information access shouldn't be so ZODB centric. work flow attr.
access should flow from the service registry. services can let implement
methods for access to an individual item/objects access that a developer
deems important for public access.

in terms of designing my toolkit i've been heavily influenced my two
other portal projects namely

http://java.apache.org/jetspeed
check out the uml models. jetspeed aims to be an enterprise scalable
portal... and IMO its doing pretty well.

http://www.mis2.udel.edu/ja-sig/portal.html
a .edu portal framework with lots of big name backers. the meeting notes
are informative... i regard think this project has potential but I think
they're making some minor design mistakes and implementation has been
slowwwww.

One of my problems with the PTK has been its user-centric concept. If
i'm trying to build a portal to scale i shouldn't have to jump through
hoops to make it fast.

There are def. benefits to a user-centric model in terms of data
management /mining of users as a community scales. Every bit of
user-entered info is a bit of gold to be added to a pot. With can come
information and programmed rules about what happens when a user
interacts with the community enough. Think meta-moderation (ala
slashdot) and customization als amazon. it becomes trivial to access the
info on a per user basis but much harder/slower to do it on an all user
basis. A pure user-centric model is to slow. look at the implementation
of Discussables/Items. A catalog search on every page is too
prohibitive, which i think began this search for a better model. A
well-designed OO system is nice, but a well-performing implementation is
better.

Some of the organizations that i'd like to build portals for are several
thousand members strong composed of many groups. I've been working with
the ACS system as of late and to be honest its pretty awesome and it has
communities with hundreds of thousands of users! But i'm committed to
using Zope for an open source portal project. Reasons: I like python
over tcl and Zope offers many benefits. The primary being not coding to
and learning the idiosyncracies of a closed propertiary package like
Oracle. 

A good example of the lack of scalability of a user-centric model I
think is zope.org... the membership roster on zope.org is still down.
try waiting for http://www.zope.org/Members/objectIds and see how long
it takes. Perhaps a BTree based system will help out, but if so that
should be incorporated into the toolkit from the getgo... not left as a
problem for an integrator/programmer to tackle on by themselves.

<aside:> why is the catalog on zope.org having so many problems? its my
primary reason for staying away from catalog for any complex/large
searches other than simple object type referencing from
properties.</aside>

I shouldn't have to reengineer the portal to scale, by tossing ZEO and
mountable storages and BTreeFolders in combination (although IMO this
still requires fulton-like knowledge of the ZODB to do). A benefit to
the service centric is that its not so ZODB specific and some of this
info can be tossed into a backend RDBMS using the object model/ZODB to
best effect.

> The default workflow attribute access tool would query documents about
> their workflow status, as is done now.  But it should be possible to
> retrieve and store workflow status in another way, such as from context
> or using a specialist.  This could be achieved by replacing the default
> tool.
> 
> The discussion access tool would enable us to solve a problem we have
> right now: every view of any portal content generates a catalog query.
> That's not necessarily a good thing.  The discussion access tool could
> govern the storage of discussion information.

IMO This type of stuff i think has no real place in a portal its a
site-specific implementation issue. A portal toolkit should facilitate
users building they're own services. Why should Discussable be part of
the Portal Toolkit?

> Basically, where PTKBase currently uses subclassing to achieve
> membership (as opposed to simple users), workflow, and discussability,
> we should instead use singleton objects that add capabilities without
> subclassing (although the initial implementation will make use of
> existing subclasses.)  I think this is exactly what Phillip's vision is
> for ZPatterns.

I'm not down with the OO Patterns enough to grasp this. Whats the
problem with subclassing? To me it seems tying to togther multiple
singleton objects requires too much intimate knowledge for a portal to
add lots of new kinds of services or singletons. I've read through the
ZPatterns stuff and the links (law of demeter, method delegation, open
implementation, good links!) and toyed with the idea of implementation
in ZPatterns of my toolkit but time and lack of understanding on where
to design the system from a high level stopped me (weaving togther a
specific problem domain isn't too bad but many aspects into an app?). To
me the PTK problem is a clean toolkit.
 
> Comments?

Included:) More Comments?

Kapil

http://sin.sourceforge.net # info on wikis a bit outdated and confusing
http://lostworld.imeme.net