History of FisheryPackage

Version 2


Combination of features from fisheye and treasury galleries

Created by: Anonymous, Last modification: 19 Jul 2008 (05:38 UTC) by Lester Caine
This documentation will need to be 'de-politicized' once all the problem areas have been formalized, but currently it is partly a sounding board for suggestions.
(Thanks to kinderlehrer for the box (:biggrin:) )

Having found problems with TreasuryPackage working on MultisitesPackage, some of the difficulties of ring fencing content have come to the front again. TreasuryPackage has a problem with it's gallery display which is reliant on LibertyPackage. This does not allow for filtering of content, and so all galleries from all sites are displayed rather than the reduced set that relate to a single site, and more important those galleries that a user has permission to access via protector or a similar security service. FisheyePackage still has some problems but it does at least only display a sub set of galleries when required.
Obviously these problems need fixing, but since other facilities are also required, a short term solution has been to combine some of the features of both rolled into a new package - fishery.

Outline of requirements

fisheye has already been extended to provide a list view in addition to the three grid views, and so one of the requirements had already been covered, but further options to the layout would be useful. These are probably just variations on the two bases of list or grid, and even list is just a single column grid.

Top level index

One of the niggles with fisheye is it's based on a single user default for the top level. This is ACTUALLY correct even for multisites, but the option to change views would be useful, such as 'all' and 'group'. One of the problems with even that simple statement is deciding what to use as a group, since multisites has it's own means of filtering content, as does protector and other filters are possible because of the core design of bitweaver.
People will be aware that I prefer a 'flat' identification system, so that having a reference ID one can go on to identify what type of content is involved, and I have come back to user_id and group_id as another area that needs a little tidy up - from MY point of view. And even multisite comes into that equation. From a management point of view, every group needs an administrator, and so for every group I create a group_admin user, and each group lines up with a multisite entrypoint. Although there can and would be more than one group in a site - however registered and editor groups will still be used to determine capability. These are a little at odds with 'grouping' content and should perhaps be viewed as ROLES instead?
index page will default to group which is actually the group_admin user but will have options for 'all'-showing all visible galleries and 'user'-to show all galleries the user has created, but in multisite these would be sub-galleries of each group the user is a member of
How users can access data from other groups/multisites still needs to be sorted. It may be that the multisite filter is enabled if a user is required to log onto a different site to see their content in that site.
Ideally the top level index will simply be another gallery view rather than having it's own code, since the gallery can be displayed as a list now.

Gallery View

This follows on from the last statement, but it may be that we have different filters displayed if the 'default' gallery is displayed as against a selected gallery. This may come out in the wash anyway, since an important filter in the gallery view is one for content type. This would be populated with a list of just the content types available in the directory, but in line with the 'flat' view, mime based content will provide additional types for the mime types available. An obvious tidy up of this will be to provide an 'image' selection as well as ( or perhaps instead of ) 'image/jpg' etc. It would also be nice to have the same grouping perhaps for 'drawing' and 'document' so that 'drawing/dxf' or 'document/odt' and the like but that is just a matter of correctly identifying or extending mime types.
Currently implemented is the ability to select the style of display for a gallery, along with the additional layout features as required, and this can be extended to provide additional features.

Content View

At the base level this should already be implemented in LibertyContent, with additional facilities provided by LibertyMime, so there should be no need to discuss it here - except ...
The gallery navigation bar is an optional facility that can be added to content, and it is intended that this will be displayed if provided in the url. So a default content url will take the format /?content_id=627&gallery_path=/3/4 although the actual path should not need to be specified. &gallery_path=0 would cause it to be calculated from the content_id.
In much the same way that gallery layout can be selected on a gallery by gallery basis, content can either be displayed using the default mime layout, or additional 'plugin' type layouts. This layout control will also apply to content entries displayed IN the gallery.

Gallery Content Management

While I do have a dislike of content being located in multiple galleries, I do not see any problem with the concept, and in fact potentially there COULD be a gallery zero which would simply access all content_id entries - the 'list all content' - so that potentially 'raw' content would only be deletable at that level. (See later note ).
What I do not like is the current fisheye way of selecting which gallery(ies) to use when editing an item. The separate tab for treasury is a bit tidier, but as has been indicated, that does not respect multisites/protector and the like. So the plan is to keep the tab as an option, and fix the display list, but also provide a 'located' function to allow a different gallery to be selected if required. This 'located' would be provided as an edit service, so that ANY content item can be located in a gallery. This is almost an alternative to protector, and highlights the problem of having multiple tables for some of these facilities. multisite_content, liberty_content_group_map and fishery_content_map are all doing similar jobs different ways, and the operation could be tidied into one central table - except when one adds multiple usage of content. But it is the MANAGING of that multiple usage across multiple sites or groups that focuses the various problems.

Ring fencing content

The starting point is deciding HOW to model the management of content. And we all have different views on that, and different solutions. But there are a few basic rules that we can all agree. If we are using a single database that it has to be simply because at some point we need access to all content. If that is not he case, then use separate databases for each site.

To be expanded - Basic premise is that ANY content item will be handled and can be added to a gallery, not just fishery attachments.
Page History
19 Jul 2008 (11:16 UTC)
Lester Caine81.138.11.1365
Current • Source
Lester Caine81.138.11.1364
View • Compare • Difference • Source
Lester Caine81.138.11.1363
View • Compare • Difference • Source
Lester Caine81.138.11.1362
View • Compare • Difference • Source
Lester Caine81.138.11.1361
View • Compare • Difference • Source