File set naming convention, associating galleries and sets with pages.
Permalink 1 user found helpful
I would like to put a whole load of common page content into a stack or global area. One of the blocks in this stack would be a gallery. But I would like the gallery to show a different file set depending on the page the stack is rendered on.
All this is very easy to do by modifying the code of an existing gallery to either pick up a fileset from a page attribute or to name a file set after the page collection ID. (eg collection-2-set, collection-41-set)
That's fine for a one-off solution. However, I think it could be great if all the gallery and slider etc addon developers could agree on a common standard and method for this. That way, any gallery addon add/edit block dialog could be extended to select a pseudo set option 'default page file set'.
By making it a convention we can all benefit from interoperability (in the same way that themes are interchangeable by sticking to page area naming conventions).
This could be either:
(a) Built into file sets - would need core changes/overrides and thus instantly available to any file set based gallery.,
or
(b) A separate gallery source option - no core changes, but requiring changes to any compliant gallery add-on's edit interface.
My initial thought on the matching algorithm priority is:
1. Look for a fileset collection attribute (addonhttp://www.concrete5.org/marketplace/addons/fileset-attribute/)... with the name collection-NN-set.
2. Look for a a numeric or text attribute with the name collection-NN-set,
3. Look for a fileset with the name collection-NN-set.
4. Create a fileset with the name collection-NN-set.
So the purpose of this post.
- What do other developers have to say about this idea?
- What should the matching algorithm/priority be?
- Should it be in the core or each 'compliant' gallery block add/edit interface?
- What should the naming conventions be?
- How would galleries with sortable file sets handle it?
- Would other developers consider making changes to utilise this in future versions of their addons?
- Should the file set matching algorithm be in a library/helper to facilitate block add/edit/controller interface development?
- Does it need to accommodate more than one set-to-page association?
If we got this off the ground, maybe we could have an icon/logo to say "Auto file set compliant" or whatever name we settle on to show off with the addon descriptions.
All this is very easy to do by modifying the code of an existing gallery to either pick up a fileset from a page attribute or to name a file set after the page collection ID. (eg collection-2-set, collection-41-set)
That's fine for a one-off solution. However, I think it could be great if all the gallery and slider etc addon developers could agree on a common standard and method for this. That way, any gallery addon add/edit block dialog could be extended to select a pseudo set option 'default page file set'.
By making it a convention we can all benefit from interoperability (in the same way that themes are interchangeable by sticking to page area naming conventions).
This could be either:
(a) Built into file sets - would need core changes/overrides and thus instantly available to any file set based gallery.,
or
(b) A separate gallery source option - no core changes, but requiring changes to any compliant gallery add-on's edit interface.
My initial thought on the matching algorithm priority is:
1. Look for a fileset collection attribute (addonhttp://www.concrete5.org/marketplace/addons/fileset-attribute/)... with the name collection-NN-set.
2. Look for a a numeric or text attribute with the name collection-NN-set,
3. Look for a fileset with the name collection-NN-set.
4. Create a fileset with the name collection-NN-set.
So the purpose of this post.
- What do other developers have to say about this idea?
- What should the matching algorithm/priority be?
- Should it be in the core or each 'compliant' gallery block add/edit interface?
- What should the naming conventions be?
- How would galleries with sortable file sets handle it?
- Would other developers consider making changes to utilise this in future versions of their addons?
- Should the file set matching algorithm be in a library/helper to facilitate block add/edit/controller interface development?
- Does it need to accommodate more than one set-to-page association?
If we got this off the ground, maybe we could have an icon/logo to say "Auto file set compliant" or whatever name we settle on to show off with the addon descriptions.
On an block by block basis when thinking about individual pages, these ideas offer no advantage whatsoever.
However, with a single level of indirection via a common set name or attribute, it brings a lot of additional flexibility when dealing with similar pages in bulk.
Suppose I want to put a similar set of blocks across 100 pages. It will be the same for 100 pages, so it can be page type defaults, a stack or global area. Except I want to put a gallery into this area. And I want the gallery to show a different file set for each page.
Page type defaults could help set the equivalent up, but offer little help with global maintenance.
With the ideas I am proposing, I can set up the gallery once in the stack, then simply set up a different file set to go with each page. The indirection will then sort it all out.
In the PRB at the moment I have an upload block that streamlines uploading to a named fileset. If I give that the same indirection capabilities and add it to the same stack as the gallery, then I think it can give a massive maintainability boost across these 100 pages and 100 galleries.
A theme developer could have a different gallery for every page, preconfigured in the theme, but showing different sets of images for each page.
While it could be done as a core thing, I currently favour a convention that block developers could build into the block user interface simply because it could happen sooner rather than 12 months time and would be retro-compatible with old versions of C5.
However, with a single level of indirection via a common set name or attribute, it brings a lot of additional flexibility when dealing with similar pages in bulk.
Suppose I want to put a similar set of blocks across 100 pages. It will be the same for 100 pages, so it can be page type defaults, a stack or global area. Except I want to put a gallery into this area. And I want the gallery to show a different file set for each page.
Page type defaults could help set the equivalent up, but offer little help with global maintenance.
With the ideas I am proposing, I can set up the gallery once in the stack, then simply set up a different file set to go with each page. The indirection will then sort it all out.
In the PRB at the moment I have an upload block that streamlines uploading to a named fileset. If I give that the same indirection capabilities and add it to the same stack as the gallery, then I think it can give a massive maintainability boost across these 100 pages and 100 galleries.
A theme developer could have a different gallery for every page, preconfigured in the theme, but showing different sets of images for each page.
While it could be done as a core thing, I currently favour a convention that block developers could build into the block user interface simply because it could happen sooner rather than 12 months time and would be retro-compatible with old versions of C5.
I'm still not seeing the benefit. Sure the block is on 100 pages, but you still need to go and set up the 100 file sets, so you're just moving the work from the block editing dialog to the file manager dialog.
I suppose I could see a situation where a site has so many pages that it would shave off a little time to create and name a file set instead of going to a page, entering edit mode, editing the block, and publishing (although this brings up an interesting point: by working around the page edits as you suggest, you are removing the ability to properly track version histories on pages).
But if editing this many pages is a concern, I feel like it would be more beneficial to put effort into a "bulk page edit" interface that is more generalizable... like it lists rows for each page and each column is a block name (and clicking on the block name brings up its edit dialog).
Or am I still not understanding something?
I suppose I could see a situation where a site has so many pages that it would shave off a little time to create and name a file set instead of going to a page, entering edit mode, editing the block, and publishing (although this brings up an interesting point: by working around the page edits as you suggest, you are removing the ability to properly track version histories on pages).
But if editing this many pages is a concern, I feel like it would be more beneficial to put effort into a "bulk page edit" interface that is more generalizable... like it lists rows for each page and each column is a block name (and clicking on the block name brings up its edit dialog).
Or am I still not understanding something?
You could set up 100 pages and assign them to 100 users who each have access to nothing but the file manager or an uploader. They don't need any block edit capabilities. But they can post to their galleries whenever the want.
Or you could have a site admin and a site picture editor. The admin sets up the pages. The picture editor doesn't need to know anything more than uploading and sorting pictures.
With either of the above, if you then want to change the look of the gallery, the admin only has to edit one global area and everything else stays in line.
You could even swap the galley block globally for another gallery block. And the pictures still stay in line.
Or you could have a site admin and a site picture editor. The admin sets up the pages. The picture editor doesn't need to know anything more than uploading and sorting pictures.
With either of the above, if you then want to change the look of the gallery, the admin only has to edit one global area and everything else stays in line.
You could even swap the galley block globally for another gallery block. And the pictures still stay in line.
Ah, yes I see. That does make sense... but for a very limited use case. I personally am of the opinion that it would be best left to custom blocks, not a standard that all image galleries should adhere to. There is a cost to adding mental baggage to the already under-documented block development arena, and I don't think it's worth the cost for something that doesn't really affect that many people (e.g. I've never heard of this situation before).
All that being said, if I were to hypothetically develop something like this, I'd think just going off of file set naming convention that utilized the page path would be the way to go. Calling FileSet::getByName() will fail gracefully if the set doesn't exist (assuming the calling code checks for a return value from FileSet::getByName). And page paths are better than CID's in my opinion because it's something users can understand more (and have easy copy/paste access to via page properties dialog) -- but they still uniquely identify a page.
All that being said, if I were to hypothetically develop something like this, I'd think just going off of file set naming convention that utilized the page path would be the way to go. Calling FileSet::getByName() will fail gracefully if the set doesn't exist (assuming the calling code checks for a return value from FileSet::getByName). And page paths are better than CID's in my opinion because it's something users can understand more (and have easy copy/paste access to via page properties dialog) -- but they still uniquely identify a page.
I missed the first 10 minutes of Totally Random live yesterday. I have just caught up with it - Franz and Andrew discussed this post.
To summarise, they think it could be useful, but will have to be by consensus amongst developers rather than something led by C5.
EDIT
I solved this and a whole bunch of other adaptive content applications with Magic Data and the family of addons that integrate with it.
http://www.concrete5.org/marketplace/addons/magic-data/...
To summarise, they think it could be useful, but will have to be by consensus amongst developers rather than something led by C5.
EDIT
I solved this and a whole bunch of other adaptive content applications with Magic Data and the family of addons that integrate with it.
http://www.concrete5.org/marketplace/addons/magic-data/...
Very interesting discussion. I am personally on the other side of the fence -- I prefer to put as much into the block editing interface as possible. To me, the biggest benefit of Concrete5 is how straight-forward the editing is. You see some stuff on a page, you click it, you edit it. Time and time again I will be developing a site and start to go down the road of dashboard interfaces, file manager attributes, hard-coded thingies... but I almost always come back to the golden rule: if it can go in a block, it should go in a block. (the only exception to this rule that I sometimes make is using a file set picker instead of individual image pickers... but only because the amount of work involved is *drastically* lessened by leveraging the file manager interface.)
Upon my first reading of what you wrote, I don't see how this provides much benefit beyond just having a block that lets users choose a file set or specific images. The block could be on the page defaults, then when users add a new page, they edit the block to choose different images if needed. I'm wondering how having them choose a page attribute is any less work than clicking "edit" on the default block.
Perhaps I'm not fully understanding your meaning or your intended use case?
-Jordan