[Catalyst] RFC and first draft for page regions

[Matthieu Codron]

Hi,

John Napiorkowski a écrit :
> Hi,
> [..]
> package myapp::Controller::pages
> 
> sub page :Local :Regions(toc,content,ad) {}
> 
> sub toc :Local {}
> sub content :Local {}
> sub ad :Local {}
> 
> The plugin override the dispatch  phase to create a
> bunch of hash refs in the stash, with each stash item
> based on the action name:
> 
> $c->stash->{PagesToc};
> $c->stash->{PagesContent};
> $c->stash->{PagesAd};
> 
> Those stash items are available to your view.  Each
> one currently is a ref to a hash that has some
> callback to get the page content.

So far, I think it's a good way of doing it. But maybe the 
Regions(toc,content,ad) annotation should be externalized. The idea 
behind this is to support (later) portal architectures where users are 
able to define themselves page composition.

> $c->stash->{PagesToc}->{link}; #like $c->uri_for on
> the action
> 
> $c->stash->{PagesToc}->{action}; #the action obj.
> 
> $c->stash->{PagesToc}->{response}; # Uses LWP to get
> the url specified by the action. Right now this only
> supports GET.
> 
> So if you use this then in Template toolkit you could:
> 
> [% PagesToc.response.content %]
> 
> and you should drop the region there.

If you are sure to use TT there is a simpler way to do it.
Simply call [% INCLUDE <template associated to the region> %].
The template should of course use the namespace of the region to access 
stash data ( [% PageToc.sections %], [% PageToc.title %], etc. )

The advantage is that you are sure to render the same content through 
initial page composition and through further AJAX calls that refresh the 
region (assuming these are calling the action associated to this region)

Of course if you want to support different view systems that's another 
story but I'm pretty sure you can make it work the same way.

The only catch is if you different views within the *same application* 
for rendering HTML content, which would be somewhat weird.

> This relies on a simple LWP model.  You'll need to
> stick both in your path to get this working.
> 
> Right now this is just using LWP to generate a full
> subrequest, but obviously this is not ideal.  Actually
> I'd like this to be similar to the subrequest plugin
> but it doesn't have to totally isolate the subrequest
> from the requesting context.  I think it would be best
> if the region behaves similar to chaining, where the
> current context in preserved, but should reset the
> context for each region.

Indeed, using LWP to generate full subrequest is not ideal. Maybe there 
is a way to do it using Catalyst::Plugin::SubRequest (I have had some 
trouble using it though).
On the other side, maybe a smart ActionClass could manage to do 
isolation between actions and then you could rely on $c->forward only.

Very interesting stuff ... and lots of work ;-)

Regards,

-- 
Matthieu