Is everybody still asleep after the long weekend? I am dying to hear how
things went with the sprint. Sean? John? Anyone?
~Nate
Thanks for the poke, Nate. Working on a blog post…
Sean
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
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?
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
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.
j
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
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 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 getSix 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.
On Tue, Oct 28, 2008 at 11:57 AM, Adam van den Hoven <
[email protected]> 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
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.
On Tue, Oct 28, 2008 at 5:53 AM, Sean C. [email protected]
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)
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.
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