Re: K3 update effects on DB

My time has been fragmented lately so I'm afraid that I'm missing out on
some of the context here.  I'll see if I can get this together :-)

On Wed, Apr 3, 2013 at 6:31 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> Ah, gotcha!  Okay, it can be done one of two ways:
>
> 1. Add Hook_SquareThumbsEvent::graphics_crop_to_square(), then add a
> graphics rule for "crop_to_square"
>
> Or, if we take my suggestion and add crop to the
> rotate/resize/composite built-in functions...
>
> 2. Just add a graphics rule for "crop" with the right parameters.
>
> Does that seem reasonable?
>

I think we have to assume that we're not going to come up with all
reasonable graphics options in the core code.  So even if we add "crop" as
a function in the gallery module and wrap it in before/after events, we'll
still encounter modules that want to add their own operations.  So how
would that work?

Your sample code above expects that Graphics::run_graphics_rule would then
call GraphicsOperations::<operation>  so there'd be a GraphicsOperation
class that extends Gallery_GraphicsOperation that would have rotate,
resize, composite and crop functions.  And this would mean that all we have
to put in the database is the name of the operation itself.  So far so good
- but as far as I can tell that doesn't explain how the "foo" module adds a
"frobulate" graphics function.

Some potential solutions:

1) Don't let the "foo" module add a "frobulate" graphics function :-)

2) Use a Hook:
2a) The database has the "foo_frobulate" operation which lets us know to
look in modules/foo/classes/Hooks/FooGraphicsOperation for the "frobulate"
function

2b) The database has FooGraphicsOperation::frobulate which lets us just use
the autoloader directly and simplifies the code a little bit.

3) The database has "frobulate" and we simply run through the
<Module>GraphicsOperation hook in every class until we find one that
handles it and then we depend on the module order

4) The database has "frobulate" and the API is to call
<Module>GraphicsOperation::operation("frobulate", ...) until we find one
that returns true.  Kind of like my original suggestion.


If we remove the module name from the operation in the database then we get
the advantage that you can slip in a new module that overrides the core
functionality.  So for example, the jpegtran module just provides its own
rotate which overrides the gallery module's rotate and now we have lossless
rotation.  If the jpegtran module fails to upgrade or something than it all
silently fails, so that's a little weird - but then again if you
purposefully remove the jpegtran module the cleanup is trivial (it's a
no-op, in fact).

I think I'm leaning towards (2b) for now because it's a smaller change.  We
can always relatively easily revisit this decision before the 3.1 launch
and move over to a hook model.  And if it turns out that nobody is really
going to use any of this functionality because they don't need operations
other than the ones we provide in the GalleryGraphicsOperation class, then
it costs us very little except for a little extra crud in the database
which we can either ignore or delete later.

thoughts?

------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html

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