[Zope3-dev] general question regarding zope3

[Jeffrey P Shell]

(I know this is an old thread, but I happen to have a quiet moment 
(sortof) and was digging through my Zope3-dev folder before cleaning it 
out).

On Monday, August 11, 2003, at 09:08  AM, Garrett Smith wrote:

> ChongQing Xiao wrote:
>> Sorry, I mean www.erp5.org
>> As for handle complex relation, Could you give me zope3 (or zope2)
>> examples (link to the document?)
>
> Stephan's bug tracker is a good example of managing a one-to-many
> relationship (tracker-to-bug):
>
> Source: http://cvs.zope.org/Products3/bugtracker/
> Demo: http://www.zope3.org:8080/demos/++skin++tracker/tracker

First - Die, plus-pluses in shared-amongst-people-urls, Die Die!

Second (the one to many relationship thing): Not really.  And I mean no 
offense, but it's way of handling is pretty basic.  It works for its 
situation if you just have a "i depend on these issues" one way 
relationship.  But when I get down  deep into a tree, I would like to 
see "these are the parent issues that are waiting on you."  In short, 
two way relationships.  A "BugDependsOn" adapter.  One that doesn't 
have to crawl through the Tracker container looking at every object to 
see what points to a child.  I guess one could write one that cached 
such data, but then I'm unsure how you'd trigger/catch the event when, 
say, Bug 1 decides that it's no longer dependent on Bug 8, without 
coding all of that handling explicitly.

> ZWiki is an example of a Zope 3 product that implements a many-to-many
> relationship (a page can have multiple child and parent pages):
>
> Source: http://cvs.zope.org/Products3/zwiki/
> Demo: http://www.zope3.org:8080/demos/++skin++wiki/wiki

They also store everything in a flat namespace.  It's easy for the 
BugDependencies adapter to say "ok, this depends on 2, 12, 24, and 48", 
because bug id's 2, 12, 24, and 48 are all within the BugTracker 
container.  Likewise, all Wiki pages are in a single container.  It 
makes pointing to parents easy - it's just a name within a parent.

But what about linking between a Wiki and a Bug?  Let's say you've got 
Bug 6 about 'containergeddon'.  It would be nice to put a good link 
between it and a wiki page about ContainerGeddon, even though the wiki 
is in a different location on the site.  Then it would be nice to go to 
the ContainerGeddon Wiki page and have it say "referred to by - bug 6" 
and maybe even display some data about Bug 6.  If ContainerGeddon gets 
renamed to ParentGeddon, Bug 6 shouldn't lose its link to it.

> [SNIP]

> I'd like to hear more from the list regarding your "complex
> relationship" question. The question isn't so much "can" these
> relationships be handled, but "how" -- or what's the best approach? 
> Here
> are some options:
>
> - Implement object relationships using an object or container attribute

No.

> - Implement object relationships using annotations

For simple one way controlled environment relationships, yes.  Or, at 
least, maybe.  It depends what sort of objects you put in the 
annotations.  You could use annotations in combination with a 
relationship object.

> - Implement object relationships using a relationship object (e.g. an
> indexing scheme)
>
> - Implement object relationships using a relationships service (there's
> been some discussion about this)

I keep kicking this discussion up, and I don't think I follow through 
as much as I should.  *sigh* time.  And time is about to get worse now 
that I'm adding school to the mix.  But I like either of these two 
ideas.

I know that when I want to combine two disparate 
applications/components/etc, like a document management system and a 
bug tracking system, that I'm going to have to write some custom 
code/configuration/templating to tie them together to do the situation 
I outlined above (ie - have a bug/task to "write final contract", and 
be able to make a pretty strong link between it and a Contract Document 
that may be managed in a Silva-like system.  I'd like that link to be 
two way, so that on the template for the document it could say "watched 
by" or "related to ..." with a link back to any objects that have a two 
way link to it.  Since the contract is in progress, it may move to a 
final area upon completion.  Again - it would be ideal if the code for 
the link to respond to its move in order to stay correct were fairly 
simple.

Fortunately, Zope 3 has its event system.  It was lack of decent event 
publishing/subscribing that made this very difficult to deal with in 
Zope 2.  It was too difficult to write something that could respond to 
an object being moved.  It was especially difficult to track movement 
instead of deletion.  This was mostly due to the fact that the actions 
that handled deletion,movement,renames,etc, didn't really have any 
common way of sharing that information with outside observers.

> I think you're right to observe Zope 3's content-centricity, but
> (personally) I view Zope 3 much more like .NET or J2EE -- i.e. very
> capable of handling traditional business applications. I'd encourage 
> you
> to keep posting your questions to the list -- there a lot of people 
> here
> who'd like to see your type of application built using Zope 3 :-)