[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
while.)
Eric
Re: [Debian-sf-devel] Future functionality questions..., Roland Mas, 2001/12/28
Re: [Debian-sf-devel] Future functionality questions..., Roland Mas, 2001/12/28
Message not available