Integrating Bricolage with Catalyst

Dear all,

I'm in the process of evaluating possibilities to integrate
Bricolage
with the Catalyst web framework. We're planning on doing a
complete relaunch
of our site which mainly has a content part (magazine with
stories) and
a community part (forum, chat etc.). Catalyst makes it
really easy to implement
the various dynamic parts of our application and I really
love Bricolage when
it comes to managing static content.

In the past, I have built a medium-sized site featuring
mixed static and
dynamic functionality with Bricolage and Mason with no pain.
The integration was
straightforward as often suggested here on the list: Have
Bricolage serve
static files which are evaluated and served through Mason.
Every URL has a
directly corresponding file in the filesystem. This was nice
and convenient -
but unfortunately without the advantages of a proper MVC
framework.

With Catalyst however I have controllers with actions that
map to certain URLs,
process a model and forward to a view to render the final
page. The first
thing that came to my mind was having Bricolage output
Template-Toolkit
templates which serve as the view part within Catalyst. But
IMHO this is an
awkward attempt because the templates are no longer
templates but rather
full pages complete with content. Furthermore, my
controllers know nothing
about the content. Try adding a
"comment-on-this-story" function with this -
there's only the URL which could be used as a reference to
the story - no ID,
no nothing. I thought about including an XML snippet within
every story that
contained some meta-information like story ID, categories
etc. which is read
and parsed by my Catalyst controllers but this is nowhere
near a clean
approach IMHO.

Another approach that came to my mind is having Bricolage
output XML only that
is parsed by a Catalyst model (using XML::Twig oder
::Simple) and then fed
through my Catalyst controllers in the standard way.
Fiddling with this
approach I'm still unsure how to configure my output
channels in Bricolage:
Having an XML OC which outputs stories in the URI format of
"%/{%slug}/story.xml" generates ugly
final URLs like:
/magazine/health/my_story_title/story.xml - I don't like the
.xml ending here
but the content of the file sure is XML, so what to do? Also
bric_soap already
is capable of exporting stories as XML so why would I want
to create another
set of (XML) templates within Bricolage that mimic this
behaviour?

Maybe somebody here already has integrated Bric and Catalyst
or some similar
combination and could shed some light on how this could be
pulled off. I believe
that having those two awesome tools combined in a sane way
would be an
absolutely killer web-application bundle 

Thanks for your time and suggestions!

--Tobias

