Mailing List Archive: Catalyst: Users

Splitting up a large application: Shared config and templates for multiple applications

Index | Next | Previous | View Threaded

moseley at hank

Aug 27, 2009, 8:46 AM

Post #1 of 8 (1647 views)
Permalink

Splitting up a large application: Shared config and templates for multiple applications

I'm exploring the idea of breaking up a large application into a number of
separate Catalyst apps. The application currently exists of a base
application and a number of optional "products." For example, one product
might be to add a calendar and scheduling to the application.

The base application has layout templates that all "products" need to use.
So each app would need to share a template path. Also, each product would
need access to application-wide configuration.

The reason I'm looking at this approach is so that different teams of
developers can work on the products, test products separately, and release
the products on different schedules.

Anyone building applications out of multiple small Catalyst applications
like this? How do you set up the apps to share templates and a config?
Anything more interesting than passing in paths?

One downside of this approach is we end up with a handful of very similar
looking applications (same set of plugins, etc.), not to mention have to be
careful about how session data is shared, and so on. I wounder if it would
be difficulst to customize the catalyst.pl script to include a standard set
of plugins/roles that we use in every application -- e.g. have a skeleton
app.

Oh, just noticed:

$ cat MyApp/myapp.conf
# rename this file to MyApp.yml and put a ':' in front of 'name' if
# you want to use YAML like in old versions of Catalyst
name MyApp

ConfigLoader looks for lower case file names, right? That is, shouldn't
that be "myapp.yml"?

--
Bill Moseley
moseley [at] hank

matt at mattwhipple

Aug 28, 2009, 6:41 AM

Post #2 of 8 (1535 views)
Permalink

Re: Splitting up a large application: Shared config and templates for multiple applications [In reply to]

Bill Moseley wrote:
> I'm exploring the idea of breaking up a large application into a
> number of separate Catalyst apps. The application currently exists of
> a base application and a number of optional "products." For example,
> one product might be to add a calendar and scheduling to the application.
>
> The base application has layout templates that all "products" need to
> use. So each app would need to share a template path. Also, each
> product would need access to application-wide configuration.
>
> The reason I'm looking at this approach is so that different teams of
> developers can work on the products, test products separately, and
> release the products on different schedules.
>
> Anyone building applications out of multiple small Catalyst
> applications like this? How do you set up the apps to share templates
> and a config? Anything more interesting than passing in paths?
> One downside of this approach is we end up with a handful of very
> similar looking applications (same set of plugins, etc.), not to
> mention have to be careful about how session data is shared, and so
> on. I wounder if it would be difficulst to customize the catalyst.pl
> script to include a standard set of plugins/roles that we use in every
> application -- e.g. have a skeleton app.
>
Subclass. This could probably take care of sharing the template/config
resources also, but otherwise I'd probably lean towards symlinking over
modifying each app.

>
>
> Oh, just noticed:
>
> $ cat MyApp/myapp.conf
> # rename this file to MyApp.yml and put a ':' in front of 'name' if
> # you want to use YAML like in old versions of Catalyst
> name MyApp
>
> ConfigLoader looks for lower case file names, right? That is,
> shouldn't that be "myapp.yml"?
>
>
>
> --
> Bill Moseley
> moseley [at] hank <mailto:moseley [at] hank>
> ------------------------------------------------------------------------
>
> _______________________________________________
> List: Catalyst [at] lists
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
> Dev site: http://dev.catalyst.perl.org/
>

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

moseley at hank

Aug 28, 2009, 7:08 AM

Post #3 of 8 (1533 views)
Permalink

Re: Splitting up a large application: Shared config and templates for multiple applications [In reply to]

On Fri, Aug 28, 2009 at 6:41 AM, Matt Whipple <matt [at] mattwhipple> wrote:

>
>
>> Anyone building applications out of multiple small Catalyst applications
>> like this? How do you set up the apps to share templates and a config?
>> Anything more interesting than passing in paths?
>> One downside of this approach is we end up with a handful of very similar
>> looking applications (same set of plugins, etc.), not to mention have to be
>> careful about how session data is shared, and so on. I wounder if it would
>> be difficulst to customize the catalyst.pl script to include a standard set
>> of plugins/roles that we use in every application -- e.g. have a skeleton
>> app.
>>
>> Subclass. This could probably take care of sharing the template/config
> resources also, but otherwise I'd probably lean towards symlinking over
> modifying each app.

Subclass what?

I was thinking that I'd have to use an environment variable to point to the
location of the base application (the one with the base tempates and
app-wide config) and then add to the template INCLUDE_PATH. Or maybe have
the applications look at $app_home/../$base_app/.

