[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Category Object Model
Read this when you have some spare minutes, but before our Tuesday IRC
meeting.
The Category Structure
Old Design:
Any application could be tied to any category and any number of
categories. Likewise, any category could be a child of an infinate number
of other categories. While this allowed for immense flexibility in our
categorization scheme, it introduced many un-needed complexities into the
design of this site. It also gave way to the need for an externally
inforced method of categorization so as not to confuse the end-user. Not
all of this was clear when I designed the system many months ago.
New Design:
In the new design I am making maximum use of a new table set I have
created and implimenting a more rigid object model. I'm renaming the
"Categories" table to "Objects". This will have a minimal impact on
everyone's code. As far as I know there is not too much code implimented
that specificly refers to the "Categories" table, with the exception of
the article submission stuff which I am not quite clear on, but will be
having a one-on-one meeting with Daniel to go over. Also, the table
structure itself WILL remain the same.
How it works:
There will be several different types of objects:
CType, Service, Application, Version, Dependancy, and Dependancy Version.
No one will every access these tables directly. I'll be working
dilligently over the next week to fully flesh out the objects to utilize
them in php. I've already got a significant portion of the code in place.
The hiearchy looks like this:
Root
|
|-> CType
| |
| -> Service
| |
| -> Application
| |
| -> Version
|
|-> CType
|
-> Service
|
-> Application
|
-> Version
|
-> Dependancy
|
-> Dependancy Version
|
-> Dependancy
|
-> Dependancy Version
First an example, and then I'll explain:
Root
|
|-> Networking
|
-> DNS
|
-> Bind
|
-> 8
|
-> RedHat
|
-> 6.0
Things may look similar but there will be stark contrasts in this method.
1) ArticleCatXref disappears. Articles are only placed in ONE category.
The ability to have more than one parent is bad design. This will spead
article queries up drasticly. One more field will be added to the
articles table: "Location", and that will be the object the article
resides in. Articles can reside in anything below the CType object.CType
is an organizational object only, all others are organizational
containers.
2) RelatedLinks is renamed to "ExternalLinks" to reflect it's external
documentation nature.
3) An Internal link structure is created to allow objects to link to
Articles contained within other objects as related material, etc. while
maintaining the same URL for that link for indexing purposes.
4) Perhaps the biggest difference is that articles and
sub-categories/objects will co-exist. If I click on DNS, I may see a "DNS
Configuration" article along with sub-categories of BIND, nslookup, etc.
Searches will still be re-cursive, so nothing really changes from the
search engine's standpoint.
Below the Version object you hit the Dependancy structure. I've put this
in place instead of breaking out Distributionsinto the main tree. It's
also more robust as it can be used for ANYTHING. You can now say, this
article applies to BIND-8 when running under RedHat 6.0 with the DHCP
client of 1.x installed if you want to. You don't have to fill out
dependancy information for an article... it's optional. At the dependancy
level, articles cannot be directly assigned... they can only be assigned
through links... the actual article will reside within the application or
version level most likely. This will all be handled by the Article
submission scripts calling the object scripts with the correct parameters.
I will provide you with the proper syntax for all your object calls.
I know you'll have questions - lets go over them at the next irc meet
(Tuesday).
In addition to everything I've covered above, I will be fully fullfilling
my role as "fearless" leader of the project as Aaron dubbed it ages ago
:). I'll be increasing my availability over the next 2 months to 4 nights
a week for IRC discussions, etc. However you guys need me. I know you'll
have frequent questions moving forward now that everything is in full
swing. My coding time will increase significantly after tomorrow... these
last 2 weeks have been very busy.
Also, in order to get my arms entirely around everything thats going on so
as to better coordinate activities, I'd like to extend the offer of a
one-on-one chat session to each of you managing a project. I know people
are headed in all sorts of directions, but I need a firm understanding of
all of those directions so I can lay the groundwork for you, including any
additional table structures, etc. Things such as the Q&A article entry
system Daniel is working on. These things can progress much faster if I
know about them in detail. I don't want people to feel confined to the
existing table structure and try to work around it. Where modifications
need to be made to support what your trying to impliment I will make them.
I had slated go-live not so long ago for 3rd week of July, and I believe
that if we really ramp up we can have something to show by then. In case
you haven't heard, I have secured the aquisition of an additional server
for the cause which will allow us to spread the delivery/DB load across
the (now) two servers.
So gather up all your questions for our next meeting and think about when
you'll be available to hit it off with me one-on-one. I'll do the
irc-logs for those and ship them off to Aaron or whoever (unless someone
tells me how to post 'em) to be posted. Then I can begine to better
direct the efforts which will be increasingly important as more developers
begin to join.
I have much to discuss on how to handle an increase in developers at the
next meeting as well, so please prepare to discuss your views on that as
well.
Sorry for all the wind... I'll wrap it up for tonight. :)
Jason