# Buckets, Page Types **URL:** \ **Category:** Radiant CMS\ **Created:** [February 25, 2007, 12:39am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721 "2007-02-25T00:39:44Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 25, 2007, 12:39am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/1 "2007-02-25T00:39:44Z")
I’ve been watching Radiant for the past few months. I think it’s a spectacular piece of software with respect to the simplistic but functional UI. Although I haven’t contributed anything to the project, I thought I would chime in with my $0.02. I have a project in mind for Radiant – using it in the grade-school education field. I know my audience pretty well. I thought their perspective might help frame your discussions about “images per page or per bucket” and selecting page content type. Teachers / secretaries would … frankly … be totally dissatisfied with the idea of having to add a picture to a bucket before using it on a site. The arguments for DRY are valid. I embrace the concept of DRY. My Ruby-based project at work has gained much from the tenants of the Ruby language, and this one in particular. More than once we’ve come to a major fork in the development process, and the word “DRY” has made the decision for us. With that said, there’s a point where you can be too DRY. If you’re using a “yes or no” set of radio buttons in two places on the site, that doesn’t mean you should create a helper for it. Just put the code twice. It’s going to be OK. The ACM / Radiant mailing list / Bill Gates / Larry Page will not excommunicate you. Similarly, if someone uses a photo twice and I have to store it twice (or, intelligently, compare it’s signature to all existing objects and notice that it’s the same… but not ask the user anything about it… ) well then that seems fine, especially if it improves the user experience. No user wants to hear about DRY. Users like another Ruby tenant… “it does what you would expect.” They expect that if they’re editing a page, they can add an image from that page. (Of course, they also expect WYSIWYG, and that the image will be automatically resized and appear in the editor…) One thing they wouldn’t necessarily expect, but would be thrilled to have access to, is a “clipart” section… your “bucket” … where they or anyone else could add “common” images. So I think perusing both would be excellent Also, on the “different pages” idea… the “New Page → Select Page Type → Display specific editor” is exactly what I had in mind. Radio buttons and next. Specifically, here are the page types I currently plan to use: - Regular Page - Grouping Page ( Very similar to a regular page, but its purpose is to hold a group of similar objects, like “Meeting Minutes” or “Elementary Schools” - and actually I haven’t figured out in my head whether this is actually necessary or just an extra layer I can drop.) - Site ( templates will be on a “site” level for me instead of on a page level… also, main menus and users will be on a site level.) - Photo Gallery ( I was looking at Tableau [Koalan & Surikaten](http://creativi.st/gallery) ) - Calendar (Google API? Who knows…) - Attachment (PDF, Word, Excel, etc.) - Link (OK this isn’t a page but it will make main menus work nicely.) So, if this helps direct your thoughts toward something useful, great. If not, click “delete.” 🙂 jw > I’m in total agreement on needing to have different interfaces for > different page types - but I would see the flow of page creation being: > > New Page → Select Page Type → Display specific editor > > Rather than have a selection of editors available directly on a page. * * * ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 25, 2007, 1:14am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/2 "2007-02-25T01:14:09Z")
I am in TOTAL agreement with your feelings here. In fact the only “disagreement” I would make is more of semantics and, if I understand you correctly, we actually agree. First, on many sites assets (especially images) have a 1:1 relationship with pages – they aren’t reused. So if the user wants to think of the asset as “living” on that page, great. When assets get reused, or like you mentioned, one user creates/uploads pictures/clipart and another user writes the content that uses it. then the user obviously is going to think of the asset living somewhere else and being “attached.” In my mind, I wouldn’t make a big deal about the “bucket” – at least not to the user. “So, you want to add a picture? Browse your computer (to pick and upload to the bucket and automatically attach) or browse the site (to pick from the bucket and attach).” So when you say: > Teachers / secretaries would … frankly … be totally > dissatisfied with the idea of having to add a picture to > a bucket before using it on a site. I agree. The use case is “add image from my computer” or “add image already on the site.” The bucket/public folder/repository is just the technical solution. By the way, I will mention this one more time. Many of the asset management solutions sound only page centric. In the asset reuse situation or where one user uploads pics for everyone to use, it would be good to be able to confirm where or if each asset is used. That way it is possible to actually “manage the assets.” ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 25, 2007, 1:58am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/3 "2007-02-25T01:58:45Z")
As to your page types, I was kind of surprised to see your “grouping page.” I plan to develop an extension shortly for a project that might line up with your grouping. I’ll share it here in case it actually is a more generally usable concept than I thought. I apologize in advance for all the lead-in… I have a website that is collecting stats on various cities in the region. Since these stats may be used on multiple pages and the data changes from year to year, I plan on sticking them in the db and calling them from custom tags within static pages. For example: \Cities (index page) \City A (static content plus stats from db) \Map (static content plus map built from db) \Chart (static content plus charts from db) \City B (static content plus stats from db) \Map (static content plus map built from db) \Chart (static content plus charts from db) … Essentially I’m grouping cities together here. I’m planning to make an extension to set the property for each city page based on choices within the db (i.e city=“City A”). It’s children would inherit this property. Now, I obviously need to build my own tags/extend radiant for each of the dynamic pieces (stats, maps, and charts). That way, in the chart page I could just insert \. Why be this fancy? I have multiple categories (cities, counties, school districts, etc.) – all of which can overlap in weird ways. Now I’m wondering if it’s actually a unique need. I’d be happy to develop a public extension if I thought anyone other than me would use it. Any takers? ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 25, 2007, 11:51pm UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/4 "2007-02-25T23:51:23Z")
> No user wants to hear about DRY. Users like another Ruby tenant… > “it does what you would expect.” They expect that if they’re editing > a page, they can add an image from that page. (Of course, they also > expect WYSIWYG, and that the image will be automatically resized and > appear in the editor…) For another usecase showing why I want (well, need) images attached to pages, have a look at [http://www.thegroggysquirrel.com](http://www.thegroggysquirrel.com) - You’ll see on the front page and image linked to each article - I can do that just from grabbing the first image associated with that page (which in many cases isn’t actually displayed in that page, it’s just that it’s been attached). The same thing can be seen at [http://www.thegroggysquirrel.com/comics](http://www.thegroggysquirrel.com/comics) - the page at /comics doesn’t need to know anything other than the fact that it has some child pages and it can happily pull down the images associated with each of the pages and render them. This could probably be achieved instead by choosing one image from the list of images for rendering (in fact, I provide an option on the page to select an image to be associated if there are multiple images), but it’s been much more straightforward for the (not so computer savvy) editors to simply upload their article, upload an associated image at the same time and be done with it. Especially when I’ve currently got 826 attachments that would be living in that bucket to choose from - giant buckets don’t scale. Dan. ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 26, 2007, 12:08am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/5 "2007-02-26T00:08:23Z")
> Especially when I’ve currently got > 826 attachments that would be living in that bucket to choose from - > giant buckets don’t scale. I think they call those ‘vats’. Now the question becomes, do you need an asset bucket, an asset vat, or an asset tanker! Sean p.s. yes this post is tongue-in-cheek ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 26, 2007, 12:19am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/6 "2007-02-26T00:19:24Z")
You need to download Mephsito and try out their system: they have many (not all) of these problems worked out. The Assets page lets you search through everything with tags, titles or asset type, then drag a small selection to a bucket. The bucket shows up when editing a page, where you can attach it. It is very slick. You can also upload an image while editing a page, directly into the bucket. I think this covers most people worries, and gives you a central place to edit, caption and tag the images/assets. But this has been an interesting conversation and it is good to hear so many ideas about this issue. ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 25, 2007, 7:07pm UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/7 "2007-02-25T19:07:29Z")
On Feb 24, 2007, at 7:14 PM, Chris P. wrote: > By the way, I will mention this one more time. Many of the asset > management solutions sound only page centric. In the asset reuse > situation or where one user uploads pics for everyone to use, it would > be good to be able to confirm where or if each asset is used. That > way > it is possible to actually “manage the assets.” I think of Basecamp’s Messages (and other places where you can attach files). I don’t think about it twice: if I have a file I want to attach, I attach it. If I want to see what files there are, I go to Files. If I want to reference a file in another place, I get the url of the file and reference it. It’s a simple matter of programming… adam williams (aiwilliams) ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 26, 2007, 1:04am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/8 "2007-02-26T01:04:27Z")
There are two Web-based tools I use frequently that illustrate this dichotomy. On the one hand I have my blog, which uses Typo. Assets are ‘global’. Having uploaded an image I can use it anywhere. By contrast I use TWiki for document management. Here the attachments are associated with a specific page (“topic”). This makes sense in context because it is a content management system and the access controls for each page and project (“web”) need to apply. A document has, of necessity, a :1 association with a page. If Radiant were a Wiki I’d encourage the restriction to the binding of the asset to a page. But a CMS, used as a blog or as a management system for a business or,as I use it, for a club,the images MAY want to be reused in various contexts. Having that ability will not stop them being used in just-one-place. But restricting availability will limit what Radiant can be used for. For example, it I were using Radiant for a product site I might want the image of the box product on the front page as well as the product comparison page and the purchase page. Having to upload multiple copies of the same image would be both wasteful and annoying. Chris P. said the following on 02/24/2007 07:14 PM: > I agree. The use case is “add image from my computer” or “add image > already on the site.” The bucket/public folder/repository is just the > technical solution. > > By the way, I will mention this one more time. Many of the asset > management solutions sound only page centric. In the asset reuse > situation or where one user uploads pics for everyone to use, it would > be good to be able to confirm where or if each asset is used. That way > it is possible to actually “manage the assets.” – The improvement of our way of life is more important than the spreading of it. If we make it satisfactory enough, it will spread automatically. If we do not, no strength of arms can permanently oppose it. - Charles A. Lindbergh ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 26, 2007, 1:27am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/9 "2007-02-26T01:27:28Z")
> For example, it I were using Radiant for a product site I > might want the > image of the box product on the front page as well as the > product comparison > page and the purchase page. Having to upload multiple copies > of the same > image would be both wasteful and annoying. Using an image on multiple pages does not necessitate the uploading of that image on each of those pages. Using my part\_attachments extension, on your main page and comparison pages you could have: \ \ \ \ \ \ The image is linked to the product page, and when other pages want to talk about that product, they can delegate the image lookups to that other page. If the images were in a giant bucket, the above would need to be something like: \ \ \ \ Speaking of DRY… I think I just repeated myself. Now, imagine that instead of being a find for a specific product, what you were looking for was a list of top ten products, or ten most recently added products or some other grouping: \ \ \ \ Radiant provides a great mechanism for structured data - everything IS in a global bucket that you can reference from any other page - that bucket is providing a structure. Dan. ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 26, 2007, 1:33am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/10 "2007-02-26T01:33:29Z")
> Radiant provides a great mechanism for structured data - everything IS > in a global bucket that you can reference from any other page - that > bucket is providing a structure. Further on that, my part\_attachments extension already lets you reference assets globally: \ or \ There would be nothing stopping you from taking my asset management code and extending it with a second extension to change the interface to see things as a bucket and hide the page ownership. Dan. ---
**Author:** ![mustmodify](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/c89c15/32.png) [@mustmodify](https://www.ruby-forum.com/u/mustmodify)\ **Post date:** [February 26, 2007, 3:54am UTC](https://www.ruby-forum.com/t/buckets-page-types/86721/11 "2007-02-26T03:54:09Z")
Dan, thanks for your posts. You’ve given me the best example of a user’s need for the asset to be seen as part of a page instead of in the radiant vat™ (kudos to Sean). To me this issue has nothing to do with where the asset is stored but rather the interface and how simple and intuitive it is to the user. In your case Dan, it is obvious that the user (you) needs a particular image and that the image’s address is based on its use elsewhere. In the case where an one user uploads 100 clip art images for other users to use in their pages, the location (in the user’s mind, anyway) is not related to where this image might already be used. In fact it would be bad if both writer A and B use the same picture (B by reference to A’s work) and then A went and changed theirs. Similarly, in my case I upload a stock photo for use and, 100 pages later, I write another piece that could also use it. I don’t remember which page I put it on before and it would be “wrong” to describe the picture as “belonging” to another page. So I’d just use \. In either case, I don’t really care WHERE the picture sits – just that the user can ask for it using the correct “address” (how they think about or need it). Both addressing methods are clearly needed. Like you said, it is all interface. Your extension could be extended to add a vat™ view with organization, browsing, etc. A vat™ based asset manager could allow for tags that reference the asset as such-and-such-image-on-page-x. Oh, and one other great point, Dan… A vat™ with too many items is hard to manage. It needs to be organizable (I implied a folder structure in my tag above but, of course, there are other ways). After all, the vat™ can hold assets long before they are used in a live work. Finally, I’ll repeat my other concern. Regardless of implementation, there is a valid need to track which pages use asset-x – not just which assets are used in page-x. This issue is the one that may dictate implementation (a central vat™ might make this easier).