Re: Gallery's K3 class name/dir/file conventions (was "Capitalization")

Whew!  I had to read this 2 and a half times.  I think all this discussion
has lead me to some conclusions:

1) We *can* tinker with autoloader and convert some of the duplicated files
into magic.
2) We *should not* do #1.  We should try living with the K3 file
duplication for now
3) We *should* make all classes in the gallery modules overloadable,
*even*ones that are likely to be unsafe to overload like the
installers, etc.
4) We *should try* the simplest approach here, even if it results in more
depth.

I think we've both mostly reversed positions :-)

What would this look like?  Here's a mapping of the tag module:

tag                                        tag
|-- controllers   |-- classes
|   |-- admin_tags.php   |   |-- Controller
|   |-- tag.php   |   |   |-- Admin
|   |-- tag_name.php   |   |   |   `-- Tags.php
|   `-- tags.php   |   |   |-- Tag.php
|-- css   |   |   |-- TagName.php
|   `-- tag.css   |   |   `-- Tags.php
|-- helpers   |   |-- Gallery
|   |-- item_tags_rest.php   |   |   |-- Controller
|   |-- tag.php   |   |   |   |-- Admin
|   |-- tag_block.php   |   |   |   |   `-- Tags.php
|   |-- tag_event.php   |   |   |   |-- Tag.php
|   |-- tag_installer.php   |   |   |   |-- TagName.php
|   |-- tag_item_rest.php   |   |   |   `-- Tags.php
|   |-- tag_items_rest.php   |   |   |-- Model
|   |-- tag_rest.php   |   |   |   `-- Tag.php
|   |-- tag_rss.php   |   |   |-- Tag
|   |-- tag_task.php   |   |   |   |-- Block.php
|   |-- tag_theme.php   |   |   |   |-- Event.php
|   `-- tags_rest.php   |   |   |   |-- Installer.php
|-- models   |   |   |   |-- Rest
|   `-- tag.php   |   |   |   |   |-- Item.php
|-- module.info   |   |   |   |   |-- Items.php
|-- tests   |   |   |   |   `-- Tags.php
|   |-- Tag_Item_Rest_Helper_Test.php   |   |   |   |-- Rest.php
|   |-- Tag_Rest_Helper_Test.php   |   |   |   |-- Rss.php
|   |-- Tag_Test.php   |   |   |   |-- Task.php
|   `-- Tags_Rest_Helper_Test.php   |   |   |   `-- Theme.php
`-- views   |   |   `-- Tag.php
    |-- admin_tags.html.php   |   |-- Model
    |-- tag_block.html.php   |   |   `-- Tag.php
    `-- tag_cloud.html.php   |   |-- Tag
   |   |   |-- Block.php
6 directories, 26 files   |   |   |-- Event.php
   |   |   |-- Installer.php
   |   |   |-- Rest
   |   |   |   |-- Item.php
   |   |   |   |-- Items.php
   |   |   |   `-- Tags.php
   |   |   |-- Rest.php
   |   |   |-- Rss.php
   |   |   |-- Task.php
   |   |   `-- Theme.php
   |   `-- Tag.php
   |-- media
   |   `-- tag.css
   |-- module.info
   |-- tests
   |   |-- Tag_Item_Rest_Test.php
   |   |-- Tag_Rest_Test.php
   |   |-- Tag_Test.php
   |   `-- Tags_Rest_Test.php
   `-- views
       |-- admin
       |   `-- tags.html.php
       `-- tag
           |-- block.html.php
           `-- cloud.html.php

   17 directories, 41 files


Note that I took some liberties with the views and tests.

So what does this mean?

We're adding 11 directories and 15 files to the distribution.. *But* you
can follow the path of inclusions relatively easily *and* it's internally
consistent with the Kohana 3 code we ship *and* it's consistent with where
Kohana 3 is going so pulling from Kohana upstream will be less impactful.

The gallery codebase is going to be larger - but contrib modules don't have
to follow this pattern!  They can extend but not be extensible if they
choose which means that they can write a lot less code if the want.

By being consistent it's easier for us to pull in other 3rd party Kohana
modules (see http://kohana-modules.com/) and use them without modification.

thoughts?

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]