Seems there was some discussion not too long ago of drop-in modules for
application, similar to what many CMSs have.

--
Bill Moseley
moseley [at] hank

frioux at gmail

Aug 28, 2009, 8:42 AM

Post #4 of 8 (1532 views)
Permalink

Re: Splitting up a large application: Shared config and templates for multiple applications [In reply to]

On Fri, Aug 28, 2009 at 9:08 AM, Bill Moseley <moseley [at] hank> wrote:

>
>
> On Fri, Aug 28, 2009 at 6:41 AM, Matt Whipple <matt [at] mattwhipple>wrote:
>
>>
>>
>>> Anyone building applications out of multiple small Catalyst applications
>>> like this? How do you set up the apps to share templates and a config?
>>> Anything more interesting than passing in paths?
>>> One downside of this approach is we end up with a handful of very similar
>>> looking applications (same set of plugins, etc.), not to mention have to be
>>> careful about how session data is shared, and so on. I wounder if it would
>>> be difficulst to customize the catalyst.pl script to include a standard set
>>> of plugins/roles that we use in every application -- e.g. have a skeleton
>>> app.
>>>
>>> Subclass. This could probably take care of sharing the template/config
>> resources also, but otherwise I'd probably lean towards symlinking over
>> modifying each app.
>
>
> Subclass what?
>
> I was thinking that I'd have to use an environment variable to point to the
> location of the base application (the one with the base tempates and
> app-wide config) and then add to the template INCLUDE_PATH. Or maybe have
> the applications look at $app_home/../$base_app/.
>
> Seems there was some discussion not too long ago of drop-in modules for
> application, similar to what many CMSs have.
>

Interestingly, I think the Rails guys (or was it Merb?) made something
kindav like this. Basically they made it so that you can drop a Rails app
into an existing Rails app and things "just work." I don't know enough
about Rails to say how well it works and whatnot, and I know that because
Catalyst is much more flexible it is unlikely that we could do anything to
make it as convenient, but maybe we could look into something like this?

I know Chained actions and our lack of a single location of routes
ameliorates this enough that this is probably something not a lot of Cat
teams would use. Anyway, just some thoughts in relation to this stuff...

--
fREW Schmidt
http://blog.afoolishmanifesto.com

bobtfish at bobtfish

Aug 28, 2009, 9:17 AM

Post #5 of 8 (1530 views)
Permalink

Re: Splitting up a large application: Shared config and templates for multiple applications [In reply to]

fREW Schmidt wrote:
> Interestingly, I think the Rails guys (or was it Merb?) made something
> kindav like this. Basically they made it so that you can drop a Rails
> app into an existing Rails app and things "just work."

That's the idea.

> I don't know
> enough about Rails to say how well it works and whatnot,

Totally doesn't for non-trivial examples ;)

> and I know that
> because Catalyst is much more flexible it is unlikely that we could do
> anything to make it as convenient, but maybe we could look into
> something like this?

With all the new technology now possible in 5.80, then this is totally
possible, and my CatalystX::SimpleLogin is a prototype for a 'component'
that you can just plug into applications.

This is mostly waiting on my pulling my finger out my ass and finishing
off the MethodAttributes in role combinations stuff, at which point
it'll be possible to build a simple way to bundle and inject sets of
roles/classes into your application via config, which, as you noted,
would go nicely with chained actions.

So this is being worked on, but I've been lazy for the last few weeks,
and had a fairly chain of yak-shaving associated with it to get where I
wanted to be to enable this to be possible in a flexible enough manor.

Cheers
t0m

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

rodrigolive at gmail

Aug 28, 2009, 9:55 AM

Post #6 of 8 (1537 views)
Permalink

Re: Splitting up a large application: Shared config and templates for multiple applications [In reply to]

> Anyone building applications out of multiple small Catalyst applications
> like this? How do you set up the apps to share templates and a config?
> Anything more interesting than passing in paths?
>
>
I have a working module called CatalystX::Featurizer that I've been using in
an app at $work. It's still at a very early stage, but I'm just going to
push early. No POD included, no tests... You've been warned. :D

http://github.com/rodrigolive/catalystx_featurizer

It's a mix of Eclipse features/plugins and RoR plugins. Ideas are welcome. I
have many myself... just don't have time to implement them all right now.

Since there is no POD, I've included a very simple TestApp. Basically the
idea is:

- create a /features directory under your app home.
- each feature home dir should be named something like

/features/my.demo.feature_1.0.0

- it's a split on underscore "_", the first part is the feature name (very
javaish, I know, with dots and all), the second is the version.
- if a higher version of a feature is found, that's the one to be used, the
rest is ignored
- a feature without a version is ok, it will be the highest version
available - good for local dev and pushing to a repository.
- a debug box is printed on startup, so you can check which version is
running:

