Re: [Radiant] So how did things go this weekend?
Josh French -- 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. j ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] So how did things go this weekend?
Sean Cribbs 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? -- This isn't life in the fast lane, it's life in the oncoming traffic. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] So how did things go this weekend?
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 On 28-Oct-08, at 7:04 AM, Josh French wrote: Josh French -- 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. j ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] So how did things go this weekend?
On Tue, Oct 28, 2008 at 3:46 PM, Adam van den Hoven [EMAIL PROTECTED] 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 r:var name=foo inherit=true /. 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: r:mailer:form name=contact … /r:mailer:form sidebar page part of Home page: r:snippet name=email_form / In my layout: r:content part=sidebar inherit=true / 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. -- Tim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] So how did things go this weekend?
Thanks for the poke, Nate. Working on a blog post... Sean Nate Turnage wrote: Is everybody still asleep after the long weekend? I am dying to hear how things went with the sprint. Sean? John? Anyone? ~Nate ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] So how did things go this weekend?
On Oct 27, 2008, at 8:59 PM, Nate Turnage 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 Parrish 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 Gay 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 ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] So how did things go this weekend?
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 Williams 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 French -- please fill us in on what you and your group did on Saturday; I missed a lot of that. Cheers, Sean ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
