Re: [Catalyst] Additional scripts accessing the Model and Config?

2012-06-08 Thread Thomas Klausner
Hi!

On Fri, Jun 08, 2012 at 02:05:31PM -0400, Luis Muñoz wrote:
 
 But still, I would like to have access to the configuration data (for 
 instance, how to setup the database/ldap/whatever Model, etc). Does 
 that happen as well when using the class method?

We pack our config (which basically is a big hash) in a class. To 
provide the config to Catalyst, we use the class in my_app.pl (which is 
like my_app.(yml|json|ini|...). If we need the config in some other 
scripts, we just use the class there.

The non-Web code lives in classes (eg DBIC) that are used via Models in 
Catalyst, or directly (or some Model-like wrappers, if it needs to be) 
in other contexts.

Greetings,
domm


-- 
#!/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/


Re: [Catalyst] Should I create a new view for rendering a pdf in browser?

2011-11-09 Thread Thomas Klausner
Hi!

On Wed, Nov 09, 2011 at 03:59:50PM +0100, Jens Gassmann wrote:

 I use Catalyst::View::Wkhtmltopdf  - maybe Prince is better, but it is
 not open source like wkhtml. Also Catalyst::View::Wkhtmltopdf  supports
 Template Toolkit and could render your Templates without much
 modifications.

If you don't want to use an external binary, you could also use Webkit 
directly via Gtk3::Webkit though I'm not sure how stable / performant 
this is. Emmanuel gave a talk about this last weekend during the Twin 
City Perl Workshop: 
http://conferences.yapceurope.org/tcpw2011/talk/3836

Here's his script to take a screenshot in various formats:
https://github.com/potyl/Webkit/blob/master/screenshot.pl

I probably wouldn't embed this directly into Catalyst, but set up a 
seperate service, so maybe just using wkhtmltopdf is in fact simpler...

Greetings,
domm

-- 
#!/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/


Re: [Catalyst] fetching a model instance from a model instance

2011-10-27 Thread Thomas Klausner
Hi!

On Thu, Oct 27, 2011 at 08:53:12AM +0200, Dimitar Petrov wrote:

 Your should put your confirmAndGetUser method into
 MyApp::Schema::ResultSet::User, like:
 
 package MyApp::Schema::Result::User;
 ^^
shouldn't that be
  MyApp::Schema::ResultSet::User   ?


-- 
#!/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/


Re: [Catalyst] Where to put use

2009-02-18 Thread Thomas Klausner
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/


[Catalyst] How much chain?

2008-07-11 Thread Thomas Klausner
... do I need to hang myself?

I'm (finally) playing around with chained, and like it very much.
But now I have some sort of design question, on which I'd like to 
collect some feedback:

Say, you want to edit things. The general way of editing is the same for 
most things, only the thingies you want to edit differ (i.e. their 
fields).

(slightly OT, but some background: We want to use HTML::FormFu 
for actual form generation, but do not want to use the config-file 
aproach, but something like a 'registry' where each field and it's 
definition is stored (basically we have several different things using 
similar fields...))


What to you think is better:

A) lots of chain

package Thing:
use base 'Generic';
sub base : Chained('/') PathPart('thing') CaptureArgs(0) {}
sub setup_fields : Chained('item') CaptureArgs(0) {
# define a list of fields and store them in stash
}

package Generic;
sub item : Chained('base') PathPart('') CaptureArgs(1) {
# load thing and store in stash
}
sub show_form : Chained('setup_fields') Args(0) {
# take field list, make form, etc 
}

I'd end up with an URL like 
  /thing/123/setup_fields/show_form


B) Plain Old Methods

package Thing:
use base 'Generic';
sub base : Chained('/') PathPart('thing') CaptureArgs(0) {}
sub edit : Chained('item') Args(0) {
my ($self, $c) = @_;
$self-setup_fields($c, ... );
$self-make_form;
# 
}

package Generic;
sub item : Chained('base') PathPart('') CaptureArgs(1) {
# load thing and store in stash
}
sub setup_fields {}
sub make_form {}
sub handle_form {}

I'd end up with an URL like 
  /thing/123/edit
which IMO looks nicer.


So, is A) just overdoing chained? B) looks ok, but is it using chained 
to it's full potential?

I'd really like to hear some of your thoughts...

-- 
#!/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/


Re: [Catalyst] Anybody who fancies some LWP poking ...

2008-05-16 Thread Thomas Klausner
Hi!

On Thu, May 15, 2008 at 10:20:23AM -0400, John Goulah wrote:
 
 Since these fix tests, will these modules get patched and released
 with this applied?

Hm, actually I only notified Leon about the patches. I will also submit 
the patches directly to Andy (for WWW::Mechanize)

-- 
#!/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/


Re: [Catalyst] Anybody who fancies some LWP poking ...

2008-05-15 Thread Thomas Klausner
Hi!

On Sun, May 11, 2008 at 07:10:27PM +0100, Leon Brocard wrote:
 2008/5/10 Daniel McBrearty [EMAIL PROTECTED]:
 
  I'd like Leon's opinion on this. Forwarding to him again.
 
 I understand many bits of it but have given up trying to get it
 working. I would love a patch which passes tests on both old and new
 lib-www-perls.

Today we where hit by this, and I dug into the code...

