[Zope] - OO paradigm

[Michael Bernstein]

Dave G wrote:

> At 4:51 PM -0800 1/21/99, Michael Bernstein wrote:
>
> >This in essence, would let us:
> >1) factor content and functionality that we currently cannot (or at least,
> >not as
> >easily). ('is a' inheritance)
> >2) provide alternative navigation to the same content ('in a' inheritance)
> > 2a) path dependent navigation and content rendering (by giving precedence
> >to the
> >path taken, where properties or methods conflict)
> > 2b) explicit and simple path analysis from server logs
> >
> >I think I'm repeating myself.
> >Add to the list if you can think of other applications.
>
> 3) dynamic creation or shaping of properties based on navigation paths.
> 4) alternative rendering of content based on instance
>         4a) 'if  in a' else  'in b'
>
> Does that make sense?

Yes, although I was primarily thinking of placing methods and documents (headers,
navbars) into the 'branch' objects to change how content and context is displayed.
Attaching properties to them to control which content is displayed should be
possible too, though I wouldn't go overboard with it. I would rather put switching
properties into the branches, and leave the switching logic in the actual content
folders default document (although that could still be acquired from higher in the
'normal' or 'primary' heirarchy).

For this to work, you would need a structure like this (please forgive the
pseudocode):

-----------------------------
Root
   /Branch_Language
      /Leaf_French
         language_property = F
      /Leaf_Russian
         language_property = R
   /Content
      Assign to Branch_Language/Leaf_French
      Assign to Branch_Language/Leaf_Russian

      /index_html
      /default_content
      /french_content
      /russian_content
-----------------------------
Then, since the property 'language_property' has conflicting values, zope would
use the one that takes precedence as a result of the users actual URL path.

The 'index_html' document would then contain a simple conditional statement to
insert the correct <!--#var -->.

Subsequent sub-folders from /Root/Content would just need the appropriate content
documents.

This would require, in contrast to an earlier idea of mine, the ability to make
assignments to more than one location within the same 'branch'.

Note: This example is an expansion of an idea presented earlier by Paulo Eduardo
Neves.

I will submit an example of alternate navigation paths to the same content in a
subsequent posting.

Michael Bernstein.

P.S. I consider myself an Information Architect, not a programmer. I am presenting
these ideas in the hope that someone on this list will find them interesting
enough to implement.