rubyonrailsin

On Apr 1, 2010, at 1:29 PM, Josh French wrote:
> There are legitimate use cases for inheritance, but I agree it would be useful to have a remove_all() method or to allow the existing remove() to accept any number of arguments. The latter is cheap, but at the very least you could do any of the following:
>
> remove 'body', 'extended'
> remove superclass.parts.map &:name
> remove Radiant::Config['defaults.page.parts'].split(", ")
>
> (If it wasn't clear in the docs, the base factory gets its parts from Radiant::Config.)

I agree, inheritance is good in some cases, but not in others. The above code looks simple enough.

> But your suggestion implies a larger, unanswered question about the relationship between factories and page classes, and how fixed that relationship should be. I'd prefer to simply identify the hooks you'd need to build that extra layer, and expose them while keeping the base implementation as open as possible. What if I did something like this in the popup:
>
> options_for_select(factories_for(@page))
>
> ...where factories_for() simply returns all factory classes by default? Then you're free override that method. You can limit the allowed factories by @page.page_factory, or @page.class, or ignore @page altogether and base it the current user's role... much more flexible, and it doesn't require others to commit to tying factories to any particular entity.

I had not thought about role restrictions. Sounds good, but what about 2 extensions that try to override that helper method in different ways?
I'd be inclined to have the page answer back with it's available factories (which would be all of them by default) and perhaps add the current_user as an argument (which could be ignored by default) so that other page types could use it.
By doing something like factories_for(@page.factories(current_user)) one could override the #factories method on Page and check for any attribute (such as url, slug, or some added custom field). Then different extensions could do some alias_method trickery to play nice with each other.

I haven't used this, so that's a big grain of salt. But I would think I'd be using this 1) freely with no restriction on selecting the template, 2) based upon the URL where you want certain types of content in a section of your site, or 3) based upon the page type. Perhaps there's a 4th option to check the page's factory, but I don't have the experience with it to think that through right now.
Having worked with a couple of solutions for this problem, how have you typically used this?

PageFactory is perfect for RSS feeds. I've been wanting to create an interface for end users for building feeds but this would certainly get things further along without the need for detailed UI work.

Jim Gay
http://www.saturnflyer.com

--
Radiant CMS Dev Mailing List
Post: radiantcms-dev@googlegroups.com
Unsubscribe: radiantcms-dev-unsubscribe@googlegroups.com
Group Site: http://groups.google.com/group/radiantcms-dev/

To unsubscribe, reply using "remove me" as the subject.