rubyonrailsin

On Fri, Apr 2, 2010 at 11:04 AM, Josh French <josh@digitalpulp.com> wrote:
>> Then different extensions could do some alias_method trickery to play nice
>> with each other.
>
> Postscript: I think this is the point we're circling. I had not really
> thought through how other extensions might use the more forward-facing
> features. In my mind, Page Factory is mostly plumbing. You might share some
> factories between projects, but the rules governing who can do what with
> them, and where, are usually pretty tailored to the application. So if
> that's the part I expect to rewrite every time, I want it isolated.
>
> But it sounds like you're anticipating a different use case, in which
> multiple extensions are providing and modifying access to factories. Can you
> describe a scenario in which you'd expect to use Page Factory like that?
> (It's great that people are thinking of ways to use this to solve problems
> that look nothing like mine!)
>

Yeah. I think we're talking about the same thing too. I just think it
might be easier to use a method on the Page model and its descendants.

This is how I imagined it:

The Page model would have

def factories
:all # or something
end

Then an extension that I create to manage newsletters, for example,
could have a NewsletterIndexPage and NewsletterIssuePage with a bunch
of custom radius tags.

In the NewsletterIndexPage model, I would do

def factories
['NewsletterIssueFactory'] # or something like this
end

Then when I clicked on a NewsletterIndexPage to add a child, it would
add a child of the given type (if there is only one type) or if there
are more than one option then it would give me the options to select
from the list of available factories.

Or if you used a current_user:

def factories(current_user=nil)
if current_user && current_user.admin?
super # or some other defined list
else
['NewsletterIssueFactory'] # or maybe [:newsletter_issue] if you
swing that way
end
end

So I would still make the default setup in PageFactory (the extension)
return all and allow the overrides to be done by any new Page classes.
Or some client-specific extension could override Page#factories, or
alias it to do their own url checking scheme or do other client
pleasing things.

If it's only in ActionView where this can be done then the ability to
do things like this is more restricted (or am I wrong about that?).

But more to the point, the Radiant UI really shouldn't allow you to
add 2 ArchiveMonthlyIndexPage pages but it currently does. If creating
new pages was done with PageFactory, then you could have the
ArchivePage#factories method check to see if it had a child of
ArchiveMonthlyIndexPage already and remove that from the list of
available templates.

But I think this really polishes up the use of Radius. It's one thing
to have a tag reference in the UI, but it's entirely better to provide
a safe way to create the radius content without worrying if you're
doing it right. I see PageFactory as a way that any extension which
adds a new subclass of Page ought to provide a sample setup.

On a side note, another thing I realized is that there should be some
description for the available templates. A select list is simple
enough, but if there were a slightly different list which gave a
description from the factory class, it would reduce the training
needed to understand when to use what factory. So your instead of your
list having "Revenge" it would have "Revenge: a template to make a
list of all the people who wouldn't let you borrow their pencil
sharpeners in grade school"

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