The problems seems to lie in WWW::Mechanize and 
Test::WWW::Mechanize::Catalyst.

I was able to (sort of) fix it with the attached two patches.

T:W:M:C tests work after those patches (as do our tests...), but 
WWW::Mechanize spews some Parsing of undecoded UTF-8 will give garbage 
when decoding entitie warnings. And I'm not in the mood for utf8 
debugging ...

I have to say that I did not analyse the whole problem, and in fact we 
just downgrade to libwww-perl-5.808. But if these findings help someone 
with deeper knowledge to really solve the problem, I'd be delighted!

-- 
#!/usr/bin/perl  http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
diff -ur WWW-Mechanize-1.34/lib/WWW/Mechanize.pm WWW-Mechanize-1.34-patched/lib/WWW/Mechanize.pm
--- WWW-Mechanize-1.34/lib/WWW/Mechanize.pm	2007-12-10 07:31:20.0 +0100
+++ WWW-Mechanize-1.34-patched/lib/WWW/Mechanize.pm	2008-05-15 13:28:03.0 +0200
@@ -2148,7 +2148,7 @@
 # See docs in HTTP::Message for details. Do we need to expose the options there? 
 # use charset = 'none' because while we want LWP to handle Content-Encoding for 
 # the auto-gzipping with Compress::Zlib we don't want it messing with charset
-my $content = $res-decoded_content( charset = 'none' );
+my $content = $res-decoded_content();
 $content = $res-content if (not defined $content);
 
 $content .= _taintedness();
Only in WWW-Mechanize-1.34-patched/: Makefile.old
diff -ur WWW-Mechanize-1.34/t/local/log-server WWW-Mechanize-1.34-patched/t/local/log-server
--- WWW-Mechanize-1.34/t/local/log-server	2007-08-27 02:47:30.0 +0200
+++ WWW-Mechanize-1.34-patched/t/local/log-server	2008-05-15 13:14:10.0 +0200
@@ -88,7 +88,7 @@
   a href=/foo1.save_log_server_test.tmpLink foo1.save_log_server_test.tmp/a
   a href=/foo2.save_log_server_test.tmpLink foo2.save_log_server_test.tmp/a
   a href=/foo3.save_log_server_test.tmpLink foo3.save_log_server_test.tmp/a
-  a href=/o-umlautLöschen -- testing for o-umlaut./a
+  a href=/o-umlautLöschen -- testing for o-umlaut./a
   a href=/o-umlaut-encodedStouml;sberg -- testing for encoded o-umlaut./a
 
   table
diff -ru Test-WWW-Mechanize-Catalyst-0.42/lib/Test/WWW/Mechanize/Catalyst.pm Test-WWW-Mechanize-Catalyst-0.42-patched/lib/Test/WWW/Mechanize/Catalyst.pm
--- Test-WWW-Mechanize-Catalyst-0.42/lib/Test/WWW/Mechanize/Catalyst.pm	2008-04-29 21:25:55.0 +0200
+++ Test-WWW-Mechanize-Catalyst-0.42-patched/lib/Test/WWW/Mechanize/Catalyst.pm	2008-05-15 13:30:44.0 +0200
@@ -89,7 +89,6 @@
 
  # For some reason Test::WWW::Mechanize uses $response-content everywhere
  # instead of $response-decoded_content;
-$response-content( $response-decoded_content );
 }
 
 return $response;
___
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] uri_for problem

2008-03-05 Thread Thomas Klausner
Hi!

On Wed, Mar 05, 2008 at 10:50:07AM +0100, Emmanuel Quevillon wrote:

 I am trying to build some url from TT using uri_for sub but I encounter 
 some problem with it.

 When in my tt I have :
 [%- ourl = Catalyst.uri_for('/search?stype=seqidquery=') -%]

 when I click on it, I get an url that looks like :
 search%5C%3Fstype=seqidquery=

 Is there a way to get the proper url produce in the HTML page without 
 '%5C%3F' ?

The docs say:
  $c-uri_for( $path, @args?, \%query_values? )

translated to TT that should read
  [%  Catalyst.uri_for('search', { stype='seqid' } ) %]
(I think, but I constantly mix up how to defines hashes in TT)


-- 
#!/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/


Re: [Catalyst] [ANNOUNCE] New plugin: Catalyst::Plugin::Assets

2008-01-31 Thread Thomas Klausner
Hi!

On Mon, Jan 21, 2008 at 09:20:54PM -0800, Robert Krimen wrote:
 On Jan 20, 2008 7:59 PM, Matt S Trout [EMAIL PROTECTED] wrote:
  You seem to be using an 'assets' config key; please change this to
  'Plugin::Assets' and deprecate the old one. We're currently moving the 
  'core'
  plugins over to this standard so you should make the change as soon as
  possible to avoid getting live users with the wrong config key.
 
 Okay, I've gone ahead and made this change. The new version, with new
 config key preference and warning message, should be available on CPAN
 shortly.

Currently, Catalyst::Plugin::Assets is not available from CPAN anymore. 
Is there a reason for this? Or is it some CPAN hickup?

It's still on BackPAN, BTW:
http://backpan.cpan.org/authors/id/R/RK/RKRIMEN/Catalyst-Plugin-Assets-0.020.tar.gz

But if it won't be continued, I'd rather not use it :-)

-- 
#!/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/