On Tue, 17 Oct 2000, Mike Haberman wrote:
> Hello,
>
> I would like to propose a new direction for jyve2.0. I would
> appreciate your input. This note's a bit long, but hopefully, it
> makes sense.
>
> I would like to change the following :
> 1. the hierarchal data flow to be completely user/project defined.
Good idea. This is actually something I had been thinking about too. I
had been thinking of keeping projects/FAQs, but allowing topics to be
nested arbitrarily deep. I like your suggestion as looks like it is a
more elegant extension of what I was considering.
I'm not totally clear on how this works though. It looks like this system
allows for arbitrary nesting, but the maximum nesting level must be
pre-defined. Also, it looks like it could be fairly hard to add nesting
levels after there is already data in the FAQ system. I also see the
potential both for required maximal nesting (i.e. *every* question must be
at the same depth), and for flexible topic/question specific nesting
levels (i.e. you could have some questions 3 levels deep, others 4, and
maybe even a few 1 level deep).
> CREATE TABLE DataSegment
> (
> id SERIAL, // auto increment primary key
>
> parentID int NOT NULL default 0, // parent id, 0 is top level
> [ ... ]
> depth int2, // system assigned
> // = parent's depth + 1
> // best implemented as a trigger
> // will have a default implementation for
> // dbase's that don't provide that functionality
> );
Theoretically, you could have something with a parentID of 0, and a depth
of 4, which would allow you to put questions at the very top level. But
it kind of sounds like you're saying the depth gets automatically
assigned, so if the parentID is 0, the depth is required to be 1.
Perhaps another way to do this would be with something akin to a file
system (for lack of a better analogy), with projects/FAQs/topics being
"folders" and questions being "files" (and answers would be a special kind
of sub-file). This seems logical to me, as questions/answers really are
different than whatever organizational structure is implemented,
especially with regard to how they are displayed. It would also seem to
make a structure like this a bit easier to build:
project
|-- question1
`-- faq
|-- topic1
| |-- question1
| |-- question2
| `-- question3
`-- topic2
|-- question1
|-- topic1
| |-- question1
| `-- question2
`-- topic2
|-- question1
|-- question2
|-- question3
`-- question4
The only real drawback I see to this scheme is it makes it harder to give
names to the various nesting levels. That is, you can't really say,
"level 2 is FAQs, level 3 is topics, and level 4 is questions," because
there might be questions in level 2 also. Or in some cases, there may be
nothing but questions in level 3, making the level 2 parent more
topic-like than faq-like.
All that said, I don't know exactly what sort of database schema would be
needed to implement it. The table you suggested would probably work well,
except I would probably eliminate the "depth" field, and add some sort of
"type" field, or question/folder toggle, or something. Alternatively, you
could make a whole other table for questions, but that would require
making 2 selects to generate the question/folder list at any given level.
> 2. allow jyve to work with multiple dbases at the same time
> e.g. one database might for FAQs and another for
> internal helpcenter.
This sounds a lot like something that might be better off addressed by
running two instances of Jyve/Turbine, rather than internally within
Jyve? What do other people think?
One last thing... There have been a couple questions on this list in the
past about restricting access to certain projects/faqs. What do you all
think of adding an (optional) access control list to each element within
the Jyve system (both projects/faqs/topics/whatever replaces those, and
questions)? I think role-level granularity, rather than visitor-level, is
probably sufficient. Thoughts?
--
Greg Morris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
