Mailing List Archive: Catalyst: Dev

RFC: new helper api

Index | Next | Previous | View Threaded

devin.austin at gmail

Jun 3, 2009, 7:51 PM

Post #1 of 9 (1601 views)
Permalink

RFC: new helper api

Howdy all,

I've put together an RFC for the new Catalyst::Helper API.
The body text is located below, but it is also available here in a pretty
formatted version:
http://www.codedright.net/2009/06/rfc-catalysthelper-api.html

For the improvement of the Catalyst::Helper API and Catalyst development in
general, comments are of the utmost importance. The more feedback
I can get, the better and quicker the API will be completed.

Thank you kindly!

-dhoss

*Intro:
*This document is to get opinions on a new, up to date set up and
refactoring of the Catalyst::Helper API.

*What We Have*
Currently, all template/image data is hideously store inline with code in
the __DATA__ section of Catalyst::Helper.pm. The API is designed to handle
data this way, which is wrong wrong wrong for a number of reasons:

1. You have to actually delve into Catalyst internals to edit any of
these files
2. If you create a helper, your data must be inline as well.
3. Its current layout does not reflect the directory hierarchy of a
Catalyst application, thus making it pretty dang hard to expand
upon/upgrade.

There are no methods to allow you to edit previously created files, unless
you want to create your own helper and feverishly create your own file
modification method(s).
I can attest to the stress this causes, as I've been doing a good deal of
yak shaving cleaning this code up and creating the proper tests for it.
It's not a very fun ordeal at this point.

*What we want*
>From the feedback I've gathered thus far:

We *do* want previously created helper files to be modifiable via
Catalyst::Helpers. For instance, updating Makefile.PL, updating myapp.conf
to reflect changes, updating DBIC schema files to reflect database changes
(with minimal pain). Also, add an infrastructure for modifying existing
catalyst code, e.g. moving Catalyst::Helper::AuthDBIC from an experimental
proof of concept to something that people might actually want to use for
their own stuff.

We *do* want to be able to remove a good deal of the boilerplate code that
still seems to need to be created manually, for each app, even though it's
the exact same code for each instance.

We *do* want to set up the helper files in the hierarchy that a Catalyst
application is created in, thus cutting quickly to the chase in the way of
creating an app. It's a simple name and Template::Toolkit variable
translation, then writing the file to the filesystem process then. This
gets our binary data out of the API code, the template data out of the API
code, and generally makes every one more happy.

With this said, here are some more specific ideas that have been passed my
way that I think would really help further advance our precious Helper API:

1. Beat up MooseX::Getopt to deal with pass-through options, so you can
deal with passing data structures as arguments easier. Not to mention
actually start USING it in the Helper API.
2. Add a feature to write out DBIC schema files for deployment. Yes,
make_schema_at does this, but you have to write your own little script to
enjoy this morsel of functionality. It would be nice to have it packaged up
and ready to go for you.
3. Have something like TTSite, but less sucky. Perhaps there could be a
default layout that can be created, or you can create your own sort of skin
and have that the default generation. Or, better yet, packaged skins that
users can submit to $somewhere and have the author choose a "theme" for
their app. For instance, using $javascript framework and $css framework to
do so, like in chapt 11 of the upcoming book (Example usage:
http://www.uow.edu.au/~kd21/ <http://www.uow.edu.au/%7Ekd21/>)

These are the current ideas I have, and that others have submitted. Sure
this RFC is a bit bare, but we don't have a whole ton to work with at the
moment with Catalyst::Helper, so we need more feedback to beef things up.

--
Devin Austin
http://www.codedright.net
http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!

zzbbyy at gmail

Jun 5, 2009, 1:28 PM

Post #2 of 9 (1519 views)
Permalink

Re: RFC: new helper api [In reply to]

On Thu, Jun 4, 2009 at 4:51 AM, Devin Austin<devin.austin[at]gmail.com> wrote:
> Howdy all,
>
> I've put together an RFC for the new Catalyst::Helper API.
> The body text is located below, but it is also available here in a pretty
> formatted
> version:http://www.codedright.net/2009/06/rfc-catalysthelper-api.html
>
> For the improvement of the Catalyst::Helper API and Catalyst development in
> general, comments are of the utmost importance. The more feedback
> I can get, the better and quicker the API will be completed.
>
> Thank you kindly!
>
> -dhoss
>
> Intro:
> This document is to get opinions on a new, up to date set up and
> refactoring of the Catalyst::Helper API.
>
> What We Have
> Currently, all template/image data is hideously store inline with code in
> the __DATA__ section of Catalyst::Helper.pm. The API is designed to handle
> data this way, which is wrong wrong wrong for a number of reasons:
>
> You have to actually delve into Catalyst internals to edit any of these
> files
> If you create a helper, your data must be inline as well.
> Its current layout does not reflect the directory hierarchy of a Catalyst
> application, thus making it pretty dang hard to expand upon/upgrade.
>
> There are no methods to allow you to edit previously created files, unless
> you want to create your own helper and feverishly create your own file
> modification method(s).
> I can attest to the stress this causes, as I've been doing a good deal of
> yak shaving cleaning this code up and creating the proper tests for it.
> It's not a very fun ordeal at this point.
>
> What we want
> From the feedback I've gathered thus far:
>
> We do want previously created helper files to be modifiable via
> Catalyst::Helpers. For instance, updating Makefile.PL, updating myapp.conf
> to reflect changes, updating DBIC schema files to reflect database changes
> (with minimal pain). Also, add an infrastructure for modifying existing
> catalyst code, e.g. moving Catalyst::Helper::AuthDBIC from an experimental
> proof of concept to something that people might actually want to use for
> their own stuff.
>
> We do want to be able to remove a good deal of the boilerplate code that
> still seems to need to be created manually, for each app, even though it's
> the exact same code for each instance.
>
> We do want to set up the helper files in the hierarchy that a Catalyst
> application is created in, thus cutting quickly to the chase in the way of
> creating an app. It's a simple name and Template::Toolkit variable
> translation, then writing the file to the filesystem process then. This
> gets our binary data out of the API code, the template data out of the API
> code, and generally makes every one more happy.
>
> With this said, here are some more specific ideas that have been passed my
> way that I think would really help further advance our precious Helper API:
>
> Beat up MooseX::Getopt to deal with pass-through options, so you can deal
> with passing data structures as arguments easier. Not to mention actually
> start USING it in the Helper API.
> Add a feature to write out DBIC schema files for deployment. Yes,
> make_schema_at does this, but you have to write your own little script to
> enjoy this morsel of functionality. It would be nice to have it packaged up
> and ready to go for you.
> Have something like TTSite, but less sucky. Perhaps there could be a
> default layout that can be created, or you can create your own sort of skin
> and have that the default generation. Or, better yet, packaged skins that
> users can submit to $somewhere and have the author choose a "theme" for
> their app. For instance, using $javascript framework and $css framework to
> do so, like in chapt 11 of the upcoming book (Example usage:
> http://www.uow.edu.au/~kd21/)
>
> These are the current ideas I have, and that others have submitted. Sure
> this RFC is a bit bare, but we don't have a whole ton to work with at the
> moment with Catalyst::Helper, so we need more feedback to beef things up.

Hi,

All that you mention above are great steps ahead - and it'll be
wonderful if they are implemented. If I may add something to that
list - it is a possibility to run the helpers in aggregation - so that
you could define the configuration once for all the parts and then run
catalyst.pl to generate the whole application in one step. Currently
you run catalyst.pl from the outside - and then you go into the
generated directory and use one of the generated scripts to generate
the further components. In theory it should be possible that all that
generation is done by catalyst.pl.

Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

devin.austin at gmail

Jun 5, 2009, 8:22 PM

Post #3 of 9 (1515 views)
Permalink

Re: RFC: new helper api [In reply to]

On Fri, Jun 5, 2009 at 2:28 PM, Zbigniew Lukasiak <zzbbyy[at]gmail.com> wrote:

> On Thu, Jun 4, 2009 at 4:51 AM, Devin Austin<devin.austin[at]gmail.com>
> wrote:
> > Howdy all,
> >
> > I've put together an RFC for the new Catalyst::Helper API.
> > The body text is located below, but it is also available here in a pretty
> > formatted
> > version:http://www.codedright.net/2009/06/rfc-catalysthelper-api.html
> >
> > For the improvement of the Catalyst::Helper API and Catalyst development
> in
> > general, comments are of the utmost importance. The more feedback
> > I can get, the better and quicker the API will be completed.
> >
> > Thank you kindly!
> >
> > -dhoss
> >
> > Intro:
> > This document is to get opinions on a new, up to date set up and
> > refactoring of the Catalyst::Helper API.
> >
> > What We Have
> > Currently, all template/image data is hideously store inline with code in
> > the __DATA__ section of Catalyst::Helper.pm. The API is designed to
> handle
> > data this way, which is wrong wrong wrong for a number of reasons:
> >
> > You have to actually delve into Catalyst internals to edit any of these
> > files
> > If you create a helper, your data must be inline as well.
> > Its current layout does not reflect the directory hierarchy of a
> Catalyst
> > application, thus making it pretty dang hard to expand upon/upgrade.
> >
> > There are no methods to allow you to edit previously created files,
> unless
> > you want to create your own helper and feverishly create your own file
> > modification method(s).
> > I can attest to the stress this causes, as I've been doing a good deal of
> > yak shaving cleaning this code up and creating the proper tests for it.
> > It's not a very fun ordeal at this point.
> >
> > What we want
> > From the feedback I've gathered thus far:
> >
> > We do want previously created helper files to be modifiable via
> > Catalyst::Helpers. For instance, updating Makefile.PL, updating
> myapp.conf
> > to reflect changes, updating DBIC schema files to reflect database
> changes
> > (with minimal pain). Also, add an infrastructure for modifying existing
> > catalyst code, e.g. moving Catalyst::Helper::AuthDBIC from an
> experimental
> > proof of concept to something that people might actually want to use for
> > their own stuff.
> >
> > We do want to be able to remove a good deal of the boilerplate code that
> > still seems to need to be created manually, for each app, even though
> it's
> > the exact same code for each instance.
> >
> > We do want to set up the helper files in the hierarchy that a Catalyst
> > application is created in, thus cutting quickly to the chase in the way
> of
> > creating an app. It's a simple name and Template::Toolkit variable
> > translation, then writing the file to the filesystem process then. This
> > gets our binary data out of the API code, the template data out of the
> API
> > code, and generally makes every one more happy.
> >
> > With this said, here are some more specific ideas that have been passed
> my
> > way that I think would really help further advance our precious Helper
> API:
> >
> > Beat up MooseX::Getopt to deal with pass-through options, so you can
> deal
> > with passing data structures as arguments easier. Not to mention actually
> > start USING it in the Helper API.
> > Add a feature to write out DBIC schema files for deployment. Yes,
> > make_schema_at does this, but you have to write your own little script to
> > enjoy this morsel of functionality. It would be nice to have it packaged
> up
> > and ready to go for you.
> > Have something like TTSite, but less sucky. Perhaps there could be a
> > default layout that can be created, or you can create your own sort of
> skin
> > and have that the default generation. Or, better yet, packaged skins
> that
> > users can submit to $somewhere and have the author choose a "theme" for
> > their app. For instance, using $javascript framework and $css framework
> to
> > do so, like in chapt 11 of the upcoming book (Example usage:
> > http://www.uow.edu.au/~kd21/ <http://www.uow.edu.au/%7Ekd21/>)
> >
> > These are the current ideas I have, and that others have submitted. Sure
> > this RFC is a bit bare, but we don't have a whole ton to work with at the
> > moment with Catalyst::Helper, so we need more feedback to beef things up.
>
> Hi,
>
> All that you mention above are great steps ahead - and it'll be
> wonderful if they are implemented. If I may add something to that
> list - it is a possibility to run the helpers in aggregation - so that
> you could define the configuration once for all the parts and then run
> catalyst.pl to generate the whole application in one step. Currently
> you run catalyst.pl from the outside - and then you go into the
> generated directory and use one of the generated scripts to generate
> the further components. In theory it should be possible that all that
> generation is done by catalyst.pl.
>
> Cheers,
> Zbigniew
> http://brudnopis.blogspot.com/
> http://perlalchemy.blogspot.com/
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev[at]lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

Hi Zbigniew,

Thanks for the input! (Thanks to Francesc as well, I didn't thank you in my
last email).

Perhaps you could flesh out your idea some? Give me an example of how it
would look in usage, I think I'm visualizing it properly, but some concrete
examples would be superb.

Thanks again!

-Devin

--
Devin Austin
http://www.codedright.net
http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!

zzbbyy at gmail

Jun 17, 2009, 4:00 AM

Post #4 of 9 (1467 views)
Permalink

Re: RFC: new helper api [In reply to]

On Sat, Jun 6, 2009 at 5:22 AM, Devin Austin <devin.austin[at]gmail.com> wrote:

>
>
> On Fri, Jun 5, 2009 at 2:28 PM, Zbigniew Lukasiak <zzbbyy[at]gmail.com>wrote:
>
>> On Thu, Jun 4, 2009 at 4:51 AM, Devin Austin<devin.austin[at]gmail.com>
>> wrote:
>> > Howdy all,
>> >
>> > I've put together an RFC for the new Catalyst::Helper API.
>> > The body text is located below, but it is also available here in a
>> pretty
>> > formatted
>> > version:http://www.codedright.net/2009/06/rfc-catalysthelper-api.html
>> >
>> > For the improvement of the Catalyst::Helper API and Catalyst development
>> in
>> > general, comments are of the utmost importance. The more feedback
>> > I can get, the better and quicker the API will be completed.
>> >
>> > Thank you kindly!
>> >
>> > -dhoss
>> >
>> > Intro:
>> > This document is to get opinions on a new, up to date set up and
>> > refactoring of the Catalyst::Helper API.
>> >
>> > What We Have
>> > Currently, all template/image data is hideously store inline with code
>> in
>> > the __DATA__ section of Catalyst::Helper.pm. The API is designed to
>> handle
>> > data this way, which is wrong wrong wrong for a number of reasons:
>> >
>> > You have to actually delve into Catalyst internals to edit any of these
>> > files
>> > If you create a helper, your data must be inline as well.
>> > Its current layout does not reflect the directory hierarchy of a
>> Catalyst
>> > application, thus making it pretty dang hard to expand upon/upgrade.
>> >
>> > There are no methods to allow you to edit previously created files,
>> unless
>> > you want to create your own helper and feverishly create your own file
>> > modification method(s).
>> > I can attest to the stress this causes, as I've been doing a good deal
>> of
>> > yak shaving cleaning this code up and creating the proper tests for it.
>> > It's not a very fun ordeal at this point.
>> >
>> > What we want
>> > From the feedback I've gathered thus far:
>> >
>> > We do want previously created helper files to be modifiable via
>> > Catalyst::Helpers. For instance, updating Makefile.PL, updating
>> myapp.conf
>> > to reflect changes, updating DBIC schema files to reflect database
>> changes
>> > (with minimal pain). Also, add an infrastructure for modifying existing
>> > catalyst code, e.g. moving Catalyst::Helper::AuthDBIC from an
>> experimental
>> > proof of concept to something that people might actually want to use for
>> > their own stuff.
>> >
>> > We do want to be able to remove a good deal of the boilerplate code that
>> > still seems to need to be created manually, for each app, even though
>> it's
>> > the exact same code for each instance.
>> >
>> > We do want to set up the helper files in the hierarchy that a Catalyst
>> > application is created in, thus cutting quickly to the chase in the way
>> of
>> > creating an app. It's a simple name and Template::Toolkit variable
>> > translation, then writing the file to the filesystem process then. This
>> > gets our binary data out of the API code, the template data out of the
>> API
>> > code, and generally makes every one more happy.
>> >
>> > With this said, here are some more specific ideas that have been passed
>> my
>> > way that I think would really help further advance our precious Helper
>> API:
>> >
>> > Beat up MooseX::Getopt to deal with pass-through options, so you can
>> deal
>> > with passing data structures as arguments easier. Not to mention
>> actually
>> > start USING it in the Helper API.
>> > Add a feature to write out DBIC schema files for deployment. Yes,
>> > make_schema_at does this, but you have to write your own little script
>> to
>> > enjoy this morsel of functionality. It would be nice to have it
>> packaged up
>> > and ready to go for you.
>> > Have something like TTSite, but less sucky. Perhaps there could be a
>> > default layout that can be created, or you can create your own sort of
>> skin
>> > and have that the default generation. Or, better yet, packaged skins
>> that
>> > users can submit to $somewhere and have the author choose a "theme" for
>> > their app. For instance, using $javascript framework and $css framework
>> to
>> > do so, like in chapt 11 of the upcoming book (Example usage:
>> > http://www.uow.edu.au/~kd21/ <http://www.uow.edu.au/%7Ekd21/>)
>> >
>> > These are the current ideas I have, and that others have submitted.
>> Sure
>> > this RFC is a bit bare, but we don't have a whole ton to work with at
>> the
>> > moment with Catalyst::Helper, so we need more feedback to beef things
>> up.
>>
>> Hi,
>>
>> All that you mention above are great steps ahead - and it'll be
>> wonderful if they are implemented. If I may add something to that
>> list - it is a possibility to run the helpers in aggregation - so that
>> you could define the configuration once for all the parts and then run
>> catalyst.pl to generate the whole application in one step. Currently
>> you run catalyst.pl from the outside - and then you go into the
>> generated directory and use one of the generated scripts to generate
>> the further components. In theory it should be possible that all that
>> generation is done by catalyst.pl.
>>
>> Cheers,
>> Zbigniew
>> http://brudnopis.blogspot.com/
>> http://perlalchemy.blogspot.com/
>>
>> _______________________________________________
>> Catalyst-dev mailing list
>> Catalyst-dev[at]lists.scsys.co.uk
>> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>>
>
> Hi Zbigniew,
>
> Thanks for the input! (Thanks to Francesc as well, I didn't thank you in
> my last email).
>
> Perhaps you could flesh out your idea some? Give me an example of how it
> would look in usage, I think I'm visualizing it properly, but some concrete
> examples would be superb.
>

I think the beginning would be to just let catalyst.pl run all the other
helpers.
Like:

catalyst.pl MyApp model CatalystModelName DBIC::Schema MyApp::SchemaClass

So you just add the MyApp at the start - and the rest goes just like it was
my_app_create.pl.

If that is done - this should open the possibilities for all the other
modifications.

Cheers,
Zbigniew

> Thanks again!
>
> -Devin
>
>
> --
> Devin Austin
> http://www.codedright.net
> http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev[at]lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>
>

--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

bobtfish at bobtfish

Jun 17, 2009, 4:05 PM

Post #5 of 9 (1465 views)
Permalink

Re: RFC: new helper api [In reply to]

On 17 Jun 2009, at 12:00, Zbigniew Lukasiak wrote:
> I think the beginning would be to just let catalyst.pl run all the
> other helpers.
> Like:
>
> catalyst.pl MyApp model CatalystModelName DBIC::Schema
> MyApp::SchemaClass
>
> So you just add the MyApp at the start - and the rest goes just
> like it was my_app_create.pl.
>
> If that is done - this should open the possibilities for all the
> other modifications.

I don't see how this helps or hinders?

Surely it means that catalyst.pl checks if it can 'cd' into the
directory named by its first argument, then executes script/
myapp_create.pl @ARGV[1..$#ARGV];

??

Please point out what I'm missing....

Cheers
t0m

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

zzbbyy at gmail

Jun 17, 2009, 11:25 PM

Post #6 of 9 (1461 views)
Permalink

Re: RFC: new helper api [In reply to]

On Thu, Jun 18, 2009 at 1:05 AM, Tomas Doran <bobtfish[at]bobtfish.net> wrote:

>
> On 17 Jun 2009, at 12:00, Zbigniew Lukasiak wrote:
>
>> I think the beginning would be to just let catalyst.pl run all the other
>> helpers.
>> Like:
>>
>> catalyst.pl MyApp model CatalystModelName DBIC::Schema MyApp::SchemaClass
>>
>> So you just add the MyApp at the start - and the rest goes just like it
>> was my_app_create.pl.
>>
>> If that is done - this should open the possibilities for all the other
>> modifications.
>>
>
> I don't see how this helps or hinders?
>
> Surely it means that catalyst.pl checks if it can 'cd' into the directory
> named by its first argument, then executes script/myapp_create.pl
> @ARGV[1..$#ARGV];
>

Hmm - I was thinking that running the helpers directly in Perl gives you
more control, but maybe you are right and it is more pragmatic to just
execute them via shell.

--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

bobtfish at bobtfish

Jun 18, 2009, 1:03 AM

Post #7 of 9 (1457 views)
Permalink

Re: RFC: new helper api [In reply to]

On 18 Jun 2009, at 07:25, Zbigniew Lukasiak wrote:
>
> Hmm - I was thinking that running the helpers directly in Perl
> gives you more control, but maybe you are right and it is more
> pragmatic to just execute them via shell.

But, you're running script/myapp_create.pl Foo Bar anyway - no shell
involved, and we can already change the behavior of that script?

Cheers
t0m

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

zzbbyy at gmail

Jul 27, 2009, 11:17 AM

Post #8 of 9 (1207 views)
Permalink

Re: RFC: new helper api [In reply to]

On Thu, Jun 18, 2009 at 10:03 AM, Tomas Doran<bobtfish[at]bobtfish.net> wrote:
>
> On 18 Jun 2009, at 07:25, Zbigniew Lukasiak wrote:
>>
>> Hmm - I was thinking that running the helpers directly in Perl gives you
>> more control, but maybe you are right and it is more pragmatic to just
>> execute them via shell.
>
> But, you're running script/myapp_create.pl Foo Bar anyway - no shell
> involved, and we can already change the behavior of that script?
>

I am using:

$helper->mk_app( $appname ) # this one works
...
$helper->mk_component ( # this one is where the problem is

i.e. I use the helper API. Unfortunately this checks $FindBin::Bin -
so it can be only run by a script in the right place (and that place
does not exists before the app is created) or else it requires an ugly
hack. What I would like to have is mk_component that would work
independently from where the binary is.

Cheers,
Zbigniew

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

devin.austin at gmail

Jul 27, 2009, 2:56 PM

Post #9 of 9 (1206 views)
Permalink

Re: RFC: new helper api [In reply to]

On Mon, Jul 27, 2009 at 12:17 PM, Zbigniew Lukasiak <zzbbyy[at]gmail.com>wrote:

> On Thu, Jun 18, 2009 at 10:03 AM, Tomas Doran<bobtfish[at]bobtfish.net>
> wrote:
> >
> > On 18 Jun 2009, at 07:25, Zbigniew Lukasiak wrote:
> >>
> >> Hmm - I was thinking that running the helpers directly in Perl gives you
> >> more control, but maybe you are right and it is more pragmatic to just
> >> execute them via shell.
> >
> > But, you're running script/myapp_create.pl Foo Bar anyway - no shell
> > involved, and we can already change the behavior of that script?
> >
>
> I am using:
>
> $helper->mk_app( $appname ) # this one works
> ...
> $helper->mk_component ( # this one is where the problem is
>
> i.e. I use the helper API. Unfortunately this checks $FindBin::Bin -
> so it can be only run by a script in the right place (and that place
> does not exists before the app is created) or else it requires an ugly
> hack. What I would like to have is mk_component that would work
> independently from where the binary is.
>
> Cheers,
> Zbigniew
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev[at]lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

Zbigniew:

I am working as we speak on unfucking Catalyst::Helper, ie Moosificating,
and making it much much much more sane to use as an API. Bear with me, but
please keep the notes coming on what's not working.

Thanks,

-Devin

--
Devin Austin
http://www.codedright.net
http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com