(Your email looks german, are you already in the german
catalyst
 mailing list (http://lists.scsys.co.uk/mailman/listinfo/catalyst-de)?

 If you ever come to results you could please also tell your
results
 there.)


Tobias Kremer <listfunkreich.de> writes:
> I'm in the process of evaluating possibilities to
integrate
> Bricolage with the Catalyst web framework.

Nice to hear that. I also already thought about it, but
haven't
practically done it yet.

I'm just thinking loud in the following:

> We're planning on doing a complete relaunch of our site
which mainly
> has a content part (magazine with stories) and a
community part
> (forum, chat etc.). Catalyst makes it really easy to
implement the
> various dynamic parts of our application and I really
love Bricolage
> when it comes to managing static content.
>
> In the past, I have built a medium-sized site featuring
mixed static
> and dynamic functionality with Bricolage and Mason with
no pain. The
> integration was straightforward as often suggested here
on the list:
> Have Bricolage serve static files which are evaluated
and served
> through Mason. Every URL has a directly corresponding
file in the
> filesystem. This was nice and convenient - but
unfortunately without
> the advantages of a proper MVC framework.

I wouldn't mind doing the same with catalyst. Simply let
bricolage
publish into a complete own area (say "/static")
that your catalyst
app can deliver via Catalyst::Plugin::Static::Simple.


> With Catalyst however I have controllers with actions
that map to
> certain URLs, process a model and forward to a view to
render the
> final page. The first thing that came to my mind was
having
> Bricolage output Template-Toolkit templates which serve
as the view
> part within Catalyst. But IMHO this is an awkward
attempt because
> the templates are no longer templates but rather full
pages complete
> with content. Furthermore, my controllers know nothing
about the
> content.

I'm not sure, what the problem is. That you have to escape
the
template language in bricolage that you want to be resolved
in
Catalyst? That could be avoided when you choose different
engines,
eg. use Template-Toolkit as template engine in Bricolage
templates and
generate Mason tags that you let Catalyst process. Or vice
versa.


> Try adding a "comment-on-this-story" function
with this -
> there's only the URL which could be used as a reference
to the story
> - no ID, no nothing.

But what is wrong with that? The URL is practically like an
unambiguous ID from Catalyst's point of view. If it looks
wrong for an
ID, hash it md5 and store it in DB to resolve it in both
directions.


> I thought about including an XML snippet within
> every story that contained some meta-information like
story ID,
> categories etc. which is read and parsed by my Catalyst
controllers
> but this is nowhere near a clean approach IMHO.
>
> Another approach that came to my mind is having
Bricolage output XML
> only that is parsed by a Catalyst model (using
XML::Twig oder
> ::Simple) and then fed through my Catalyst controllers
in the
> standard way.

Hm. I wouldn't do this. Sounds too much overhead for a
practically
already completely rendered html content from Bricolage.


> Fiddling with this approach I'm still unsure how to
> configure my output channels in Bricolage: Having an
XML OC which
> outputs stories in the URI format of
> "%/{%slug}/story.xml" generates
ugly final URLs like:
> /magazine/health/my_story_title/story.xml - I don't
like the .xml
> ending here but the content of the file sure is XML, so
what to do?

You don't have to use .xml, it can be anything.


> Also bric_soap already is capable of exporting stories
as XML so why
> would I want to create another set of (XML) templates
within
> Bricolage that mimic this behaviour?

This would lead to a practically dynamically delivering CMS
application. I wouldn't do that. It's too slow. Even if you
cache, the
first access of a page would suck.

Instead, if you really need more infos in the pages, then
generate the
meta info into the pages with your own syntax, define your
Catalyst
Action or a special View to parse (and maybe replace/delete)
the meta
info before delivering.


> Maybe somebody here already has integrated Bric and
Catalyst or some
> similar combination

We didn't do it with Bricolage but already with an other
statically
content generating CMS (a commercial one). Although the
areas were
quite hard divided. So maybe your needs are slightly more
challenging.

Anyway, we did it with my first idea above, divide static
content from
dynamic application via different sub uris. I don't remember
whether
we did it with Plugin::Static::Simple or maybe at Apache
level where
the Catalyst application is defined at it's own subdir/path
beside the
static content.

GreetinX
Steffen 
-- 
Steffen Schwigon <schwigonwebit.de>
Dresden Perl Mongers <http://dresden-pm.org/>

Deutscher Perl-Workshop <http://www.perl-work
shop.de/>

Hi Steffen.

> (Your email looks german, are you already in the german
catalyst
>  mailing list (http://lists.scsys.co.uk/mailman/listinfo/catalyst-de)?


Yes and yes 

> > In the past, I have built a medium-sized site
featuring mixed static
> > and dynamic functionality with Bricolage and Mason
with no pain. The
> > integration was straightforward as often suggested
here on the list:
> > Have Bricolage serve static files which are
evaluated and served
> > through Mason. Every URL has a directly
corresponding file in the
> > filesystem. This was nice and convenient - but
unfortunately without
> > the advantages of a proper MVC framework.
>
> I wouldn't mind doing the same with catalyst. Simply
let bricolage
> publish into a complete own area (say
"/static") that your catalyst
> app can deliver via Catalyst::Plugin::Static::Simple.

This would make the output generated by Bricolage completely
static. My
Catalyst controllers won't run for these files and thus I
won't be able
to add dynamic content or did I miss something here?

> > With Catalyst however I have controllers with
actions that map to
> > certain URLs, process a model and forward to a
view to render the
> > final page. The first thing that came to my mind
was having
> > Bricolage output Template-Toolkit templates which
serve as the view
> > part within Catalyst. But IMHO this is an awkward
attempt because
> > the templates are no longer templates but rather
full pages complete
> > with content. Furthermore, my controllers know
nothing about the
> > content.
>
> I'm not sure, what the problem is. That you have to
escape the
> template language in bricolage that you want to be
resolved in
> Catalyst? That could be avoided when you choose
different engines,
> eg. use Template-Toolkit as template engine in
Bricolage templates and
> generate Mason tags that you let Catalyst process. Or
vice versa.

That's exactly what I did to avoid this while playing around
with this
approach  I just
don't feel like fully rendered pages generated by
Bricolage should end up in my Catalyst root (template)
directory. It feels
strange to me that full pages with nearly content are used
as templates - but
maybe that's just me 

> > Try adding a "comment-on-this-story"
function with this -
> > there's only the URL which could be used as a
reference to the story
> > - no ID, no nothing.
>
> But what is wrong with that? The URL is practically
like an
> unambiguous ID from Catalyst's point of view. If it
looks wrong for an
> ID, hash it md5 and store it in DB to resolve it in
both directions.

Good idea. I just like integer IDs for this stuff. Integer
indexes should
be faster than alphanumeric indexes.

> > Another approach that came to my mind is having
Bricolage output XML
> > only that is parsed by a Catalyst model (using
XML::Twig oder
> > ::Simple) and then fed through my Catalyst
controllers in the
> > standard way.
>
> Hm. I wouldn't do this. Sounds too much overhead for a
practically
> already completely rendered html content from
Bricolage.

Yes, and as far as I have played with this it's really a
PITA - Sort of
makes Bricolage quite a bit more useless.

> > Fiddling with this approach I'm still unsure how
to
> > configure my output channels in Bricolage: Having
an XML OC which
> > outputs stories in the URI format of
> > "%/{%slug}/story.xml"
generates ugly final URLs like:
> > /magazine/health/my_story_title/story.xml - I
don't like the .xml
> > ending here but the content of the file sure is
XML, so what to do?
>
> You don't have to use .xml, it can be anything.

I know, but files containing XML should end with .xml.
Not .html or whatever. But I'm starting to believe that this
whole
XML-only approach makes stuff way too complicated.

> > Also bric_soap already is capable of exporting
stories as XML so why
> > would I want to create another set of (XML)
templates within
> > Bricolage that mimic this behaviour?
>
> This would lead to a practically dynamically delivering
CMS
> application. I wouldn't do that. It's too slow. Even if
you cache, the
> first access of a page would suck.
>
> Instead, if you really need more infos in the pages,
then generate the
> meta info into the pages with your own syntax, define
your Catalyst
> Action or a special View to parse (and maybe
replace/delete) the meta
> info before delivering.

That's what I described above (I included a short XML meta
information
snippet with story ids and stuff). Still feels somewhat
wrong to me. I have
to read the file, parse the meta-information and hand it
over to the view (TT)
which again reads the file and parses it.

> We didn't do it with Bricolage but already with an
other statically
> content generating CMS (a commercial one). Although the
areas were
> quite hard divided. So maybe your needs are slightly
more challenging.

There is a fair amount of interaction between static content
generated by
Bricolage and dynamic content controlled with Catalyst, so
we can't handle
stories in a completely static way.

Thanks for your ideas, Steffen!

--Tobias

Tobias Kremer <listfunkreich.de> writes:
>> > "%/%/story.xml"

Regarding the discussed interaction with other systems,
maybe it would
be a useful to have more such keywords for URI creation,
e.g.,

 %        ... id of story or media
 % ... id of the element that the story/media is
based on
 %      ... one of "story",
"media" (, "template"?)
 %   ... version number
 %      ... UUID
 %        ... the output channel (not really neccesary
because the
                  path is specific to the OC)

and probably some more that are available as meta info.

Then you could infer the meta info from the URI during the
Catalyst
action and secondly, you can infer the URI by its meta info
from
outside bricolage.

Not all of them would make sense to normal Bricolage usage,
but the
documentation could tell about this and give hints that they
are meant
for integration purposes.

(And maybe only the static ones are possible, not the always
changing
things like "%", because a lot of old
files would scatter
around or Bric had to clean them away everytime. Don't know
...)


David? Does it sound useful? Absurd? Somewhere between? 

Steffen
-- 
Steffen Schwigon <schwigonwebit.de>
Dresden Perl Mongers <http://dresden-pm.org/>

Deutscher Perl-Workshop <http://www.perl-work
shop.de/>

Steffen Schwigon <schwigonwebit.de> writes:
> Regarding the discussed interaction with other systems,
maybe it would
> be a useful to have more such keywords for URI
creation, e.g.,
>
>  %        ... id of story or media
>  % ... id of the element that the
story/media is based on
>  %      ... one of "story",
"media" (, "template"?)
>  %   ... version number
>  %      ... UUID
>  %        ... the output channel (not really
neccesary because the
>                   path is specific to the OC)

BTW, is it possible to use these tags in the filename and
extension?
(I can't try it at the moment, live systems everywhere. 

If not, could it be made possible? So that for instance the
filename
can become

  /.../%.html.%


And (*woooohoo, association blast*) yet another tag might be
useful: a
mnemonic for the used template engine:

  % ... one of "mas",
"tt", "htmlt", "php"

so I can make URIs like

  /.../%.%


Steffen
-- 
Steffen Schwigon <schwigonwebit.de>
Dresden Perl Mongers <http://dresden-pm.org/>

Deutscher Perl-Workshop <http://www.perl-work
shop.de/>

> Regarding the discussed interaction with other systems,
maybe it would
> be a useful to have more such keywords for URI
creation, e.g.,
>
>  %        ... id of story or media
>  % ... id of the element that the
story/media is based on
>  %      ... one of "story",
"media" (, "template"?)
>  %   ... version number
>  %      ... UUID
>  %        ... the output channel (not really
neccesary because the
>                   path is specific to the OC)

Yes, I'd love to have something like that! Unfortunately
while digging
through the mailing list archives I found out somebody
already asked
for % and David pointed out that ids are not as unique
as one might
think (e.g. after re-importing exported stories they will
not stay the
same) and the request was dropped. For a more seemless
integration with
MVC systems this nevertheless would be a great add-on IMHO.

> David? Does it sound useful? Absurd? Somewhere between?


Steffen++ 

--Tobias

On Mar 6, 2007, at 07:20, Steffen Schwigon wrote:

> Regarding the discussed interaction with other systems,
maybe it would
> be a useful to have more such keywords for URI
creation, e.g.,
>
>  %        ... id of story or media

No.

>  % ... id of the element that the
story/media is based on

I think I'd prefere %. Better to use
text.

>  %      ... one of "story",
"media" (, "template"?)
>  %   ... version number

I don't think so. Then your URL would change every time you
changed a  
story. That's bad.

>  %      ... UUID

This is already done (and was put in so for those who wanted
the id).

>  %        ... the output channel (not really
neccesary because the
>                   path is specific to the OC)

Right.

Best,

David

On Mar 6, 2007, at 07:33, Steffen Schwigon wrote:

> BTW, is it possible to use these tags in the filename
and extension?
> (I can't try it at the moment, live systems everywhere.


No, not at this time.

> If not, could it be made possible? So that for instance
the filename
> can become
>
>   /.../%.html.%

Sure. Patches welcome. ;-P

> And (*woooohoo, association blast*) yet another tag
might be useful: a
> mnemonic for the used template engine:
>
>   % ... one of "mas",
"tt", "htmlt", "php"
>
> so I can make URIs like
>
>   /.../%.%

%.

Best,

David