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/
