[cvs] [Wiki] changed: MichaelRubinsky

[Michael Rubinsky]

mrubinsk  Thu, 20 May 2010 18:11:18 -0400

Modified page: http://wiki.horde.org/MichaelRubinsky
New Revision:  1.28
Change log:  some random notes, organize some ansel 2 todos while I'm  
digging around the code

@@ -4,25 +4,33 @@
  http://theupstairsroom.com

  ++Ansel 2.0 Stuff

-PHP 5-ify ,getters/setters, clean up public,private distinction
+++++TODO:

-Change Ansel_Storage::listImages() to accept a parameter array  
instead of the gallery_id and the WHERE parameter. In addition, .need  
to refactor usage of this method so that client code doesn't have to  
know anything about the SQL table structure. i.e.  get rid of the  
WHERE parameter. All non Ansel_Gallery code should be calling  
Ansel_Gallery::listImages and not Ansel_Stroage list images....which  
leads to:
+* PHP5 native
+* rewrite tagger to use content_tagger
+* use pretty autocompleter for tags / update the image view and  
review placement of tag widget.
+* Use a decorator pattern for the different gallery display modes  
(Date/Normal/?)
+* Use custom binders/factories for the various global objects such as  
ansel_storage, cache etc... use a null cache driver instead of  
checking for the cache existence.
+* Rewrite google maps integration to use horde_map javascript
+* Add a way to easily perform image actions such as downloading from  
the gallery view...something along the lines of either a small  
contextual menu or simply a link on the image tile, also a textual  
link to display the full image view would be very helpful for  
galleries using a lightbox - so the user could see the exif  
data/comments/image actions etc...

-Make Ansel_Storage purely a class that  
Ansel_Image/Ansel_Gallery/Ansel_Tagger etc... use and NEVER client code.
+++++Random notes
+Change Ansel_Storage::listImages() to accept a parameter array  
instead of the gallery_id and the WHERE parameter. In addition, .need  
to refactor usage of this method so that client code doesn't have to  
know anything about the SQL table structure. i.e.  get rid of the  
WHERE parameter. All non Ansel_Gallery code should be calling  
Ansel_Gallery::listImages and not Ansel_Stroage::listImages:

  list* methods should return ids, get* methods should return objects.
-
  Review all ansel js, output all strings in js and consolidate all  
the gallery_view js into a single *.js file.

-Refactor Ansel_Gallery to make it less dependent on the Share  
implementation for when/if Shares changes again.
-
-(Maybe use composition instead of inheritance with the Share object).
+--

  Make it easier to add new !ModeHelper objects.  There should be an  
init function somewhere that returns the available modes that are  
installed.  Normal and Date should be 'built in' and always available  
- maybe parse the contents of a special custom Mode folder?

  Related to above, come up with a detailed idea of what a gallery  
"style" will be...clarify what a "mode" is vs a "style", how to allow  
for (and what to call) special modes (such as a possible "remote  
gallery") that cannot be arbitrarily switched between modes (like the  
current Normal and Date modes can be). Maybe a gallery "type" that is  
specified initially that cannot be changed (Local, Remote, etc...)?  
And, obviously along with all this, finally provide a UI (and backend  
support) to allow the user to define their own gallery styles.  
(Layout, color, thumbnail type etc..).
+
+Maybe use "displayMode" for changing the way images are grouped  
(Date, Location, Normal) etc...then a GalleryType to specify a "local"  
gallery for images (maybe video too) vs "remote" gallery for allowing  
galleries to display remotely hosted images from, say, facebook or  
flickr.
+
+--

  Allow user-specific, global, settings for what Ansel_Widgets are  
visible, allowing them to remove a widget that is defined in the style  
to un-clutter the view.

  Modularize the photo (and maybe gallery) actions so we can easily  
plug in new actions, such as "Send this photo to Flickr" etc...