[debug] Features Loaded:
.----------------------------------------+------------------------+----------.
| Feature Name | Class | Version
|
+----------------------------------------+------------------------+----------+
| simple.feature_1.0.0 | simple.feature | 1.0.0
|
.-----------------------------------------------------------------+----------.

- the idea is to merge /root dirs (right now for Static::Simple, TT and
Mason)
- controllers, models, schema, etc. should work just like when underneath
MyApp/lib
- simple.feature.conf is loaded as part of the main conf (appended) - the
filename has to match the feature "class" name, ie "simple.feature".
- extend the main app part by part (depending on your needs), replacing the
standard plugin with an extended one:

use Catalyst qw/-Debug
+CatalystX::Featurizer ---- this one is a must, loads
features and push things into @INC
+CatalystX::Featurizer::Plugin::ConfigLoader -----
optional
+CatalystX::Featurizer::Plugin::Static::Simple ------
optional
/;

- I'm also including CF::View::Mason and CF::View::TT. To use them, just
subclass it in your MyApp::View::TT or Mason, instead of the C::V::TT,Mason.
- a CF::Plugin::I18N is included too.
- $c->features returns an array of CF::Feature objects that can be used to
identify features, etc.

Let me know what you think.

cheers
-rodrigo

bobtfish at bobtfish

Aug 30, 2009, 10:21 AM

Post #7 of 8 (1449 views)
Permalink

Re: Splitting up a large application: Shared config and templates for multiple applications [In reply to]

On 28 Aug 2009, at 17:55, Rodrigo wrote:

>
> Anyone building applications out of multiple small Catalyst
> applications like this? How do you set up the apps to share
> templates and a config? Anything more interesting than passing in
> paths?
>
>
> I have a working module called CatalystX::Featurizer that I've been
> using in an app at $work. It's still at a very early stage, but I'm
> just going to push early. No POD included, no tests... You've been
> warned. :D
>
> http://github.com/rodrigolive/catalystx_featurizer

Nice :)

I'll look into this more closely when I have chance (this week
hopefully) and give you some deeper feedback.

One of the things I've been thinking about significantly is how
'features' can ship templates in whatever the feature author's
preferred template language is, but allow customisation of those
templates (or, more importantly, of the fragments those templates are
made from) in a different template language - so using feature X
doesn't force the application author to have to use TT or Mason or
whatever.

I'm interested in your approach to this - given you've obviously
thought of this (on some level at least), as you're already supporting
TT and Mason.

Cheers
t0m

_______________________________________________
List: Catalyst [at] lists
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst [at] lists/
Dev site: http://dev.catalyst.perl.org/

rodrigolive at gmail

Sep 2, 2009, 9:03 AM

Post #8 of 8 (1446 views)
Permalink

Re: Splitting up a large application: Shared config and templates for multiple applications [In reply to]

>
>> http://github.com/rodrigolive/catalystx_featurizer
>>
>
> Nice :)
>
> I'll look into this more closely when I have chance (this week hopefully)
> and give you some deeper feedback.
>

Cool, I appreciate your feedback on this.

BTW, I've just now reblessed the module *CatalystX::Features* since the
"rizer" suffix is sortta of a in-joke here at $work... Besides it's 2 bytes
shorter ;)

So finally I put it here, with a little PODing in Features.pm:

http://github.com/rodrigolive/catalystx_features

Hopefully I'll have some time this weekend to cpanize this thing and do a
dev release.

>
> One of the things I've been thinking about significantly is how 'features'
> can ship templates in whatever the feature author's preferred template
> language is, but allow customisation of those templates (or, more
> importantly, of the fragments those templates are made from) in a different
> template language - so using feature X doesn't force the application author
> to have to use TT or Mason or whatever.
>
> I'm interested in your approach to this - given you've obviously thought of
> this (on some level at least), as you're already supporting TT and Mason.
>

I think I grasp the concept, but I haven't come across the need... just yet.

I guess it would take some abstracting while going from the app to the
feature and back. Or maybe it would need to trap some of the internal view
engines to capture that precompiled template, just before it get's evaled
and/or run into HTML or whatever the template becomes. Well, somewhere in
between the template engine and the Catalyst controller there must be a spot
where we could just talk plain perl and let things communicate regardless of
the templating engine in use.

Indeed you hit a sensitive note here. The "merging" of two parts (myapp +
myfeature) is quite complex. To the point merging could become a separate
module entirely. I even thought of separating parts of the module into a
different module called i.e. CatalystX::Merge, but I pulled back, at least
for now, to keep things concise.

cheers,
rod

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads