# Behaviors, Page Parts and Extending Radiant **URL:** \ **Category:** Radiant CMS\ **Created:** [June 7, 2006, 4:27pm UTC](https://www.ruby-forum.com/t/behaviors-page-parts-and-extending-radiant/62723 "2006-06-07T16:27:22Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![ol1barn3s](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/9de053/32.png) [@ol1barn3s](https://www.ruby-forum.com/u/ol1barn3s)\ **Post date:** [June 7, 2006, 4:27pm UTC](https://www.ruby-forum.com/t/behaviors-page-parts-and-extending-radiant/62723/1 "2006-06-07T16:27:22Z")
Hi All: This is just an idea and I am not shure to what extent it fits into the no-fluff concept of Radiant. It seems that many people are trying to extend Radiant and in many cases their extensions have nothing to do with pages (i.e. attachments, forms, comments, forums, etc.) or in particular with page parts as they are currently defined. A single arbitrary length string is just not the right data type to store an attachment, a form or a forum and its user interface via a text area clearly does not allow for convenient input. Therefore, I suggest to treat page parts as an abstract data type whose implementation is determined by the behavior selected for a page. Specifically the current PagePart model acts as an interface between the Page model and the actual implementation of the page parts used. Each implementation of a page part defines its own database schema and input forms. The behavior of a page will determine which implementations of page parts can be used for that page, ideally which parts are required and which are optional. That way one can ensure that the content of each page part can be accessed and processed properly. Two examples to illustrate: Attachments: As I mentioned in another thread it might be beneficial to use Radiant’s already existing hierarchical storage stucture to add an attachment to a page as its child instead of changing the page’s model and assume each page could potentially have an attachment. The problem with the current design is, that a child of a page can again only be a page consisting of page parts that just store text. With multiple page part implementations, however, one could just add a “File” page part to the page, that allows uploading a file to the system. The “Attachment” behavior of this page then provides approriate render methods and tags to access the content stored in the “File” page part associated with the page. For those, who do not like to have attachments being stored as separate pages, one could provide a “Page with Attachment” behavior that merges the behavior of a page with that of an attachment and allows for “Text” page parts as well as one or more “File” page parts. Comments: Similar to file attachments as described above, comments are essentially also attachments to a page and can be treated as children of a page. Their structure, however, is somewhat different from “normal” pages and certainly from file attachments in a sense that they have a potentially non-authenticated author, who wants to provide an URL as well as an actual comment text. Therefore a comment page needs to store at least 3 fields: author, URL and text. All of these fields could be defined with the current page parts, however, using arbitrarily long text fields for each field might be overkill and the data model does not enforce consistency. Instead a “Comment” page part implementation can provide a model that stores comments in their own database schema with appropriate data types chosen. The “Comment” page bahavior on the other hand ensures that the page in fact has a “Comment” page part and provides appropriate tags to access the page part’s content. It is clear that this way of providing commenting requires some significant improvements in Radiant’s access and permission control, since it is currently not possible to add comment pages by non-authenticated users. In the future, however, I think those improvements will be necessary nevertheless. The examples forms and forums mentioned above can be implemented similarly to comments. As stated eariler, I am not sure on how this fits into Radiant’s roadmap and I am open for comments and suggestions. I will also try to cobble together an implementation. Cheers, Oliver ---
**Author:** ![ol1barn3s](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/9de053/32.png) [@ol1barn3s](https://www.ruby-forum.com/u/ol1barn3s)\ **Post date:** [June 8, 2006, 12:10am UTC](https://www.ruby-forum.com/t/behaviors-page-parts-and-extending-radiant/62723/2 "2006-06-08T00:10:56Z")
> and I am open for comments and suggestions. I will also try to cobble > together an implementation. 🙂 ---
**Author:** ![ol1barn3s](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/9de053/32.png) [@ol1barn3s](https://www.ruby-forum.com/u/ol1barn3s)\ **Post date:** [June 8, 2006, 3:30am UTC](https://www.ruby-forum.com/t/behaviors-page-parts-and-extending-radiant/62723/3 "2006-06-08T03:30:52Z")
Oliver B. wrote: > implementation is determined by the behavior selected for a page. > Specifically the current PagePart model acts as an interface between the > Page model and the actual implementation of the page parts used. Each > implementation of a page part defines its own database schema and input > forms. The behavior of a page will determine which implementations of page > parts can be used for that page, ideally which parts are required and which > are optional. That way one can ensure that the content of each page part > can be accessed and processed properly. This is a good idea and it has been brought up once before. I hate to shoot it down right now, but it’s not within the current scope of what I’m aiming to do with Radiant. It may be a 2.0 idea, but not 1.0. – John L. [http://wiseheartdesign.com](http://wiseheartdesign.com)