Tomcat - The main reason I recommended 3.2.3 is simplicity on the part of
linux. To move to 4.0 will require significant effort on my part which may
not result in a more useful platform (for the project, that is). The
problem is that 4.0 comes only as source and RPM, not Debian packages. To
build the source requires a later version of java than the standard Debian
package. Getting THAT to run requires getting libstdc++ libraries working
at the right version,... and on it goes. A lot of companies customize
things for Redhat these days instead of linux in general. The important
question is (and I can't answer is), will we need to make use of the newer
API features? If so, I have no problem with biting the bullet and getting it
all going. If not, I'd rather devote my time to coding as opposed to
installing right now. Though I'm surprised I'm saying this, it's
unfortunate that the setup isn't as convenient as Windows (ie. download and
go).
Foundation classes -
> >>WikiPage - Encapsulates one page, however that is represented, and
will
> >>be passed around from the database, parser, HTML generator, etc...
> So the responsibility of this class is to get encapsulate the a page.
> Would it be responsible in setting it's own state or would its state be
> set by another entity?
WikiPage objects will have both open an restricted aspects. The data will
be changeable by the public, but fields like ID and such will be managed
either at construction or by authorized parties (ie a database). This class
will lean very much toward the data side of the spectrum. It is almost like
a struct, a but a few methods will probably be involved to keep track of
things like versions, last update time, etc. I was more interested in
wrapping up a String so we have something more flexible to pass around until
we know exactly what we want.
> >>WikiContext - This would be a singleton which would contain common
> >>configuration information. Users typically call getInstance() on it,
and
> >>then use that object to learn about the environment, policies/setting,
and
> >>get references to other objects.
>
> Which objects interarct with this one?
>
Everyone who wants to know global information. ie. there will be one WikiDB
for the
system, and WikiContext would be the class to give it to you. Any class
that needs to write or read pages will
probably need this. I would think that future semaphoric concerns might
involve
this class too.
> >>WikiDB - Abstracts the database functions. One would probably call
> >>getLocalDB() on a WikiContext object to get a reference, and then this
> >>class would handle page creation/deletion/retrieval/update. I would
expect
> >>that most of the functions would be passing WikiPage references. The
guts
> >>of this class would then attach to a production DB, text file interface,
> >>etc.
> >>
> So, this is the class responsible in managing the connections to the
> page repository? Who would call the getLocalDB()?
>
Yes. Again the Browse, Edit, Preview classes (many others, probably) would
need a reference
to the main DB interface.
Debbie and I got the basics of those three classes written today. We'll
finish the comments and
check things into CVS within a couple of days. As we have it now, anyone
can get a reference
to the database which will let them create, retrieve, and update simple
WikiPage objects by name.
The underlying storage scheme, as implemented by WikiDB, is probably
temporary (it's not portable,
that's for sure), but all of that mess is well out of sight from the users.
Regards,
Jim
|
