Re: [Catalyst] DBIC::Schema issue - out of ideas [ more info ]
Hello, Dermot and Alejandro, Thanks for your help. Yes, they are very good hints :) I tried them and I learnt more about the Catalyst framework. I looked at how I executed the script and I think I figured out why. I ran myApp_create.pl within the script subdirectory. For some reason, the files are not generated in the right places. I have reexecuted myApp_create.pl from outside 'scripts' and am now getting another error (which I think is trivial) when I run myApp_server.pl In short: Never ever myApp_create.pl in the scripts directory level. Don't know why it is such (which I think is silly cause we should be able to run the any damn script in the directory level which it is made in without problems). Ta! K. akimoto Quoting Dermot paik...@googlemail.com: 2009/2/18 kakim...@tpg.com.au: Hello Dermot, sorry, you're right. Yes, I could not find myAppDB::Listing myself. I ran the following command for generating the static schema manually. myApp_create.pl model myAppDB DBIC::Schema myApp::Schema create=static dbi:Pg:dbname=myApp myAdminUser mypassword Where in catalyst do we get Catalyst to recognise all the static files found under Schema ? In lib/myApp/Model/DB.pm It should look something like: __PACKAGE__-config( schema_class = 'myApp::myAppDB', ... Your command says Create a schema under the directory 'myAppDB', so they should be under lib/myApp/myAppDB/ They probably are there as *.new (as Alejandro says) This whole issue can be quickly resolved if you can search/grep through the files in ~/Controller/* and/or ~/myAppDB/* to find out how is trying to use Listing.pm. Does you this table exist in you DB? Good luck, you'll get there eventually :) Dp. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Where to put use
On Wednesday 18 February 2009, Dermot wrote: One of my controller is starting to use a lot of other modules like File::Find...etc but they are usually confined to one subroutine or method. It's most common to see all the use statements at the top of the package but I have seen instances where they are declared within the Sub block. Is there an advantage is declaring the use of modules, that are only used by a single subroutine, in that subroutine? For perl it doesn't matter where you put this definition. Personaly I expect to find the 'use' at the top of the sources. Not in in middle of the file. At least I would expect it in a middle of a subroutine. Just my 2 cents. -- So long... Fuzz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] DBIC::Schema issue - out of ideas [ more info ]
Hello, Dermot, Replies are as per below. Quoting Dermot paik...@googlemail.com: myApp_create.pl model myAppDB DBIC::Schema myApp::Schema create=static dbi:Pg:dbname=myApp myAdminUser mypassword Your command says Create a schema under the directory 'myAppDB', so they should be under lib/myApp/myAppDB/ I beg to differ. The files are created within myApp/lib/myApp/Schema and myApp/lib/myApp/Schema.pm They probably are there as *.new (as Alejandro says) Nope. This whole issue can be quickly resolved if you can search/grep through the files in ~/Controller/* and/or ~/myAppDB/* to find out how is trying to use Listing.pm. Does you this table exist in you DB? Yes the table exists. I ran the myApp_create.pl script again outside of the 'scripts' directory and running myApp_server.pl is ok except I got another error (small one). I found that when I add relations into the ORM files (ie. Listings.pm, Users.pm), I was using the notation of __PACKAGE__-has_many( 'listings' = 'myAppDB::Listings', 'manager_id'); That should be right because 'myAppDB' to my understanding, is how Catalyst will recognise my schema (as defined in the myApp_create.pl call above). I know logically, it should be 'myApp::Schema::Listings' as that package can be found in lib/myApp/Schema/Listings.pm ' Very confused here. Can anyone please enlighten me?? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] DBIC::Schema issue - out of ideas [ more info ]
2009/2/18 kakim...@tpg.com.au: lib/myApp/myAppDB/ I beg to differ. The files are created within myApp/lib/myApp/Schema and myApp/lib/myApp/Schema.pm What not Schema/myAppDB? All of these question really belong on the DBIc mailing list which is here: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class Yes the table exists. I ran the myApp_create.pl script again outside of the 'scripts' directory and running myApp_server.pl is ok except I got another error (small one). I found that when I add relations into the ORM files (ie. Listings.pm, Users.pm), I was using the notation of __PACKAGE__-has_many( 'listings' = 'myAppDB::Listings', 'manager_id'); That should be right because 'myAppDB' to my understanding, is how Catalyst will recognise my schema (as defined in the myApp_create.pl call above). I know logically, it should be 'myApp::Schema::Listings' as that package can be found in lib/myApp/Schema/Listings.pm ' Very confused here. Can anyone please enlighten me?? I'm going to do something horrid and point you at the documentation: http://search.cpan.org/~ribasushi/DBIx-Class-0.08012/lib/DBIx/Class/Relationship.pm#has_many and http://search.cpan.org/~ribasushi/DBIx-Class-0.08012/lib/DBIx/Class/Schema.pm You created you Schema with DBIx::Class::Schema. If you had used myApp_create model myApp::Model, your model would reside under the model directory. Instead you a a Schema.pm file the points resolves everything to the files with the the model name you handed to it. I not expert enough to say much more and I fear I might give incorrect information if I try and summarise why you use 'myAppDB::Listing' and not the full path (i suspect the latter woudl work though. Good luck, Dp.. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Where to put use
Dermot escribió: Hi, This might be a daft question but I'll chance it. One of my controller is starting to use a lot of other modules like File::Find...etc but they are usually confined to one subroutine or method. It's most common to see all the use statements at the top of the package but I have seen instances where they are declared within the Sub block. Is there an advantage is declaring the use of modules, that are only used by a single subroutine, in that subroutine? I tend to use Module::Load to load seldom used modules at runtime to reduce loading time and memory footprint. Cheers, Jose Luis Martinez jlmarti...@capside.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
I've actually done the reverse switch. Although I was a Perl developer for a good while, I previously used Apache::ASP and real ASP on Windows, with raw DBI and a hand-crafted search engine for most of this time. I then had to pick up Java and Spring with Hibernate for a while, for a second project. Since I started on my current task, which involved a large legacy code base in Perl, taking up Catalyst with DBIx::Class has been a great experience, as I get all the concepts from Spring and Hibernate with the development simplicity and CPAN assistance of Perl. Also, many of my colleagues have basic Perl, mostly pre-OO scripty style. Some of it is truly awful code!! Even they are beginning to see the flexibility that Catalyst has started to add into the development. We're now trying to recruit additional staff, and as Catalyst is a rare (and pricey) skill, we're also looking at Java folks, ideally with some knowledge of Spring and Hibernate, as a good base to move into Catalyst. There are still a few things I miss from Spring - notably the flexibility of its dependency injection for configuration. Configuration in Catalyst was actually far the hardest issue for me, and I still find it a little awkward. We began with YAMLs, and I still regret this from time to time. But this was an area where the examples were less detailed than helped the transition for me. Also, we found some highly inexplicable errors -- largely where Module::Pluggable loads everything in @INC, even when it is not where you expected. (PERL5LIB had been set to an old site, and loaded old components with different names.) For me, configuration is an area where the multiple alternatives really is a problem for Catalyst. My colleagues (and our clients) struggle with YAMLs. I'd rather one strongly preferred syntax was clearly set (and documented with detailed examples), although with an API that allows code to be used, through which others can be used for legacy apps. All the best Stuart Dave Rolsky wrote: On Tue, 17 Feb 2009, bill hauck wrote: I'm trying to put together a project to rewrite a job tracking database currently running in FileMaker. The functionality and scope of the job tracking system has changed so instead of throwing more money in a proprietary, closed system that requires a costly application on each desktop I'm suggesting writing it as a web application with Perl Catalyst. The only problem is that I've been told we would have to use Java Struts since it's our corporate standard for web applications. Perl, ironically, is used in quite a few places in the company, mainly in utility scripts. However, since we don't have anyone whose job title is Perl developer we can't use it for web applications. This is hardly unreasonable. I've worked at a number of smaller shops where we were developing a Perl-based app. If a developer had decided that they wanted to throw together some important tool in Java (or Python or Haskell or Smalltalk or ...), that would have been problem. The investment in a language is bigger than just the programmers, even. You have build deployment tools, automated testing setups (you do, don't you? ;), sysadmin knowledge, packaging infrastructure, and so on. Some of that may be language-agnostic, but often a lot of it ties into the language and its tools. Once you've made that investment, it makes sense to stick with it. Just because Catalyst and Perl are great tools for webapps doesn't mean that they're the _right_ tool at your job. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */ -- Stuart Watt ARM Product Developer Information Balance ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: New to Catalyst questions
On Tue, Feb 17, 2009 at 6:06 PM, Trevor Phillips trevor.phill...@gmail.com wrote: On Tue, Feb 17, 2009 at 5:32 AM, Jay Kuri j...@ion0.com wrote: My working list is as follows (in no particular order.) 1) 'Getting' DBIx::Class (starting from a straight SQL-users point of view) I'm new to Catalyst, having started to look into it a few months back (and now developing several apps in it). The auto-schema stuff on DBIx::Class was great. All the has_many many_to_many it took a while to wrap my brain around, and I'm still a bit fuzzy on some of it, but referring back to the docs, I can figure it out. Trying to do a moderately complex SQL query in DBIx::Class is a nightmare! Sometimes I wish I could just write out the SQL myself - even if it's chunked up into fields, condition, join, etc... This is called a learning curve :) When you first started to learn SQL, you wrote very simple queries and worked your way up. I've been using DBIC for a few years, and now I have resultset methods that can be chained so I can filter and refine queries in ways I would never even expect. Sure, sometimes I get frustrated because I can write the SQL but can't quite sort out how to do it in DBIC but I can at least patch DBIC! -J ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Where to put use
* Jose Luis Martinez jlmartinez-lists-catal...@capside.com [2009-02-18 15:35]: I tend to use Module::Load to load seldom used modules at runtime to reduce loading time and memory footprint. This is counterproductive in a long-running, fork()ing server. If you load all modules up front then they will only be loaded once and each child processes will have a copy already loaded at the time of fork(), which also means child processes will start out sharing more memory with the parent (and therefore probably with other children). If you load the modules as late as possible, then each child process will have to load the module separately and will not share the necessary memory with any other process. But you can use prefork.pm[1] to have your cake and eat it. [1]: http://search.cpan.org/dist/prefork/ Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] DBIC::Schema issue - out of ideas [ more info ]
Reply is as per below I'm going to do something horrid and point you at the documentation: http://search.cpan.org/~ribasushi/DBIx-Class-0.08012/lib/DBIx/Class/Relationship.pm#has_many and http://search.cpan.org/~ribasushi/DBIx-Class-0.08012/lib/DBIx/Class/Schema.pm You created you Schema with DBIx::Class::Schema. If you had used myApp_create model myApp::Model, your model would reside under the model directory. Instead you a a Schema.pm file the points resolves everything to the files with the the model name you handed to it. K.akimoto: hi, 1) Please read the latest update on this thread which I posted. I found the solution 2) Please read the command which I used properly. a) myApp::Schema is used hence, the ORM files will be created in 'lib/myApp/Schema'. I have looked at the output and it's confirmed. b) the script/myApp_create.pl command is: myApp_create.pl model myAppDB DBIC::Schema myApp::Schema create=static dbi:Pg:dbname=myApp myAdminUser mypassword ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] DBIC::Schema issue - out of ideas [ more info ]
On 18 Feb 2009, at 10:43, kakim...@tpg.com.au wrote: In short: Never ever myApp_create.pl in the scripts directory level. Don't know why it is such (which I think is silly cause we should be able to run the any damn script in the directory level which it is made in without problems). From a quick scan of the changelog, I make that as being fixed in 2005! What version are you running, as I certainly can't replicate this in any of my applications? If you create a new application, and then try to run the create, can you make it happen again, and if so please cough up the command line as it needs fixing! :) Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
--- On Wed, 2/18/09, Kieren Diment dim...@gmail.com wrote: From: Kieren Diment dim...@gmail.com Subject: Re: [Catalyst] RFC: The paradox of choice in web development To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Wednesday, February 18, 2009, 7:41 AM On 18/02/2009, at 5:55 PM, Dave Rolsky wrote: This is hardly unreasonable. I've worked at a number of smaller shops where we were developing a Perl-based app. If a developer had decided that they wanted to throw together some important tool in Java (or Python or Haskell or Smalltalk or ...), that would have been problem. The investment in a language is bigger than just the programmers, even. You have build deployment tools, automated testing setups (you do, don't you? ;), sysadmin knowledge, packaging infrastructure, and so on. Some of that may be language-agnostic, but often a lot of it ties into the language and its tools. Once you've made that investment, it makes sense to stick with it. Just because Catalyst and Perl are great tools for webapps doesn't mean that they're the _right_ tool at your job. Yes indeed. To balance that, management also need to work with the idea that rules are not dogmatic but designed for practical purpose. In my (academic - research and practical) experience, the larger the organisation, the more likely they are to believe dogma is more important than pragmatism, especially if you go through the official IT channels. If you go through the unofficial channels this may change, depending on the structure of the organisation, and the quality of your unofficial channels. No, I totally understand that. If the company is using Java, PHP, Python, etc. then the other projects should use the same language if possible. Um, if by automated testing you mean sending an email to the crew and saying, Ok, give it a try ... then, yeah, we've got automated testing. However, we don't really have Java developers for this project. Sure, the company has lots of Java developers but none that are funded by us (corporate communications) and available. We don't really have any funding for the project, either, so a contractor is out as well. I proposed that we write the application in Perl using Catalyst since I know Perl pretty well and my system administrator needs to learn it since many utilities have been / will be written in Perl. I guess I could learn Java, Servlets, and JSPs, but it'll take me a lot longer to write than in Perl. And it'll be a whole lot less fun. Cheers bill ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
2009/2/19 * Template::Toolkit * Text::Template * Text::FastTemplate * Text::Templar * HTML::Template * HTML::KTemplate * HTML::Mason * HTML::Seamstress * dTemplate * Jemplate Yes there is, at first glance, a lot of choice but is there. I would say TT and Mason are the only realistic choices (for HTML). And ONE of the reasons why is because they have both been published and by the patron of Perl, O'Reilly. Unless your being published by O'Reilly (or Addison) your not hitting the right audience. There is lot's of choice out there but you don't have to dig very far to find out what best is. Dp. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: New to Catalyst questions
On Feb 17, 2009, at 9:06 PM, Trevor Phillips wrote: I'm pretty new to the Catalyst community, and still very much a Catalyst newbie. I don't know how open this list is to having the same n00b questions asked over over again. I'd be happy to write up a few howto's myself, as I discover stuff, but I'm not confident I'm doing things the right way anyway, or if people would care about the same topics I struggle with, or where the best place to document this sort of Cookbook/FAQ stuff is... Welcome! We're all on this list because we either use or care about this framework. Help yourself, and others! http://dev.catalystframework.org/wiki/ Kenny ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Where am I? ;-)
Hi, with this somewhat philosophic question, I want to know, how a Controller knows, which of its action is currently active (p.ex. displayed to the user). And a similar question: How does the root controller know what other controllers are available in the app? Thanks Jens -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New version of InstantCRUD
Just one more thought on collaboration in general: let's find some elements in each other work that we would like to collaborate on, let's not strive to steer the other project in full into the direction of our wishes. Let's divide the projects so that later each of us will be able to assemble his own ideal solution out of it. Zbigniew On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier alexander.hartma...@t-systems.at wrote: Would be great if we could combine our efforts instead of creating even more choices for the users of cat in form of InstantCRUD, Controller::DBIC::API and so on (http://dev.catalyst.perl.org/wiki/crud). - Alex aka abraxxa Am Montag, den 16.02.2009, 21:44 +0100 schrieb Zbigniew Lukasiak: Looks like we are again discussing CRUD in Catalyst - so I decided to finally update InstantCRUD and release it to CPAN. It is still experimental. It is a 'scaffolding' - like the Rails one - it generates a CRUD application for a given dsn. Some more random thoughs: http://dev.catalystframework.org/wiki/crud/instantcrud and http://dev.catalystframework.org/wiki/crud/crud_and_rest (one caveat I completely disagree with the Preliminary URI naming guidelines). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Where am I? ;-)
I think more interesting is the question about: which action can the
user visit? With different roles not every user could visit /admin, but
it would be great to know that while building the navigation/links. And
only configurate that at one point!
sub admin :Local :ACL('role:admin') {...}
And than the question: $self-action_for('admin')-can_visit or similar.
Exists something like that?
Currently i build with Authorization::ACL the deny/access rules and in
every template i make a check for the rules needed for a link. And i
cant use one configuration :-/
Jens Schwarz schrieb:
Hi,
with this somewhat philosophic question, I want to know, how a Controller
knows, which of its action is currently active (p.ex. displayed to the user).
And a similar question: How does the root controller know what other
controllers are available in the app?
Thanks
Jens
--
Mit freundlichen Grüßen
Felix Antonius Wilhelm Ostmann
--
Websuche Search Technology GmbH Co. KG
Martinistraße 3 - D-49080 Osnabrück - Germany
Tel.: +49 541 40666-0 - Fax:+49 541 40666-22
Email: i...@websuche.de - Website: www.websuche.de
--
AG Osnabrück - HRA 200252 - Ust-Ident: DE814737310
Komplementärin: Websuche Search Technology
Verwaltungs GmbH - AG Osnabrück - HRB 200359
Geschäftsführer: Diplom Kaufmann Martin Steinkamp
--
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Where to put use
Hi!
On Wed, Feb 18, 2009 at 10:51:06AM +, Dermot wrote:
One of my controller is starting to use a lot of other modules like
File::Find...etc but they are usually confined to one subroutine or
method. It's most common to see all the use statements at the top of
the package but I have seen instances where they are declared within
the Sub block. Is there an advantage is declaring the use of modules,
that are only used by a single subroutine, in that subroutine?
sub find_files : Local {
use File::Find;
...
...
}
'use' is executed at compile time, not runtime, so as soon as Perl sees
a 'use Foo' statement during parsing the code, it loads the module.
If you want to conditionally load a module (or only load it for some
sub), you'll have to use 'require' (possibly followed by 'import').
Or use some of the CPAN modules helping with this.
(see this old talk from me:
http://domm.plix.at/talks/2005_braga_using_use/index.html )
But I'd guess this would only make sense for a huge module that get's
used very seldomly (i.e. the action in question isn't called very often)
In the end your idea sounds like premature optimisation to me :-)
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
