rubyonrailsin

> Rather than using "remove 'extended'" I think something like
> "clear_parts" to remove all parts would be nice since you'll have no
> way of knowing exactly what parts need to be removed from the standard
> new page. Or perhaps it should clear all parts by default but provide
> an "inherit_standard_parts" method to do the opposite.

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.)

> Defining a "parent_page_class" or "parent_factory" might be nice to
> allow the interface to adjust to the content. If I make a factory that
> should create pages under an Archive page, it would make sense for the
> UI to restrict me from putting it anywhere else by removing it from
> the list of factories. The parent_page_class could be Page by default,
> but you could set it to ArchivePage (or Archive) in your factory
> class.
> ...
> And while I'm dreaming... providing a locked way to create a child
> page for any given page class would be nice. So in the above scenario
> I could click to add a new ArchivePage which would automatically
> create the day/month/year archives as well as force the add child
> button to only create 1 type of page so that a user wouldn't have to
> select the "Blog" factory every time a new child page is added.

I think these are two implementations of the same pattern: specifying
that certain factory classes can only be created below other
factories. In your second example, that's just limiting it to one
class instead of several. (And then being smart about not showing the
list when only one option is available.)

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.

> It seems to me that loading PageFactory classes ought to be done from
> the Rails.root lib directory or something like that as well. If all
> one wants to do is add some factory class, then creating an extension
> seems excessive (since we require a certain structure).

Agreed.

Thanks for all your feedback, it's much appreciated!

j

--
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.