gotcha. The only part I had to put in Root.pm was the
__PACKAGE__->config( ... ), which is logical.
I found a lot of templates under root/base ... including 'xhtml' which
at some point calls
[% INCLUDE header;
window.render_viewport(self.inner); %]
which I guess then runs down the various objects that were added with
$self->push_viewport(ViewPort, 'blah') in the controllers.
These templates have lots of apparently widget-orientated stuff ... is
this library code or app code used to generate the crud stuff? how do
I set up where it lives in my app?
On 1/2/07, Matt S Trout <[EMAIL PROTECTED]> wrote:
On 2 Jan 2007, at 20:10, Daniel McBrearty wrote:
> OK. It is a good idea to make sure everything in the view goes through
> the I18N code, for sure. I'd like to merge what we are doing there
> with the cat plugin, but tat can wait ...
>
> next questions, about the Root.pm of the example app ... :
>
> 1.
>
> use base 'Reaction::UI::RootController';
> use Reaction::Class;
> use aliased 'Reaction::UI::ViewPort';
>
> do these HAVE to be in Root.pm?
>
> I just want to use this stuff in my admin code at the moment ... say
> it all sits in under MyApp::Controller::Admin ... can I just put these
> there?
They need to be in an appropriate namespace to supply begin and end
actions. If all your reaction controllers are under ::Admin:: then
that's fine - that's usually where we start when doing conversions
(or where we stop when writing hybrids :)
> 2.
>
> __PACKAGE__->config(
> view_name => 'XHTML',
> window_title => 'Reaction Test App',
> namespace => '',
> );
>
> sub base :Chained('/') :PathPart('') :CaptureArgs(0) {
> my ($self, $c) = @_;
> $self->push_viewport(ViewPort, layout => 'xhtml');
> }
>
> I'm just not getting this bit. WHy do I want your XHTML view (it
> happens that I use xhtml anyway ... ) but what's it all about?
You need to be using a view that inherits from
Reaction::UI::Renderer::XHTML; it does a few bits and pieces above
and beyond the standard TT view that are required for everything to
work, and will likely soon to rather more above and beyond as layout
classes get added to help extract even more logic out of the templates.
> 3. the root action is using a viewport, pushing the template name onto
> it ... what does a viewport actually do over, say, a standard TT
> template?
A viewport is nothing like a template - a viewport object provides a
viewport onto a particularly model display or mutation and
encapsulates all the logic required for handling events from the user
and altering the data visible to the view/layout stuff appropriately.
In this case the viewport doesn't actually provide any data in and of
itself - it's there as a placeholder for the xhtml document layout to
hang off. The ListView and ActionForm viewports are probably more
educational in terms of the point of such objects.
--
Matt S Trout, Technical Director, Shadowcat Systems Ltd.
Offering custom development, consultancy and support contracts for
Catalyst,
DBIx::Class and BAST. Contact mst (at) shadowcatsystems.co.uk for
details.
+ Help us build a better perl ORM: http://dbix-
class.shadowcatsystems.co.uk/ +
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
--
Daniel McBrearty
email : danielmcbrearty at gmail.com
www.engoi.com : the multi - language vocab trainer
BTW : 0873928131
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
