What does GalleryModule::performFactoryRegistrations() do?
|
ehughes
Joined: 2005-09-15
Posts: 4 |
Posted: Fri, 2005-09-16 04:28
|
|
The title says it all. What does performFactoryRegistrations() do? Why is it necessary? When should I use it? |
|
Posts: 40
Heaps of things from what I have seen, I'm still unsure of what exactly and wouldn't mind finding out everything it can do.
What have I used it for:
//modules/MyModule/module.inc function performFactoryRegistrations() { $myMimeArray = array('image/jpeg', 'image/pjpeg'); //here i register my own custom file type $ret = GalleryCoreApi::registerFactoryImplementation( 'GalleryItem', 'MyPhotoItem', 'MyPhotoItem', 'modules/MyModule/classes/MyPhotoItem.class', 'MyItem', $myMimeArray); if ($ret->isError()) { return $ret->wrap(__FILE__, __LINE__); } //Here i added a section under "edit photo" $ret = GalleryCoreApi::registerFactoryImplementation( 'ItemEditPlugin', 'EditMyPhotoItem', 'EditMyPhotoItem', 'modules/MyModule/EditMyPhotoItem.inc', 'MyModule', $myMimeArray); if ($ret->isError()) { return $ret->wrap(__FILE__, __LINE__); } }and it appears you can do lots of other things here too
-add stuff to admin panes
-add new menu choices
-the list goes on, where I don't know
the first argument to registerFactoryImplementation seems to be where everything happens
Posts: 32509
i couldn't find good links, but we're using a programming pattern called "factory" or software factories.
http://en.wikipedia.org/wiki/Factory_object
so with registerFactoryImplementation you tell G2 that there is an implementation of GalleryItem which is made for a special purpose. e.g. for specific mime types.
when you add a new item to g2 by uploading, g2 first detects the mime type of the item and then it creates a new GalleryItem for this mime type.
so it looks in its list of GalleryItem implementations for a specialized implementation for this mime type. if it finds a match, it returns it. else it returns an instance of the GalleryUnkownItem.
this is very elegant.
we can do something like
$newEntity = GalleryCoreApi::newFactoryInstanceByMimeType($mimeType); and g2 does all the magic (look up in database tables if there's a GalleryItem for this mime type, else return a new instance of GalleryUnknownItem).
the above code won't work, it's just illustrative.
the same goes for the ItemEditOptions etc. you register a new option. for the itemEdit page, g2 then looks in the db which options it should display for the current image. and the deciding factor is the mime types in this case.
not all factory registrations have to do with mime types.
e.g. you can register a URL generator. G2 generates all URLs with a single class, the GalleryUrlGenerator.class.
but you can override it with any url generator.
just register your own url generator class.
when g2 starts handling a request, it intiates all its core functionality etc. in init.inc. there it also asks the factory for a UrlGenerator implementation. and this implementation is then used to generator all urls.
the rewrite module (short urls) registers its RewriteUrlGenerator.class or a newly coralize module generates its url generator to generate urls that point to a global distribution network.
factories are very powerful if properly used and bharat did it certainly right in G2
Posts: 56
Hi, I've been studying about factories, really powerfull stuff. I now understand about adding new GalleryItem but I'm not too sure about the ItemEditOptions and the other examples you mention.
I have the idea that a factory should create a product (an object) and in G2 I think the most visible objects are GalleryItems (albums, photos and other types of files you could manage), however when I start thinking about other not so "tangible" objects like urls, item options, etc, I get a little confused.
Could you please let me know which modules or source files I should review and analyze to better understand this?
Regards!
Alexis Bellido - Ventanazul web solutions
Posts: 32509
the g2 core module is a basic platform and the core of an extensible framework. we're using the factory not only to extend the item types G2 can handle but also to add features / options in various places.
e.g. a module can add new ways to edit an item or a new method to add an item. all registered methods to add / edit items are listed in the "add items" and "edit photo" / "edit album" pages.
basically it works like this:
modules/core/ItemEdit.inc asks the factory to return all registered ItemEdit options/plugins and then it lists them as tabs on the ItemEdit page. if a user then uses one of these item edit options / plugins, the ItemEdit controller again loads the specific Itemedit option/plugin from the factory and dispatches the request to the registered option/plugin.
another example:
all URLs in are generated by the GalleryUrlGenerator. when initializing the core services of G2, we're first checking if any module registered a replacement for the standard GalleryUrlGenerator by asking the factory to return a UrlGenerator. if no object is returned, we're falling back to our good old standard GalleryUrlGenerator. if the factory finds something relevant, we're using the url generator returned by the factory instead.
that's the way the url rewrite module is working. it registers its RewriteUrlGenerator as a UrlGenerator in the factory and we get this RewriteUrlGenerator returned by the factory and thus we're using it.
this happens in init.inc function GalleryInitFirstPass()
another use:
API interfaces. say your module works as is, but it can offer extended features if the exif module is also installed because you can use some exif attributes for your module. to have a real example: the maps module - which shows the user a google map of where your albums / images have been takes - needs to know the GPS coordinate of your images. and the GPS coordinates are in the exif data of images. so the maps module needs to check if the exif module is installed, active and then it needs to retrieve data from the exif module.
this is solved by registering the Exif interface in the exif module. it's an interface to common functions of the exif module.
the maps module then asks the factory to return an exif interface. if it gets an object returned, it uses the exif interface object to fetch the GPS coordinates with a simple function call. if there's no exif interface object returned, the maps module must ask the user to manualy enter the GPS coordinates.
you can use the factory for a lot of purposes. all you need is a place where you query the factory for something and then other modules can extend / add functionality by registering something of the type that is asked for.