Re: K3 update effects on DB

Haha to say that this part was planned is.. generous.  It's been mostly
organic growth.  The original plan was to provide a simple abstraction over
common graphics operations, but let modules add their own operations.  So
graphics is supposed to be all the generic stuff about dealing with rules
and toolkits, and gallery_graphics is supposed to be specific graphics
operations.  Having the toolkit code in graphics was useful because modules
don't really care about which specific toolkit they have - they're supposed
to use the Image interface.

So graphics is all rules and toolkits, and gallery_graphics is all
operations that use the abstractions.

Now that I've paged all this back into RAM, really what we're talking about
here is the ability for modules to add new rules.  Putting the name of the
module in the file name (eg "gallery_graphics") allowed us to have a
per-module namespace.  We still want that, and the only model that we have
for that currently is as a Hook.  So even though it's kind of different
than other hooks, it's consistent if you consider it as an extension of the
core framework.  The one major difference is that inside gallery_graphics
we don't dictate the names because we don't know what operations you're
going to want to add.

We could make this more consistent with other hooks by changing the API
here.  Instead of:

  gallery_graphics::rotate($input_file, $output_file, $options, $item=null)
  gallery_graphics::resize($input_file, $output_file, $options, $item=null)
  gallery_graphics::composite($input_file, $output_file, $options,
$item=null)

We could have:

  GalleryGraphics::operation($op, $input_file, $output_file, $options,
$item=null)

where it would be similar to GalleryRss::feed().  You'd have a case
statement inside operation() which would delegate internally.  Each module
would be called in turn for the operation ("resize", "rotate",
"composite").  Return true if the operation is handled, false if not.
 Advantages:

1) It's consistent with our hook structure.  (Note: we probably want to
eventually create actual interfaces for these hooks)
2) Each operation wouldn't be bound to an individual module - ie in the DB
we'd go from "gallery_graphics::resize" to "resize" and then we'd have a
Module::event style which would call the hooks for each module in turn
until one of them handles the operation
3) ... is there a 3?

thoughts?




On Wed, Mar 27, 2013 at 7:34 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> Hey Bharat,
>
> Re: the upgrader, that makes sense.  Should I just add a stanza to
> GalleryInstaller like usual?
>
> Re: gallery_graphics, in my opinion, I'm not sure it still looks like the
> other hook files.  Maybe that was the original intention, but it seems like
> it's developed into something else.  In particular:
> - the three function names don't have any special meaning outside how
> their own module defines them and puts callbacks in graphics_rules
> (watermarks, for example, adds graphics_rules without having its own
> functions)
> - the three functions actually run their own events
> (graphics_rotate, graphics_rotate_completed, etc... 6 in total)
> - other modules can set graphics_rules and do similar things without
> having a similar structure (e.g. my image_optimizer module)
>
> I think we have one of a few options:
> - Leave the class name as-is.  Change the DB and call it a day.
> - Change the class name to something like GalleryImage, since it's
> kinda/sorta the layer between the gallery and image modules.  However,
> that's not entirely the case since all of the toolkit stuff is still in
> Graphics.
> - Move the toolkit stuff out of Graphics and into soon-to-be-renamed
> GalleryGraphics.  This nicely puts all of the image module stuff into one
> class, while leaving all of the graphics_rules and other gallery stuff in
> the other.
> - Move all of GalleryGraphics into Graphics.  This is a bit simpler than
> the option above, but won't give us a nice separation between image and
> gallery modules.  Then again, I'm not sure if we care.
>
> I'm split on which of the two last options I like best... thoughts?
>
> Take care,
> Shad
>
>
> On 27 March 2013 00:40, Bharat Mediratta <[email protected]> wrote:
>
>>
>> I can't think of any places other than the graphics_rules models.  We can
>> cover that in the upgrader code (we'll probably need a slightly more
>> special upgrade process for 3.0 -> 3.1).
>>
>> On the topic of renaming, the point in having gallery_graphics was to
>> make it like gallery_event and gallery_task, so shouldn't it live in
>> classes/Hook/GalleryGraphics ?
>>
>>
>> On Tue, Mar 26, 2013 at 4:06 PM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>>
>>> Hey everyone,
>>>
>>> I took a glance through the Gallery DB, and after my recent changes, it
>>> *looks* like there are no changes required in the DB to make it work with
>>> K3... except one.  In graphics_rules, we have the callbacks to
>>> gallery_graphics::resize stored in there, which need to be changed.  While
>>> I'm at it, I wouldn't mind renaming that helper (having graphics and
>>> gallery_graphics sit next to each other always confused me a little...).
>>>
>>> Can anyone think of other DB changes we'll need to make to accommodate
>>> the K3 upgrade?
>>>
>>> Take care,
>>> Shad
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Own the Future-Intel&reg; 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://p.sf.net/sfu/intel_levelupd2d
>>> __[ 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 ]
>>>
>>
>>
>

------------------------------------------------------------------------------
Own the Future-Intel&reg; 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://p.sf.net/sfu/intel_levelupd2d

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