# Very preliminary image patch

**URL:** <https://www.ruby-forum.com/t/very-preliminary-image-patch/64214>\
**Category:** Radiant CMS\
**Created:** [June 23, 2006, 3:58am UTC](https://www.ruby-forum.com/t/very-preliminary-image-patch/64214 "2006-06-23T03:58:54Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\
**Post date:** [June 23, 2006, 3:58am UTC](https://www.ruby-forum.com/t/very-preliminary-image-patch/64214/1 "2006-06-23T03:58:54Z")

</div>

Here’s the results of a a very rough implementation of images and also  
towards allowing different types of pages to have their own input  
interface:

[http://soxbox.no-ip.org/images.patch](http://soxbox.no-ip.org/images.patch)

Should be able to just apply that and run a rake migrate. Don’t do it to  
an environment you care about in any way shape or form.

There’s a big chunk of fairly fundamental restructuring of things, but  
I’m more interested in feedback on the way the interface has been  
implemented (it’s unstyled, just how it flows is important).

Basically, I’ve added a new page at the “add child” point that gives a  
list of the available page types. Currently there are three page types:

- Generic Page - this is the same as the current add page screen
- Binary Data - allows you to upload images/files
- Redirect

There’s also new tags available to a page:  
\<r:attribute\>, \<r:if\_attribute\>, \<r:unless\_attribute\> - these are  
equivalent to \<r:url\>, \<r:if\_url\> and \<r:unless\_url\>, except they can  
apply to any attribute of a page (title, slug, etc) - this allows new  
assets to expose new attributes without having to code up new tags.

\<r:image\> - creates an img tag for an image with alt and title  
attributes, use it like so:

\<r:children:each type=“image”\>  
\<r:child\>\<r:image\>\</r:child\>  
\</r:children:each\>

Each of these ‘asset types’ has their own entry screen. New asset types  
with new behaviours and model associations can be added quite easily.

The introduction of the “add child” page adds an extra step to the data  
entry process, but I don’t really see a way around that - any ideas on  
how to make that process better are very welcome.

Also, changing a page from one asset type to another is basically  
impossible - this will have an impact because I’m planning on  
re-organising things so that behaviours are rolled into the asset types.  
Is this actually a problem? Do people imagine a world in which you’ll  
change a page from being one behaviour to another? Can you give me an  
example of such a change?

I’ll be re-implementing this more cleanly with more unit tests soon, and  
will be doing so in my own svn repository so you can get a better view  
of the individual changes being made here, but the patch above should be  
enough to give feedback on the functionality.

Daniel.