K3 next steps / brain dump

Hey gang,

Now that I've wrapped up the big rename/move/search/replace task for all
the modules, I'm trying to put together my thoughts and figure out what I
should attack next.  I thought maybe putting my brain dump here might be
useful, so enjoy :-).  Any and all thoughts/critiques welcome.

My overall strategy: put the tasks that are required before gallery can run
at all first.  This makes debugging the others much easier.

I've loosely "assigned" them to Bharat or myself below, mostly based on
what I think each of us has already started.  I'm sure the list is
incomplete, but it's a starting point.  Also, I'm not sure I know the
status of Bharat's stuff, so his stuff might or might not already be done...

Shad's todo before gallery can run:
- Module class/file rename/move/search/replace task (done, but probably
needs cleanups as we move along)
- Theme class/file rename/move/search/replace task (see related email chain)
- Make some Gallery-specific module-name-to-class-name translation
functions (see below)
- K2->K3 replacement: expires (should be easy)
- K2->K3 replacement: Input (see below)

Bharat's todo before gallery can run:
- K2->K3 replacement: ORM and ORM_MPTT
- K2->K3 replacement: Database
- K2->K3 replacement: Cache
- bootstrap.php and index.php (note: I did the class name search'n'replace
thing here)
- Routing

Shad's todo after gallery is (at least barely) running:
- K2->K3 replacement: Forge -> Formo (*much* easier to do this after
gallery is running)
- Make unified Hook API
- K2->K3 replacement: Image
- Change GalleryGraphics stuff (see related email chain)
- Make URL use SERVER_NAME instead of HTTP_HOST

Yet-to-be-assigned todo after gallery is (at least barely) running:
- K2->K3 replacement: Pagination (see below)
- K2->K3 replacement: transliterate and purifier (still referenced in core
code)
- K2->K3 replacement: unit_test (replaced by php_unit?)
- Revise gallery_unit_test and unit test classes

------------

Module-name-to-class-name translation functions

We need a pair of functions that go back and forth between names_like_this
and NamesLikeThis.  This is used both to translate between module names and
their classes (parsing urls, finding module hooks) as well as between model
names and their table names (ORM).  At first, I thought that K3's built-in
Inflector::camelize() and Inflector::decamelize() were a good match, but am
no longer entirely sure.

Inflector::camelize($str) gives:
- gallery --> gallery
- server_add --> serverAdd
- g2_import --> g2Import
- g2_import_event --> g2ImportEvent
- html5_example --> html5Example

This is fixed with ucfirst(Inflector::camelize($str)), but it's kinda ugly
and inefficient (see Kohana_Inflector::camelize()).  So, I extended
Inflector to add a $ucfirst argument.  Now, Inflector::camelize($str, true)
makes NamesLikeThis.  Default is false to keep it like Kohana intended.

Inflector::camelize($str, true) gives:
- gallery --> Gallery
- server_add --> ServerAdd
- g2_import --> G2Import
- g2_import_event --> G2ImportEvent
- html5_example --> Html5Example

Okay, so that mostly works.  Now, the other direction.

Inflector::decamelize($str) gives:
- FooBar --> foo_bar
- G2Import --> g2import
- G2ImportEvent --> g2import_event
- Html5Example --> html5example

The problem is that decamelize looks for [a-z][A-Z], which doesn't work
with numbers.  One approach is to just do an extension like I did before
(e.g. a new $num_sensitivity argument that changes it to [a-z0-9][A-Z]).
 That said, this is starting to make we wonder if extending the built-in
functions is really a good approach and if we wouldn't be better served
with two purpose-built functions instead.  Thoughts?

------------------------

Pagination

This library was originally in Kohana 2.x, but left after 2.3, so we put it
in kohana23_compat for 2.4.  Similarly, it was originally in Kohana 3.x but
left after 3.1.  Some folks forked the module and made it compatible with
3.2 (https://github.com/kloopko/kohana-pagination), and others forked that
to make it work with 3.3 (https://github.com/webking/kohana-pagination).
 Does it seem like pulling this in as another module is a reasonable idea?

BTW, this is the only thing left in the kohana23_compat module...

-----------------------

Input

This library is gone with K3.  Instead, they recommend working with $_GET,
$_POST, and $_SERVER directly.  Handling unset and default values can be
handled using Arr as:
Arr::get($_POST, "foo", "default foo");

This part is pretty straightforward.  The only catch is that they need
cleaning first.

It was recommended to use Security::xss_clean() with K3.0, but that's since
disappeared.  I'm looking for the best alternative, which shouldn't be too
hard to find, but think the bigger question is this: *where* do we do this
so nobody downstream has to think about it?
- bootstrap?
- an extension of Route?
- an extension of Controller?
- somewhere else?

---------------

Thoughts?

Thanks for listening to my ramblings!

Take care,
Shad

------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2

__[ 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 ]