From 753f8f1d3d3d5a7efc2cb8416f6b7f09b3a722a0 Mon Sep 17 00:00:00 2001 From: mateu Date: Tue, 11 Aug 2009 14:35:33 +0000 Subject: extending Reaction core skins and call_next POD additions. --- lib/Reaction/Manual/Tutorial.pod | 33 ++++++++++++++++++++++++++++++--- 1 file changed, 30 insertions(+), 3 deletions(-) (limited to 'lib/Reaction') diff --git a/lib/Reaction/Manual/Tutorial.pod b/lib/Reaction/Manual/Tutorial.pod index ca0fdc3..46a49c1 100644 --- a/lib/Reaction/Manual/Tutorial.pod +++ b/lib/Reaction/Manual/Tutorial.pod @@ -142,7 +142,23 @@ a relative name like and it would try to extend a skin named C in your own application's C directory. -Now we create C to allow settings that concern all skins of +In general, the Reaction distribution provides two skin choices to build upon: +C and C. C is Reaction's most basic skin +while the C skin extends the base by embellishing the layouts with more XHTML. +The default skin is designed to be a working skin. + +In other words, if you want to write most of the low-level XHTML yourself +then put the following in your skin.conf: + + extends /Reaction/base + +If you want to use more XHTML out of the box, then configure your application to extend +the default skin. + +It's worth noting that you are not bound to the XHTML of the default or base skin layouts, +because you are able to override layout fragments in your own skin. + +Next we create C to allow settings that concern all skins of the application. It should contain only this: widget_search_path MyApp::View::Site::Widget @@ -195,8 +211,19 @@ containing the common C for all pages using this site layout. The C<[% inn where the deeper parts of the stack will be included, in the case of our C action that would be the C with the C layout. -If we wanted to override a specific fragment, we could do just that. And inside that fragment -we could call C<[% call_next %]> to include the layout fragment from the extended layout. +If we want to override a specific fragment, we can do just that. There are two choices +when overriding a specific fragment. One can disregard the parent fragment all together +and start from scratch or they could reuse the parent fragment and add to it. The key to +re-using a parent (extended) layout fragment is the keyword C. Specifically, +we insert C<[% call_next %]> to include the layout fragment of the parent. + +The parent layout fragment is found either in another layout template named in the +C<=extends> directive or it's in a subclass of Reaction::UI::Widget. +In the latter case, the Widget subclass name matches the name of the template or +the widget name posed at the top of the layout file via the C<=widget> directive. + +Once you know the hierarchy C follows, then you know where to examine +the details of the parent layouts or widgets. The layout representing the root action is called C: -- cgit v1.2.3-54-g00ecf From 1b45efc103b064840771676901e2a12606d50df9 Mon Sep 17 00:00:00 2001 From: mateu Date: Tue, 11 Aug 2009 15:10:28 +0000 Subject: add missing word to Widgets.pod --- lib/Reaction/Manual/Widgets.pod | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'lib/Reaction') diff --git a/lib/Reaction/Manual/Widgets.pod b/lib/Reaction/Manual/Widgets.pod index 3e20427..3553391 100644 --- a/lib/Reaction/Manual/Widgets.pod +++ b/lib/Reaction/Manual/Widgets.pod @@ -48,7 +48,7 @@ be used to provide the data and some additional control over the rendering of th This abstracts the data manipulation view logic from the layouting view logic. -A widget can a new fragment like this: +A widget can implement a new fragment like this: package MyApp::Widget::Foo; use Reaction::UI::WidgetClass; -- cgit v1.2.3-54-g00ecf