[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Debian-sf-devel] Future functionality questions...

From: Eric D Nielsen
Subject: Re: [Debian-sf-devel] Future functionality questions...
Date: Thu, 27 Dec 2001 15:31:49 -0500

:Tim writes:
> What is REALLY needed are two things. A generic hierarchical object and a 
> generic symlink object. The hierarchy stores symlinks. Each object has a 
> unique ID (OID or a serial). The symlink is what is stored in the 
> hierarchy. Each hierarchy is nothing but a table containing the leaf nodes 
> and the symlink. I was thinking about coding up the examples in the "SQL 
> for smarties" book by Joe Celko.

I've seen stuff like this before.  Before we had decided to use SF I was 
designing our site and something similar to this was in the works.  I think
it is something that can be very useful, but basically requires a complete
rewrite of the db accessors and possibly the schema as well depending how
you choose to implement your generic symlink.  (ie does the generic symlink
contain the tablename, key field name, and key ID number; do you require
certain meta descriptive fields in your symlinkable tables for automatic
browsable navigation, etc)  Given the way SF accesses the database such a 
change affects next to every page/file.  You do gain an advantage of being
able to add ACL style meta-data to the symlink for context based security if
you want (I think that's what you allude to in a later paragraph).

(I may have missed your point in which case my long "essay" here is
probably useless....  Actually the more I write, the more certain I am
that I'm missing part of your idea..... )

The debian-sf folks so far have done a wonderful job of packaging a SF
solution that works pretty much out of the box and doesn't truely require
a SQL hacker there is minimal need of even a php coder if all the install
wants is simple name customization.  In the future I would hope that people 
like you and I who are building on their work make more and more of the 
customizations possible from within the SF environment so that not even
that minimal php knowledge is needed.  A result of this philosophy drives me
away from any solution that requires an installer to have to play with 
manually adding tables to the database as any table added requires both SQL 
and PHP knowledge to make the site interact with it.

While it would be easy to have the heirarchy/symlink tables creatable from
a web interface doesn't it still require another table?  Ie the table that 
holds whatever information makes a department a department to continue your
example(It can't use the group table or it wouldn't have been stretching the
metaphor to use a foundry....)? 
Wouldn't some coder need to write the display routines for this
object (assuming we have an underlying generic post/retrieve mechanism)?

I'm hoping that by expanding the flexibility of the provided foundry object
we can create a system that works in many different hierachical arrangements 
without having to have a user modify source/schema.   Because foundry and
projects are both groups and all the tools are defined at the group level all
the tools are accessible to foundry if someone (me right now) codes a way for
the administrator to turn them on.  Ie if you want to let a foundry(dept.) use
the task tracker, you would just turn on the task tracker for that foundry.

What may be more useful to the site admin is to have a set of foundry 
"templates" availible when approving foundries with appropriate sets of 
tools turned on and public/private by default.  Perhaps even some default page 
layouts for the different types of foundries.  (This is just wild 
brainstroming on my part.  I won't get to something like this for a long 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]