Re: [Catalyst] root dir location
On 17 Jun 2009, at 13:51, Ben Vinnerd wrote: Where should the root dir (for templates) be? I thought it was at the same level as lib, script, and t. snip ...the INCLUDE_PATH isn't setup, and i have to manually add: At a guess, you deleted your Makefile.PL? 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] myapp_local.yml gets ignored
On 17 Jun 2009, at 14:50, Jochen Luig wrote: According to the ConfigLoader docs, 'local' is the default suffix for files used to override the main config, so AFAIU the above code is supposed to just work. Maybe I'm just not seeing the wood for the trees here, but are there any prerequisites for this to work that I may have overlooked? Erm, no. It should just work. I generated an example app with: catalyst.pl TestConfig, and applied the attached patch - this shows the local config happening. At a wild stab in the dark - is this an issue with the lifecycle of your application? I.e. is your app starting before you actually write the config file out? I guess that starting your test with strace -f and then searching for instances of the string 'myapp_local' in the output would be instructive about what is going wrong for you.. Cheers t0m 0001-Test-local-config-works.patch Description: Binary data ___ 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] ConfigLoader trouble
On 17 Jun 2009, at 11:16, Ben Vinnerd wrote: It's like ConfigLoader's setup() isn't being run, or it's choosing to ignore the MYAPP_CONFIG_LOCAL_SUFFIX i'm setting. I'm afraid the best way to debug this is likely to be brute force. Copy your apache config somewhere, mangle it to only run 1 child process, then try to start the app with strace -f, pipe the stdout and stderr to a file. You can then grep through that file for instances of myapp_.*\.(conf| yml|whatever). This should help you build a mental model of how it's going wrong (e.g. looking for the wrong filename, looking in the wrong place, just not looking etc). One you know what it's doing wrong in more detail then it'll be easier to work out how to debug/fix. 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] Database-backed sessions: Session::Store::DBI/DBIC and MSSQL
On 17 Jun 2009, at 21:34, Stuart Watt wrote: Since Session::Store::DBI can be set to use its own connection, I thought that might resolve it. Not completely, unfortunately, and now the error is due to the recommended use of a text column for the data. It seems the DBI+DBD::ODBC likes to require LongTruncLen set to a rather larger value than is the default (apparently the default can even be zero!), so you get truncation errors when reading any session data. Any session data at all? Can you be more specific - I'd guess that this should only hit you if the length is small, or if your sessions get large. Also, is there a different data type you can use without this behavior? (One that at least fails rather than silently truncating stuff would be good, for a start).. The way the statements are set up (in a batch) makes it hard to set this for one statement independently, and supposedly it needs to be set before a statement is prepared. Why not just arrange for it to be set by all queries done by the session handling? If you already have a dedicated DB connection for session data, why not use it? :) 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] root dir location
On 18/06/09 08:51, Tomas Doran wrote: At a guess, you deleted your Makefile.PL? Yes :O I didn't really want to bother with make on my webapp, so deleted that along with Changes and README. Cheers t0m, Ben ___ 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] root dir location
Ben Vinnerd wrote: On 18/06/09 08:51, Tomas Doran wrote: At a guess, you deleted your Makefile.PL? Yes :O I didn't really want to bother with make on my webapp, so deleted that along with Changes and README. Yeah, that'd get you. The lines in the generated Makefile.PL which say: # IMPORTANT: if you delete this file your app will not work as # expected. You have been warned. Are, actually, not lies. Catalyst uses the presence of a Makefile.PL to work out if your application has actually been installed, or if it is just running from a checkout. I totally see the 'I will never install' point of make being unneeded, but I personally like the possibility that I may one day run my apps somewhere other than my laptop (or, maybe I'll even buy a less crappy laptop). So keeping the dependencies in Makefile.PL up to date is a very worthwhile exercise; you can then just copy your app to another machine and say 'make installdeps', rather than suffer half an hour's frustration trying to start your app and failing. 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/
[Catalyst] Clean access to config from outside Cat?
I included this as part of a long question yesterday about
testing, but I realize that perhaps it's better as a separate
question.
Basically, I have a standard Catalyst config file, where
the database connection section looks like this:
Model::LibraryDB
schema_class Library::Schema::Main
connect_info DBI:mysql:host=localhost;database=library_test
connect_info library_test_user
connect_info library_test_password
connect_info
mysql_enable_utf8 1
/connect_info
/Model::LibraryDB
I'd like to get access to this information from a script
running outside of Catalyst. How can I do this cleanly?
I grab the file with:
my %config = Config::General-new($config_file)-getall;
But then this leaves me with ugliness like
$my user_name = $config{'Model::LibraryDB'}-{'connect_info'}-[1];
And getting the database name requires regexing the first
connect_info line. Is there some other Cat-approved way of
setting up the config file so that this information is easily
available both to an external program and to Cat? I suppose I
can put this into a plain variable up front, switch on
variable interpolation, and then include the variables in the
connect info, but I haven't seen this done with Cat before.
Jesse Sheidlower
___
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] Clean access to config from outside Cat?
2009/6/18 Jesse Sheidlower jes...@panix.com Basically, I have a standard Catalyst config file, where the database connection section looks like this: I'd like to get access to this information from a script running outside of Catalyst. How can I do this cleanly? Hi Jesse, I wrote an advent calendar article on this (bit out of date, but should do) http://www.catalystframework.org/calendar/2007/14 on CPAN see http://search.cpan.org/perldoc?Config::JFDI Cheers, Peter http://perl.dragonstaff.co.uk ___ 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] ConfigLoader trouble
On 18/06/09 08:57, Tomas Doran wrote: On 17 Jun 2009, at 11:16, Ben Vinnerd wrote: It's like ConfigLoader's setup() isn't being run, or it's choosing to ignore the MYAPP_CONFIG_LOCAL_SUFFIX i'm setting. I'm afraid the best way to debug this is likely to be brute force. No need - i tried putting back the Makefile.PL i deleted (as per other thread), and ConfigLoader (as if by magic) started working again. I really should read important notices a bit more :) Ben ___ 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] Clean access to config from outside Cat?
On Thu, Jun 18, 2009 at 01:51:28PM +0100, Peter Edwards wrote: 2009/6/18 Jesse Sheidlower jes...@panix.com Basically, I have a standard Catalyst config file, where the database connection section looks like this: [...] I'd like to get access to this information from a script running outside of Catalyst. How can I do this cleanly? Hi Jesse, I wrote an advent calendar article on this (bit out of date, but should do) Thanks, Peter. This is interesting, and I think I'll use this for something or other. But in this case, it doesn't really address the main question, which is that fishing this variable out of the haze in which it's currently in in the config file is a PITA. Thinking about it since I sent the original message, though, I think I will put them into variables that I will interpolate. Jesse Sheidlower ___ 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] Database-backed sessions: Session::Store::DBI/DBIC and MSSQL
On 18-Jun-09, at 4:01 AM, Tomas Doran wrote: Any session data at all? Can you be more specific - I'd guess that this should only hit you if the length is small, or if your sessions get large. No, the sessions were tiny, more or less all they held was the id for which project the user was working on. The field allocated was text type, and it looks like MSSQL basically throws a truncation error for long type, no matter how much data was actually in there. DBI permits this. This was something of a surprise. If I'd declared the type as a VARCHAR of some kind, I'd have got away with it. Unfortunately, you can't get away from the need to make a separate connection as easily. Also, is there a different data type you can use without this behavior? (One that at least fails rather than silently truncating stuff would be good, for a start).. Yes, a VARCHAR(4000) or so would probably do fine for my purposes. Although my actual solution was C::P::Session::Store::Delegate with some additional logic to delegate to my existing user data model, which has a bunch of non-session stuff. This eventually worked well, when I finally figured the requirement for this to support any additional fields, and to keep user and session data separate. It even seemed to handle the overlapping query issues. DBIC saved the day (again!). The way the statements are set up (in a batch) makes it hard to set this for one statement independently, and supposedly it needs to be set before a statement is prepared. Why not just arrange for it to be set by all queries done by the session handling? If you already have a dedicated DB connection for session data, why not use it? :) That would have worked fine, but DBIC handles all this directly, so delegating to that solved all the issues. I guess my comments should really be read as in anyone is ever patching C::P::Session::Store::DBI, here are a some things that could probably be added. In its out of the box form, it would have needed an override or two to work. As it is, C::P::Session::Store::Delegate is working very smoothly, and running stable with MSSQL. 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/
[Catalyst] ajax character encoding issue solved, but WHY?
I had a character encoding issue that I finally solved, but I don't understand why the fix works. I'm hoping someone can explain this to me! The issue was that non-ascii chars were appearing as junk BUT only when retrieved via ajax calls. Otherwise, they displayed fine. The junk display was due to them being interpreted as ISO-8859-1, but I could not figure out why the browser was interpreting that way. All my data is handled as UTF-8. The problem was fixed by calling utf8::decode on the data prior to sending back via ajax. BUT WHY? I am using the JSON view to render ajax responses, and it sets the charset header correctly to UTF-8. Of course, even when you decode, perl still represents as internal utf8. But why should this be necessary? Thanks! -- == http://www.bikewise.org 2People citizen's network for climate action: http://www.2people.org Greater Seattle Climate Dialogues: http://www.climatedialogues.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/
