Todo List
Omeka
- Should this storage method be merged into the Plugin Broker class? Probably. That way hooks and filters will be no different in the storage space (in the manner of Wordpress).
- Incorporate pagination into this CRUD method so that all CRUD controllers paginate by default
- Should be able to create derivatives for all image types that ImageMagick can handle, not just the ones that can be read by getimagesize().
- Should tag delimiter (,) be a site-wide setting?
- make it switch between public and admin
- Should use the Zend inflection, though mine works better at the moment [KBK].
- This should encapsulate the entire install script.
- ACL settings should be stored in the database. When ACL settings are properly stored in a normalized database configuration, then this method should populate a new Acl instance with those settings and store that Acl object in a session for quick access.
- The entire install process should eventually be routed through this controller. For the moment, it's enough that this correctly redirects to the install script directory.
- Refactor this so that it subclasses Zend's FlashMessenger action helper (adding message status) and use Zend_Form's form validation instead of the form validation in this class.
- This deserves some testing to see whether or not it should return a true boolean or a string representation (not sure how the database inserts booleans) and whether or not it can be tricked into returning the wrong value under certain circumstances.
- This should be removed and replaced with a better date processing algorithm, especially since we no longer rely on MySQL date fields for storing dates in the Omeka database.
- Separate the Media Adapter code in the plugin broker class into a similar class such as this.
- Modify Omeka_Record to allow Omeka_Record_Module implementations to be added at runtime.
- If possible to use Zend_Form for form generation instead of this class, then this class and Omeka_Validator_Errors will be deprecated in favor of built-in Zend Framework capabilities.
- It may be easier just to generate a long string of random numbers and characters for each new file, rather than actually trying to maintain the old filename, which is still stored in the database. This would only be an issue if the archives directory needs to be human-readable, and there is no guarantee that it does.
- Does this actually need any options, and if so, what are they? An example of one option would be automatically generating the pagination, or automatically assigning to the items to the view object.
- Maybe separate caching here so it's not hiding in a seemingly unassociated method. Though, doing so would require an extra step in the output methods (i.e. <?php $this->_cache($element); ?>).
- What other file metadata should be retrievable? Presumably we shouldn't display the physical path to the filename, but maybe the web path? Do we want to display all the various MIME types we pulled in, or just 'MIME type' and plan to make a definitive one of those?
- Could pass the name of the partial in as an argument rather than hard coding it. That would allow us to use arbitrary partials for purposes such as repackaging the data for RSS/XML or other data formats.
- Come up with a better solution for logging bad queries. Zend_Db_Profiler won't help with logging broken queries, so we need to keep this for the sake of logging those.
Omeka_ThemeHelpers
- Code that generates the http://hostname part of the URI might be better to have as a separate helper function, called by this one.
- Should this look for the next item in the loop, or just via the database?
- Should this take a set of parameters instead of $order? That would be good for limiting the # of tags returned by the query.
- Could pass the name of the partial in as an argument rather than hard coding it. That would allow us to use arbitrary partials for purposes such as repackaging the data for RSS/XML or other data formats.
Documentation generated on Fri, 05 Jun 2009 13:58:07 -0400 by phpDocumentor 1.4.2