Directory structure

[Andrew da Silva]

Related issues: #72 and #112.

When working with Code Igniter, I liked how the different class types
had their own folder.

What is the general consensus on having the follow structure for our /
system/classes:

/classes/handlers - All of our handlers (action, atom, feedback, etc)
/classes/methods - All of our objects (post, posts, logentry,
comments, etc)

Now we could have /helpers for the utils and format class, but what
about the others like controller or the xmlrpc libraries... I don't
know..

It just seems the /classes is getting more and more cluttered?

[Scott Merrill]

Andrew da Silva wrote:
> What is the general consensus on having the follow structure for our /
> system/classes:
>
> /classes/handlers - All of our handlers (action, atom, feedback, etc)
> /classes/methods - All of our objects (post, posts, logentry,
> comments, etc)

At first blush, I'm against this notion, though I admit I can't
adequately explain why.

> It just seems the /classes is getting more and more cluttered?

I guess I don't see it as too big of a deal. We currently have 71 class
files, so it's not so many as to cause multiple pages of output in an
`ls` display. Most (all?) of them are sanely named, so it's not too
hard to find the class or method you're looking for.

But some logical organization to the files isn't necessarily a bad
thing, either. So I guess at the end of the day I'm +0.

--
GPG 9CFA4B35 | ski...@skippy.net | http://skippy.net/

[Michael Bishop]

Not really being a coder, I can understand how as time goes by, the
addition of more classes and files might muddy the directory, but I
don't really know how many more might come. What are the
ramifications to changing the structure? My other question to this
is, how does having all of the classes well documented balance to the
amount of files? Meaning, since it is well documented, how much
wading really does one have to go through to find functions, etc?

~miklb

[Owen Winkler]

On Nov 7, 2007 6:17 PM, Michael Bishop <miklb....@gmail.com> wrote:
>
> Not really being a coder, I can understand how as time goes by, the
> addition of more classes and files might muddy the directory, but I
> don't really know how many more might come. What are the
> ramifications to changing the structure? My other question to this
> is, how does having all of the classes well documented balance to the
> amount of files? Meaning, since it is well documented, how much
> wading really does one have to go through to find functions, etc?

These are interesting questions.

One thing that Habari does not suffer from is being unable to find the
file related to the specific functionality you are searching for.
Everything is very clearly named. If you can't find it, you just
don't know what part of the program you're supposed to be looking in,
and more "organized" directories will just send you looking in
multiple directories for a file you don't already know the name of.
(Is that a "handler" or what is it?)

That said, if we wanted more directories, it's trivial to use them.
The trick is that with multiple directories comes the possibility for
multiple files with the same name, but in different directories.
Habari searches for filenames by the name of the class that the file
will contain. So in the end, only one of multiple files would be the
one used.

This behavior is used to facilitate the user directory override. By
loading the names of all of the files in the system directory into an
array, and then loading the names of all of the files in the user
directory into that same array, the locations of the user files
overwrite those of the system files. If we did that with multiple
cascading directories, the ones with names later in the alphabet (or
is it natural order?) would get priority. We would still be able to
have user override system, not because of alphabet order, but because
we explicitly load one after the other.

I am not inclined toward creating multiple directories, not just
because of the strange potential consequences of loading multiple
directories' identical filenames, but primarily because in my opinion
adding directories only adds clarity for people who already know what
they're doing -- and if you already know what you're doing, what's the
difference? ;)

Owen

[Christopher Davis]

One thing that I think should be highlighted here is that Owen said:

"If you can't find it, you just don't know what part of the program
you're supposed to be looking in, and more "organized" directories
will just send you looking in multiple directories for a file you
don't already know the name of. (Is that a "handler" or what is it?)"

This is the real issue I think. Having a clear list matching up
function to class would be the most helpful I think. And make it
human parse-able please:

Where does Habari:

Process comments once they are submitted? feedbackhandler.php in
system/classes

Retrieve Posts for display? posts.php in system/classes/

And so on. That make some type of sense.

Chris

[Andrew da Silva]

Just to conclude this discussion, we don't want to create
subdirectories in /classes?

[Christopher Davis]

I am not expressly against it, but I am also not gung ho for it. I
can see the merit of both points of view. So lets say I am +0 on this
one.

Chris