[Catalyst] A View that may include elements optionally returned
from other funcs
Joe Landman
landman at scalableinformatics.com
Tue Apr 24 02:38:17 GMT 2007
Hi Steve
Steve H wrote:
> Hi all,
[...]
> Anyway.... the dilema I have is: With Catalyst, how do I compose a html
> document from multiple sources. For example I have many Boxes of data,
> the creation of which I'd like to generalise, and optionally include
> some/none/all in any finally composed page/document (and positioned at
> for examle, tags in any doc they could appear in)... like a menu or a
> hot-list or other things that may be common to many documents/pages.
"Easy" :) Use one "master" controller that stashes what you need from
the multiple sources, by calling the necessary methods to populate the
multiple source data set.
We are doing this with one of our own codes. If we don't want the
element to appear, we leave the element undefined. Then in the
"template" (we use Mason), our page is composed of lots of
<& /components/foo, bar=>$bar &>
if $bar is undef, then in the component, there is a master if-then
construct like this:
if ($bar) {
# output stuff
}
This lets our master controller stuff everything we need into the stash,
then the template simply outputs on a sub-component basis if that
component's data is defined. I think something similar is possible with
TT using [%include foo%]
> At face value, Catalysts model of a Controller to crunch/prepare the
> data then a View to render a doc/page, seems to promote a 1-document per
> view notion.
> For this sort of er, Portal app I'm working on, I'd like to when
> composing a page, identify whether or not particular common elements
> (say, boxes of data) should be included, and then merely call out to
> some common functoin to build the things which I then stitch them in at
> the appropriate place in the final doc.
If you have a master controller as indicated, this can be made to happen
(and should be made to happen) in the template.
> Seems to me that at the point in processing I need to intervene (the
> final page's View), the doc is the compiled/hash representing the html
> doc tree. I can certainly look_down() and replace_content() in that
Ugh... Assume that the view gets everything from controller. Then
this controller is the thing that should gather everything together
before shipping it to the view. Let the template decide the form, let
the controller decide the content.
> tree.... how though can I call some other function that will return the
> appropriate structure to stitch in. If they were their own View, they
> would parse a doc fragment (or even a larger doc with lots of common
> fragments) into a tree in it's new()... then I'd call in to some
> function that would build and return me the structure that I could
> push/replace/splice in to the tree I'm composing.
> Although I'm a well experienced programmer from way back :(from the old
> top-down days though), I am still struggling to get my head around the
> whole interitence and calling model of the Catalyst OO framework... in
> who does what to who, when, for how much, and where did they meet.
> Hopefully what I'm trying to do is pretty 101 stuff, and someone with
> the right Catalyst/Seamstress stuff can 'show me the way'... as I'm
> going nuts trying out different things from Google'ing.
>
> regards
> Steve
>
> _________________________________________________________________
> Advertisement: Visit LetsShop.com to WIN Fabulous Books Weekly
> http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fwww%2Eletsshop%2Ecom%2FLetsShopBookClub%2Ftabid%2F866%2FDefault%2Easpx&_t=751480117&_r=HM_Tagline_books&_m=EXT
>
>
>
> _______________________________________________
> List: Catalyst at lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/[email protected]/
> Dev site: http://dev.catalyst.perl.org/
More information about the Catalyst
mailing list