# So how did things go this weekend? **URL:** \ **Category:** Radiant CMS\ **Created:** [October 28, 2008, 1:59am UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927 "2008-10-28T01:59:55Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 28, 2008, 1:59am UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/1 "2008-10-28T01:59:55Z")
Is everybody still asleep after the long weekend? I am dying to hear how things went with the sprint. Sean? John? Anyone? ~Nate ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 28, 2008, 2:25am UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/2 "2008-10-28T02:25:39Z")
Thanks for the poke, Nate. Working on a blog post… Sean ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 28, 2008, 5:10am UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/3 "2008-10-28T05:10:01Z")
On Oct 27, 2008, at 8:59 PM, Nate T. wrote: > Is everybody still asleep after the long weekend? I am dying to hear > how > things went with the sprint. Sean? John? Anyone? It was a great weekend Nate. Sean headed up the work on the code and I worked with people who were interested in helping implement the new design. I’ll let Sean tell you more about the work that was begun on code, but I can tell you a little of what was accomplished on the design side. The most visible stuff was integrating the work Chris P. has done on the HTML for the new design. You can see some of the results in the prototype. (There’s a README in the prototype project on GitHub for getting it up and running.) Jim G. spent some time working on rewriting the HTML for the treeview to use a list instead of a table. He didn’t complete it, but some valuable things were learned along the way and we had some good discussions about how the real-estate can be better used on the pages tab. Daniel Beach worked on the HTML for custom page attributes. When this is integrated it will make it easier for people to add custom attributes to pages for configuration and some of the other things that they are using page parts for. You can see some of the results in his fork of the radiant prototype. Justin Blecher did some wireframes that sparked some of the treeview discussions and wrote up some excellent suggestions for improvements to the website and documentation. I pretty much presided over the work being done and talked a lot. 🙂 To me the most valuable part of the weekend was not so much the work that was done, but the relationships that were formed. I am hoping that the groundwork was laid for some exciting contributions from folks in the future. As a side note anyone interested in helping with design stuff on Radiant should check out the radiant-mockups and radiant-prototype projects on GitHub. The mockups project contains a lot of the ideas for the new UI. And the prototype contains the HTML for some of the new things that are being developed. If you are interested in helping, fork the prototype, implement your idea, and tell us about it on the mailing list. If we like it, your changes will be incorporated into the official prototype and will be slated for development for sometime in the future. Also contributions and improvements on the HTML and CSS are welcome! – John ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 28, 2008, 3:48pm UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/4 "2008-10-28T15:48:19Z")
Sean C. said the following on 10/28/2008 12:53 AM: > […]. Many bugs were squashed and edge cases discovered > thanks to them, including an esoteric bug involving an extension that > only gets loaded in test mode. We’ll be reducing the number of > controller unit/functional specs and relying more on integration specs > going forward. And can I just wave a magic GIT commadn and update my installation? ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 28, 2008, 5:53am UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/5 "2008-10-28T05:53:50Z")
Since John passed the ball to me, it’ll probably be easier to write an email first than a blog post. The primary goal I had for this weekend was to make headway on a refactoring of the admin interface toward a conventional RESTful design. These changes will be rolled into the 0.6.10 release to give time for developers to update their extensions before 0.7. Clinton Nixon helped refine the design of the parent controller for all primary resources in the interface and converted a number of the controllers and their specs to the new design. Rick DeNatale showed up midday and paired with me while I was working on refactoring the Page interface, which happens to be the most complicated one. Like a good pairing partner, he kept me honest about writing specs. Adam W. started writing integration specs for the admin interface using his spec\_integration plugin and was joined midday by Mark Imbriaco in a pairing session. Many bugs were squashed and edge cases discovered thanks to them, including an esoteric bug involving an extension that only gets loaded in test mode. We’ll be reducing the number of controller unit/functional specs and relying more on integration specs going forward. Brian Landau worked on creating an extension migration generator and specifications for the other generators. Andrew O’Brien implemented a much needed and obviously missing “to\_slug” method for the String class, among other things. As I mentioned before, I worked on creation of the Admin::ResourceController and conversion of most of the existing controllers to the RESTful design. In the course of this, I was able to contend with the dirty-tracking “feature” of Rails 2.1. The existing models, including Page, should act as expected. You can follow our work in the ‘rest’ branch of the core repository. This branch will be squash-merged once ready for the mainstream. Josh F. – please fill us in on what you and your group did on Saturday; I missed a lot of that. Cheers, Sean ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 29, 2008, 8:07am UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/6 "2008-10-29T08:07:32Z")
> Josh F. – please fill us in on what you and your group did on > Saturday; I missed a lot of that. Andrew O’Brien, Mike Hale, Luke whose last name I am blanking on (apologies), and myself started work on extending the page class to accept arbitrary attributes – booleans, integers, timestamps, &c. This pattern shows up in numerous extensions and we saw a need for a generalized solution. The primary goal was to expose a number of simple object types (single-dimensional data, like the existing metadata fields) and allow these to be managed via a mechanism similar to the page-parts interface. We’re also aiming for a solution that can eventually be extended to accept complex data structures. You can follow our progress at [http://github.com/jfrench/radiant-page-attributes](http://github.com/jfrench/radiant-page-attributes). j ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 28, 2008, 3:54pm UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/7 "2008-10-28T15:54:46Z")
It’s not ready yet, so I wouldn’t recommend it. I’ll let you know when it is! If you want to contribute to the development, feel free to check out the ‘rest’ branch: git clone git://github.com/radiant/radiant.git cd radiant git checkout -b rest --track Sean ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 29, 2008, 10:00am UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/8 "2008-10-29T10:00:03Z")
This is a brilliant idea. I know because I thought of it first ;). In our J2EE application we have a similar concept where any page can have an arbitrary collection of named attributes and we have code that can work with that code. We have a Tag Library that will write out a value of a named attribute, assume the value of the attribute is the path to a JSP and include it, and others that let us do conditional logic (if attribute “Foo” has a value of “bar” do this else do that). All of this, I expect, will make its way into radiant, if it hasn’t already. There is one piece of behaviour that I suspect you haven’t implemented, but which turns out to be VERY useful. Right now, page parts are inheritable if the usage of the part says so, which is to say that the Radius tag has an attribute called inherit. In our application, we did it the other way. When I author a page, I get to say whether or not a attribute is inherited or not (and it defaults to inherited). This allows us to set values for a whole section easily (sparse population of data). It works out the same as it currently does with the parts in radiant with one exception. If I set a “masthead\_image” attribute on page /products/widgets to “widgets.gif” then every page in /products/widgets gets that value, this is the same. However, I want the “masthead\_image” attribute for /products/ widgets/legal to have a value of “pirate.gif” but it only applies to that one page and /products/widgets/legal/privacy should have a value of “widgets.gif”. In our system, we simply flag the attribute on / products/widgets/legal as being “local” and it only applies to that one page, its descendants get their value from its parent. With the current logic, I would have to go in and set the attribute on each child page and if this is something I need for my visual design, a content author is not likely to know to set the attribute unless I tell them but on any sufficiently complex project that will be difficult to maintain. Adam ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 29, 2008, 1:48pm UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/9 "2008-10-29T13:48:50Z")
On 28-Oct-08, at 12:06 PM, Tim G. wrote: > > attribute, assume the value of the attribute is the path to a JSP and > > DB schema > > has an > > “masthead\_image” attribute on page /products/widgets to > > “local” and it only applies to that one page, its descendants get > > Six one way, half a dozen the other. I think that Radiant’s current > behavior > is the more widely expected default behavior. It’s easy enough to set > inherit=“true” when needed, and I don’t think there’s much benefit to > switching it around. The benefit is being able to sparsely populate data. Where the content author is the person doing the technical admin, its not an issue. but if you have many non-technical authors (a good reason for using a CMS) then sparsely (only where you want things to change) is very beneficial. ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 29, 2008, 1:14pm UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/10 "2008-10-29T13:14:48Z")
On Tue, Oct 28, 2008 at 11:57 AM, Adam van den Hoven \< removed\_email\_address@domain.invalid\> wrote: > This is a brilliant idea. I know because I thought of it first ;). In our > J2EE application we have a similar concept where any page can have an > arbitrary collection of named attributes and we have code that can work with > that code. We have a Tag Library that will write out a value of a named > attribute, assume the value of the attribute is the path to a JSP and > include it, and others that let us do conditional logic (if attribute “Foo” > has a value of “bar” do this else do that). All of this, I expect, will make > its way into radiant, if it hasn’t already. I agree that the single-dimensional data idea is a great one. Not only is it fantastically scalable, it’s also a step toward a fully normalized DB schema (I’m not a fan of tacking on columns willy-nilly, leaving most of them NULL). It also makes migrations easier in both directions (up and down). > I want the “masthead\_image” attribute for /products/widgets/legal to have a > value of “pirate.gif” but it only applies to that one page and > /products/widgets/legal/privacy should have a value of “widgets.gif”. In > our system, we simply flag the attribute on /products/widgets/legal as being > “local” and it only applies to that one page, its descendants get their > value from its parent. With the current logic, I would have to go in and set > the attribute on each child page and if this is something I need for my > visual design, a content author is not likely to know to set the attribute > unless I tell them but on any sufficiently complex project that will be > difficult to maintain. Six one way, half a dozen the other. I think that Radiant’s current behavior is the more widely expected default behavior. It’s easy enough to set inherit=“true” when needed, and I don’t think there’s much benefit to switching it around. – Tim ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [October 29, 2008, 3:05pm UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/11 "2008-10-29T15:05:52Z")
On Tue, Oct 28, 2008 at 3:46 PM, Adam van den Hoven \< removed\_email\_address@domain.invalid\> wrote: > The benefit is being able to sparsely populate data. Where the content > author is the person doing the technical admin, its not an issue. but if you > have many non-technical authors (a good reason for using a CMS) then > sparsely (only where you want things to change) is very beneficial. I agree that sparsely populating data is a benefit of the inheritance of page parts (and other things which may be inherited). But the current method of specifying inherit=“true” in the Radius tag enjoys this benefit, and making inheritance the default (so that local=“true” is used for Radius tags which should not be inherited) doesn’t add anything. Your example of the widgets image (a “page variable”) being set for /products/widgets and being inherited by /products/widgets/legal/privacy, and then setting that same page variable to a pirate image just for /products/widgets/legal, I think is made moot by the paperclipped and page\_attachments extensions. I’m having a hard time thinking of any other use case where your suggestion would be easier than just \. Page attributes like created\_at, updated\_at, title, meta\_description, meta\_keywords, etc., all seem like things that should \*not - be inherited by default. Perhaps you’re just pointing out the ideal behavior already present in extensions like the mailer extension, that makes available extension-specific tags available which make sense to be inherited by default. In one Radiant site, I’ve placed all of the configuration necessary for a mailer form on the Home page (page parts mailer, email\_plain, email\_html). Then I have the following: email\_form snippet: ``` … ``` sidebar page part of Home page: ``` ``` In my layout: ``` ``` The mailer extension automatically inherits the configuration page parts to the rendering page, and everything works nicely. I think this behavior is extremely useful on a per-extension basis, but I’m not sure it has a place in core. ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [November 4, 2008, 1:42pm UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/12 "2008-11-04T13:42:14Z")
On Tue, Oct 28, 2008 at 5:53 AM, Sean C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > The primary goal I had for this weekend was to make headway on a > refactoring of the admin interface toward a conventional RESTful design. > These changes will be rolled into the 0.6.10 release to give time for > developers to update their extensions before 0.7. Hi, I was wondering what items are still remaining left for a 0.6.10 release (i.e. is it the list at [Lighthouse - Beautifully Simple Issue Tracking](http://radiant.lighthouseapp.com/projects/11883-radiant/milestones/current?)) I’m about to setup a new radiantcms based project and was wondering what would be my best ‘starting’ point. Should I stick with the 0.6.9 release for now? Best regards, Jeroen J. ---
**Author:** ![nateless](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/96bed5/32.png) [@nateless](https://www.ruby-forum.com/u/nateless)\ **Post date:** [November 4, 2008, 3:00pm UTC](https://www.ruby-forum.com/t/so-how-did-things-go-this-weekend/151927/13 "2008-11-04T15:00:56Z")
Jeroen, You should be fine running on edge – that is the “master” branch of Radiant. In fact, there are a few feature enhancements and bugfixes that are good to have from “master”. The majority of the work for 0.6.10 is being done in the “rest” branch. Sean