rubyonrailsin

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

OK, now I see the use case. In this instance, it really is the Page
class that cares about what factories are available. The general
problem though is that you've got an extension which needs to modify
factory selection, and will be delegating that responsibility to a
specific model.

Let's use your example and add extension that scopes factories by
role. That doesn't involve the page at all, but both extensions are
just filtering the list of factories by arbitrary criteria. The
general solution would just be a chainable filter:

def factories
[PageFactory, *PageFactory.descendants]
end

def factories_with_singleton
factories_without_singleton.reject { |f|
@page.page_factory.singleton_exists?(f) }
end
alias_method_chain :factories, :singleton

def factories_with_roles
factories_without_roles.select { |f| (f.roles &
current_user.roles).any? }
end
alias_method_chain :factories, :roles

> If it's only in ActionView where this can be done then the ability to
> do things like this is more restricted

If the above method is available to the controller/view, then it
already has access to the @page instance and current user, plus
anything else I can find in the current request.

On the other hand, Page#factories(current_user=nil) implies there's
only one dimension you can filter on. It makes it harder for
extensions which might want to filter by something we haven't thought
of yet.

> On a side note, another thing I realized is that there should be some
> description for the available templates.

This would be nice. Do we have an existing UI pattern for a modal
containing a table instead of a select element?

j

On Apr 2, 2010, at 1:49 PM, Jim Gay wrote:

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

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