From: Alec M. <al...@al...> - 2009-05-25 17:49:02
|
>>I like Alec's idea of being able to wipe out data without doing any of the above, especially for, say, the comment module Just to point out that wiping all comment data (as part of a bulk management interface) is a nice feature, but orthogonal to wiping all module data (as if reinstalled). Only in special cases (maybe the comment module is one of them) there's no config data other than that which a module's own interface can "bulk-manage". It's a minor point, maybe, but it's not a natural feature for a module to provide a "delete my config and data", and if I was having problems with a module I'd be more likely to trust such a feature if it were provided by the core than if it were part of the module itself. To expand on the trust issue - suppose I was having difficulties, and I used the module-provided "nuke my config" option, but that didn't help any. I'd still end up looking for a way to remove the module's data from outside the module itself. (Of course if that didn't work, I'd turn to phpMySQL, but it would be nice if there was an in-framework method.) I guess that would be done either with a "wipe" button, or an uninstall-reinstall cycle (like G2) - but either way, I'd like it to be available to the admin user. ----- Original Message ----- From: "Jake Conner" <ja...@st...> To: "Bharat Mediratta" <bh...@me...> Cc: "Alec Myers" <al...@al...>; <gal...@li...> Sent: Monday, May 25, 2009 6:27 PM Subject: Re: [Gallery-devel] Gallery3 problem with upgrades and plugin states My opinion on all of this, from a UI standpoint, pretty well matches Bharat's: one installs a module, which creates the tables, one can then deactivate and activate it at will without losing data - the words "activate" and "deactivate" are intuitively non-permanent. One can also uninstall, which wipes out all data and should maybe have the option of wiping out the plugin itself - intuitively a more permanent word. I like Alec's idea of being able to wipe out data without doing any of the above, especially for, say, the comment module - but since the utility of this feature is somewhat module-dependent, perhaps it should be up to the module to provide it. That way, modules could provide the database manipulation functions most appropriate to themselves - for instance, maybe we'd finally get a bulk comment management interface! Jake On May 25, 2009, at 12:03 AM, Bharat Mediratta wrote: > Alec Myers wrote: >> That sounds very good. How does the administrator get to call >> uninstall()? >> (Case: "I've really b*lls*d up my installation of >> VeryComplexModule, I want >> to start over.") > > I haven't got that far yet. We could do it like G2 and have an > uninstall button next to each module, but I never really liked that in > G2 because it clutters up the modules page. Perhaps Chad and Jakob > have > some ideas here? > >> >> >> ----- Original Message ----- >> From: "Bharat Mediratta" <bh...@me...> >> To: "Alec Myers" <al...@al...> >> Cc: <gal...@li...> >> Sent: Sunday, May 24, 2009 7:56 PM >> Subject: Re: [Gallery-devel] Gallery3 problem with upgrades and >> plugin >> states >> >> >> Alec Myers wrote: >>> I do like the idea of purging a module being decoupled from having >>> the >>> code >>> active though - it would be nice to be able to reset a module to >>> zero (zap >>> all comments etc) -with appropriate warnings, naturally - from the >>> UI, >>> without having to deactivate/uninstall/reinstall/reactive. >> >> (stream of consciousness type response as I go through the code, with >> some conclusions at the end) >> >> I've been going through the various modules to understand the >> implications of trying to get this right. The states that I think >> are >> necessary are: >> >> Uninstalled: >> - the module does not exist in the database and is not available >> to the rest of the code. >> >> Installed: but inactive: >> - the module exists in the database >> - the module code (hooks, theme callbacks, etc) are NOT ACTIVE >> - database tables MAY be out of date (ie: it may require an >> upgrade before you can activate it). >> >> Installed and active: >> - the module exists and is up to date in the database >> - the module code (hooks, theme callbacks, etc) are ACTIVE >> >> >> With those states, let's consider a few modules: >> >> Watermark module: >> - deactivate and then reactivate it, you should not have to >> rebuild all of your thumbnails/resizes >> - uninstall it and all your watermarks should go away >> >> Tag module: >> - deactivate then reactivate should leave your tag data unchanged >> - uninstall it and all your tags should go away >> >> Recaptcha module: >> - deactivate then reactivate should preserve your settings >> >> >> Open issues/thoughts: >> 1) Deactivated modules won't have up-to-date data. Scenario: we >> apply >> tags to a photo, then deactivate the tag module, then delete the >> photo, >> then reactivate the tag module. Upon reactivation, the tag module >> needs >> to make sure that its data is clean. This applies to any module that >> has data related to items. The exif and search modules have >> maintenance >> tasks to take care of this scenario so they're covered, but comments, >> tags, and notification don't. >> >> CONCLUSIONS >> >> Having thought about this a bit I think that we need to give >> modules the >> ability to separate activation from installation. So I'm thinking >> that >> we'll extend the installer API to have activate() and deactivate() >> calls. Invariants that the framework enforces: >> >> * We always call install() before activate() >> * We always call deactivate() before calling uninstall() >> * Modules which are not activated are not accessible in the code >> >> The admin UI can remain exactly the same. It'd work like this: >> >> * If you check the box next to a module (ie, you're saying "I want to >> use this module") then we call install() followed by activate(). >> * If you uncheck the box next to a module ("I don't want to use >> this") >> then we call deactivate() BUT WE DON'T CALL UNINSTALL(). >> >> I'm going to let this simmer in my head for a bit before I take >> another >> shot at coding it. >> >> >> > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity > professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like > Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > __[ 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 ] |