[Catalyst] OT - long game phishing

2016-07-14 Thread Darren Duncan
I just noticed that a list subscriber m.j.co...@asitis.co.uk seems to have been 
hacked and the hacker is playing a longer game, sending phishing email to this 
list and a bunch of others at infrequent intervals to try and avoid a security 
response.


Specifically, the catalyst@lists.scsys.co.uk list has now received 3 phishing 
messages from that sender over a 6 month interval, on 2015 Dec 23, 2016 Apr 23, 
and 2016 Jun 19.


Anyway, those administering this list or others this account is posting to 
should escalate some security response, at least a boot from the list and 
optionally a report to their email host.


-- Darren Duncan

___
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] An MVC logic separation conundrum

2016-03-09 Thread Darren Duncan
The best option is to keep the concerns separated.  Models should always take 
their inputs via explicit arguments for a Model-specific API, and they should 
not have any knowledge of or direct access to a Controller.  If this means you 
have to bundle up a larger amount of data in the Controller so the data passage 
is clean, so be it, that is the lesser evil. -- Darren Duncan


On 2016-03-09 11:03 AM, Chris Welch wrote:

Hi

This is more of a general MVC question, but hopefully it's okay to ask in here.

I've set up a model to generate data in iCal format (see my previous thread and
thanks for the responses on that), but it has thrown up an interesting general
logic separation question that I don't know the answer to.

By way of an example, I'm generating iCal events for a data table called
team_matches (DBIx::Class model name TeamMatch).  I was hoping, as would seem to
be the cleanest way to do it, to have a result class "helper" method, such that
on each match object I could call something like: $match->generate_ical_data,
which would generate a hashref of calendar values to be passed through to my
MyApp::Model::ICal module that will generate the actual data.  The problem with
this is that certain properties require access to the Catalyst application: for
example, there's a uri property, the value for which will need to be generated
by $c->uri_for_action and since this particular application has the ability to
be multi-language (via CatalstX::I18N) the description value needs to be
generated by $c->maketext.

All of this brings up a quandary: there are only two ways around this that I can
see:
   * Pass $c into the $match->generate_ical_data method (which I know is
STRONGLY discouraged and very very bad).
   * Generate the hashref in the controller (which potentially makes for a
'fatter' controller than you ideally want and I'm trying to stick to the ideals
here).

I'm guessing the preference of the above options should really be the latter
(which is what I'm currently doing in the interim), but I am hoping that there's
a super-clever way that I've not thought of that someone can tell me I've
completely overlooked?

Thank you in advance.


Chris



___
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] Fw: new message

2015-12-10 Thread Darren Duncan

Looks like someone's been hacked.

___
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] Using Catalyst on MS SQL DB that has tables with no primary keys

2012-09-14 Thread Darren Duncan

Brian Katzung wrote:
If I recall correctly, I read in a cookbook somewhere (can't seem to 
find it now) that for rows with no primary key, you can use:


__PACKAGE__-set_primary_key(__PACKAGE__-columns);

(making the entire row be a multi-column primary key).


Well that is indeed how things should work; when there is no primary or unique 
key explicitly defined, there should be an implicit one ranging over all the 
columns.  However, SQL doesn't work that way and would allow duplicate rows, and 
so then the question is what behavior do you expect your Perl layer to have?  If 
you edit a duplicate row, is it supposed to change all copies or just one? -- 
Darren Duncan



On 2012-09-14 14:53, Derek W wrote:

Ah, you meant just on Catalyst side, to tell it that the id column is
the primary.  I didn't think of that.  Thanks!  I'll give that a shot.

On Fri, Sep 14, 2012 at 11:40 AM, Robert Wohlfarth
rbwohlfa...@gmail.com wrote:

On Fri, Sep 14, 2012 at 1:31 PM, Derek W derekwro...@gmail.com wrote:

Thanks, I figured that would probably fix it, but the problem is I am
not allowed to make any changes to the DB structure itself.  I suppose
I need to convince them why it's in the best interest to have a
primary key...

You can set the primary key in the schema file. For example, add a 
line like
__PACKAGE__-set_primary_key( id ); to 
lib/MyApp/Schema/Result/MyTable.pm.

You do not need to change the database. DBIx::Class will then use id
whenever it wants a primary key.

--
Robert Wohlfarth


___
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] [JOB] Looking for Telecommute Web Developer

2012-07-05 Thread Darren Duncan
Speaking for myself, I got my current (good) job because the company also posted 
it to the Catalyst list, in addition to jobs.perl.org. -- Darren Duncan


Frank Kumro wrote:

I believe the opening is posted on jobs.perl.org too (or will very
soon). The opening is sent to the list because some of our other devs
(including myself) found the job via this list.

-Frank

On 07/05/2012 05:40 PM, Len Jaffe wrote:

Doesn't jobs.perl.org http://jobs.perl.org exist for posting perl jobs?
L.
--
lenja...@jaffesystems.com mailto:lenja...@jaffesystems.com  
614-404-4214 www.volunteerable.net

http://www.volunteerable.net
Proprietor: http://www.theycomewithcheese.com/ - An Homage to Fromage
Greenbar http://www.greenbartraining.org/: Grubmaster: 2012-2009, Grub
Asst: 2008, Trained: 2007.



___
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] Wiki is Temporarily Unavailable

2012-07-02 Thread Darren Duncan

Dimitar Petrov wrote:

It should be back in a while.

Cheers,
Dimitar

On Mon, Jul 2, 2012 at 10:11 AM, sc...@simpzoid.com 
mailto:sc...@simpzoid.com wrote:


Just in case nobody has noticed the Catalyst WiKi is down and has
been for
at least a day.


So is this the leap-second bug or the power outage or something else? -- Darren 
Duncan


___
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] Caching SQL results for speed...?

2011-04-13 Thread Darren Duncan

will trillich wrote:
Okay, after some perl -D:NTYProf tester.pl http://tester.pl with 200 
iterations:

70% of the time is taken up in five modules:
1) SQL::Abstract
2) DBIx::Class::ResultSet
3) Class::Accessor::Grouped
4) DBIx::Class::Storage::DBI
5) HTML::FormHandler::Field
...because in 200 iterations they were called millions of times each. 
(The form requested has several select/option menus.)


So, several 5000s (millions / 200) of calls for a single screen?  That sounds 
like a lot for one screen.  Do you need that much? -- Darren Duncan


___
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] Which Form Validation Libs?

2010-11-29 Thread Darren Duncan

Eric Berg wrote:
I see that there are a number of form validation libraries that purport 
to work with Catalyst.  I've been using CGI::Formbuilder for years and 
have been relatively happy with it.


I need something for my new Catalyst app.  I have already created my 
forms in my TT templates, but I need validation for most of the regular 
stuff, including zip codes, states, credit card info, etc.


You guys got any  recommendations?

Thanks.

Eric


Its not form specific, but currently I like using MooseX::Types and 
MooseX::Types::Structured for validation.


You can use these to declare validators in a declarational fashion for each data 
type you have, or use pre-defined ones for some common cases.  For each type 
Foo, it provides an is_Foo function you can test inputs with.


With MooseX::Types::Structured in particular and its Dict type constructors, 
you can define a type to represent the form as a whole, so it will check you 
have all the right fields and their contents; that said, while using a Dict 
for the whole form will tell you if any field was done incorrectly, it alone 
won't say which field, so whether you might want to use it depends on how 
specific you want input error messages to be.


-- Darren Duncan

___
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] Question about Chained Controller

2010-11-14 Thread Darren Duncan

woosley. xu. wrote:

Hi All,
 I am quite a beginner for Catalyst. When I used Chained Controller 
to handle  some permission pages, I met a problem

snip

I don't know if others do it the way you have, but in my limited experience I 
found that an auto method is the most appropriate way to intercept people 
going to a protected section with a login screen.  Also, I don't recognize the 
$c-flash part of your code; where is flash() defined? -- Darren Duncan


___
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] example of sep db config args (was Re: Accessing DB from external model)

2010-11-08 Thread Darren Duncan

Darren Duncan wrote:

sub _lazy_default_for_dbc {
my ($process) = @_;
my $dbc = try {
my $dsn = sprintf( q{dbi:Pg:dbname=%s;host=%s;port=%s},
$process-db_name(), $process-db_host(), 
$process-db_port() );

my $dbc = DBIx::Connector-new( $dsn,
$process-db_user(), $process-db_pass(),
{ 'RaiseError' = 1, 'AutoCommit' = 1 },
);
my $dbh = $dbc-dbh();
# SET UP ANY OTHER CLIENT SETTINGS HERE ON $dbh
return $dbc;
}
catch {
confess sprintf( q{Could not open connection to Pg server or 
db: %s}, $_ );

};
return $dbc;
}


As an addendum ...

While this isn't relevant to the main point of my post, which is how to separate 
config params for a database connection used by a Catalyst app, I noticed that 
my code had a different flaw, which is now hopefully corrected in the version below:


sub _lazy_default_for_dbc {
my ($process) = @_;
my $dbc = try {
my $dsn = sprintf( q{dbi:Pg:dbname=%s;host=%s;port=%s},
$process-db_name(), $process-db_host(), $process-db_port() );
my $dbc = DBIx::Connector-new( $dsn,
$process-db_user(), $process-db_pass(), {
RaiseError = 1,
AutoCommit = 1,
Callbacks  = {
connected = sub {
my ($dbh) = @_;
$process-_do_post_connect( $dbh );
},
},
},
);
return $dbc;
}
catch {
confess sprintf( q{Could not open connection to Pg server or db: 
%s}, $_ );

};
return $dbc;
}

sub _do_post_connect {
my ($process, $dbh) = @_;
# SET UP ANY OTHER CLIENT SETTINGS HERE ON $dbh
}

The flaw is that if DBIx::Connector had to reconnect to the database, an event 
that users shouldn't have to be aware of having occurred, the client settings 
done by SET UP ... would not have been done on the new connection.


-- Darren Duncan

___
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] example of sep db config args (was Re: Accessing DB from external model)

2010-11-06 Thread Darren Duncan
P.S.  While answering a question, this email could be adapted for a Catalyst 
cookbook / etc entry if one wants to.


Octavian Rasnita wrote:

I agree and yes, that sample code could give bad ideas.
In my case I am the app designer, coder, maintainer, site admin, everything but 
the web designer and I've done it so for not specifying these settings in more 
places.


I have the same role in my situation, but I also designed the project so it is 
easier for someone else to come along and maintain it.



Is there another place where I could put these settings for a certain DBIC 
schema?
For example, can I put them in the MyApp/Schema.pm, orsomewhere else? Can you 
give an example?


I can show you a simplified version of what I have done, but with any 
identifying details changed to protect the innocent.  My version uses straight 
DBI+DBIx::Connector rather than DBIC but you should be able to adapt the design 
to DBIC or any other database API; my version is also Pg-specific but only minor 
tweaks would be needed to work with something else.  Since this is from a 
proprietary application rather than a CPAN module, I can get away with requiring 
and exploiting the latest Perl version, 5.12.x, rather than giving those up to 
support older Perls.


1.  Here is the relevant portion of MyApp.conf, which uses Config::General as 
per Catalyst's default these days.


Model DB
args
db_host localhost
db_port 5444
db_name myproj_v1_db
db_user myproj_v1_usr_myapp
db_pass myapppass
/args
/Model

2.  Here is the slightly simplified version of MyApp/Model/DB.pm, which uses 
Catalyst::Model::Adaptor, and in such a way to support different class and file 
names (requires 0.09+):


use 5.012002;
use utf8;
use warnings FATAL = 'all';

use MyDBMSLib 0.001;

package MyApp::Model::DB 0.001;

use parent 'Catalyst::Model::Adaptor';  # requires = 0.09

__PACKAGE__-config( class = 'MyDBMSLib' );

1;

3.  Here is a complete/template content of MyDBMSLib.pm; the original had 
multiple classes in it but I removed the other ones and simplified the main one; 
the original file was named after a different package than what I kept:


use 5.012002;
use utf8;
use warnings FATAL = 'all';

use DBIx::Connector;
use DBI;
use DBD::Pg;

###
###

{ package MyDBMSLib 0.001; # class

use namespace::autoclean;

use Try::Tiny;

use Moose;

has 'db_host' = (is = 'ro', isa = 'Str', required = 1 );
has 'db_port' = (is = 'ro', isa = 'Int', required = 1 );
has 'db_name' = (is = 'ro', isa = 'Str', required = 1 );
has 'db_user' = (is = 'ro', isa = 'Str', required = 1 );
has 'db_pass' = (is = 'ro', isa = 'Str', required = 1 );

# This is the actual (as far as we're concerned) Pg database connection
# object; the connection is opened the first time the _dbc attr is read
# and it is closed when the _dbc attr is garbage collected.
has '_dbc' = (
is   = 'ro',
isa  = 'DBIx::Connector',
required = 1,
lazy = 1,
default  = \_lazy_default_for_dbc,
);

###

sub _lazy_default_for_dbc {
my ($process) = @_;
my $dbc = try {
my $dsn = sprintf( q{dbi:Pg:dbname=%s;host=%s;port=%s},
$process-db_name(), $process-db_host(), $process-db_port() );
my $dbc = DBIx::Connector-new( $dsn,
$process-db_user(), $process-db_pass(),
{ 'RaiseError' = 1, 'AutoCommit' = 1 },
);
my $dbh = $dbc-dbh();
# SET UP ANY OTHER CLIENT SETTINGS HERE ON $dbh
return $dbc;
}
catch {
confess sprintf( q{Could not open connection to Pg server or db: 
%s}, $_ );

};
return $dbc;
}

###

# PUT OTHER USEFUL MyDBMSLib METHODS HERE

###

__PACKAGE__-meta()-make_immutable();

} # class MyDBMSLib

###
###

1;

For your version, mainly just replace _dbc with an object of whatever initial 
class you have with DBIC that takes the db connection config args.


Your analogy to _lazy_default_for_dbc is where you feed DBIC its actual config 
args, where some can be defined in MyDBMSLib itself and others taken from the 
config file.


-- Darren Duncan

Re: [Catalyst] Accessing DB from external model

2010-11-05 Thread Darren Duncan

Mike Raynham wrote:
Here, the connection information is moved from MyApp::Model::DB to 
MyApp::DB, and then Catalyst::Model::Adaptor is used to glue 
MyApp::Model::DB to MyApp::DB.  Is it a good idea?  MyApp::Model::DB 
appears to be part of the Catalyst application, so if I want to access 
the database from an external model, it makes sense to me to move the 
connection code outside of the Catalyst application.


What you want to do is turn all the stuff that mediates access to the database 
into your own shared library formatted kind of like one you might find as a CPAN 
module, say MyDBLib, and then use it in your Catalyst application by way of 
Catalyst::Model::Adaptor.


For any configuration details that might vary either per application or per 
deployment, make these user-configurable parameters of MyDBLib, with then each 
of your applications would supply arguments to it when instantiating a MyDBLib 
object; in the Catalyst app's case, said arguments would be in your Catalyst app 
config file as is normal for MyApp::Model::DB.


For any configuration details that are unlikely to vary per application or per 
deployment, especially if they are details for which your actual code would 
vary, then put these directly in your MyDBLib code instead.


Octavian Rasnita wrote:

The best idea would be to put the connection information in the application's 
config file like in the example below. (This example uses a Perl data 
structure, but you can use any configuration type accepted by Config::Any).

'Model::DB' = {
 schema_class = 'MyApp::Schema',
 connect_info = {
   dsn = 'dbi:Oracle:host=10.10.10.10;port=1521;sid=ora8',
   user = 'user',
   password = password,
   #name_sep = '.',
   LongReadLen = 100*1024*1024,
   LongTruncOk = 1,
   on_connect_call = 'datetime_setup',
   on_connect_do = [
 alter session set NLS_COMP='LINGUISTIC',
 alter session set NLS_SORT='BINARY_AI',
   ],
 },
},

The model will access the connection information directly if it is defined in 
the config file, and you can use the data from this config file in any other 
external program.
You can use the module Config::JFDI for using the Catalyst config file easier.


Now some of this looks wrong to me; a lot of those details should be in your 
MyDBLib code instead of the config file.  Your config file should instead look 
more like this:


'Model::DB' = {
 schema_class = 'MyApp::Schema',
 connect_info = {
   host = '10.10.10.10',
   port = 1521,
   user = 'user',
   password = password,
 },
},

These are more details that a non-programmer user would set.

The other details should all be in your code instead, because users shouldn't 
have to know and in particular if they are changed your code could break.  In 
particular I'm thinking of stuff like on_connect_call or the fact you are 
using dbi:Oracle.


Where it can get fuzzier is if your application is cross-DBMS portable, in which 
case more info would need to be in the config file, but you'd want to abstract 
it somehow, such as users just naming the DBMS and then they are actually 
picking from a pre-defined profile which has the code-specific details.  But if 
the app isn't supposed to be portable, eg if it uses Oracle-specific stuff, then 
don't put dbi:Oracle and NLS* and that stuff in your user config file.


Stuff like LongReadLen might be okay here if and only if changing it just tunes 
performance, like you were setting a chunk-buffer size or something, and would 
have no impact on behavior nor break any code; otherwise don't have it here.


-- Darren Duncan

___
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] Deleting the expired session files?

2010-09-04 Thread Darren Duncan

Octavian Rasnita wrote:

I am trying to create a script that will be executed by a cron job which will 
delete all the expired session files, but without success.
I use the Session::Store::File plugin.

snip

Have you tried using the FastMMap store instead?  I understand this can 
automatically expire sessions.  The main caveat that I'm aware of is that it is 
unreliable in a multi-thread environment. -- Darren Duncan


___
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 mailing list?

2010-09-03 Thread Darren Duncan
I find that a good thing to check when one doesn't see their own list messages 
is the web archive of that list.  If your message is in the archive, then the 
problem is likely with delivery to you as a list subscriber, and other 
subscribers may have seen it.  If the message isn't in the archive, then 
probably no one has seen it. -- Darren Duncan


___
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] test PostgreSQL 9.0 rc1

2010-08-31 Thread Darren Duncan

All,

The next major release of Postgres is imminent, 9.0, but first a release 
candidate has come out today, and anyone who can should download and test it. 
Details in the forwarded email below.


(Also, coincidentally, a release candidate for Perl 5.12.2 has also come out 
today on CPAN and needs testing, this being a minor update.)


-- Darren Duncan

 Original Message 
Subject: [ANNOUNCE] PostgreSQL 9.0 Release Candidate 1
Date: Tue, 31 Aug 2010 09:05:01 -0700
From: Josh Berkus j...@postgresql.org
To: pgsql-annou...@postgresql.org

The first release candidate for PostgreSQL 9.0 is now available. Please
download and test immediately so that we can move rapidly towards final
release. All known bugs should be fixed, so users should promptly report
any bugs which they find.

Note that, due to a system catalog change, an initdb and database reload
will be required for upgrading from 9.0 beta versions. We encourage
users to use this opportunity to test pg_upgrade. Please report your
results.

If you are able to help with testing, please see the testing page:
http://wiki.postgresql.org/wiki/HowToBetaTest

No changes in commands, interfaces or APIs are expected between this
release candidate and the final version. Applications which will deploy
on 9.0 can and should test against 9.0rc1. Depending on bug reports,
there may or may not be more release candidates before the final release.

Source code, as well as binary installers for many platforms, is
available from the PostgreSQL Web Site:
* Source:
  http://www.postgresql.org/ftp/source/v9.0rc1
* One-Click Installer, including Win64 binaries:
  http://www.enterprisedb.com/products/pgdownload.do
* Binaries for other platforms:
  http://www.postgresql.org/ftp/binary/v9.0rc1
* Release Notes:
  http://developer.postgresql.org/pgdocs/postgres/release-9-0.html
* Participating in Testing:
  http://www.postgresql.org/developer/beta

---(end of broadcast)---
-To unsubscribe from this list, send an email to:

  pgsql-announce-unsubscr...@postgresql.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] Catalyst::ScriptRole and excludes

2010-08-29 Thread Darren Duncan

Bill Moseley wrote:
In case hasn't been noticed, newer Moose will complain about the renamed 
-excludes option.


with 'MooseX::Getopt' = {
excludes = [qw/
_getopt_spec_warnings
_getopt_spec_exception
_getopt_full_usage
/],
};

Love that MooseX::Getopt. :)


That was true with Moose 1.10, and then Moose 1.12 turns off that warning so 
that other code has time to be updated. -- Darren Duncan


___
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] working with strange port setups

2010-08-21 Thread Darren Duncan

Hello,

For context, I'm currently deploying/demoing a Catalyst app on a client machine 
where it uses a contrived base url scheme to work around a restrictive firewall 
setup.  To be specific, the Firewall blocks all ports except port 80 (plus a few 
admin ports like SSH etc) and I want to run through HTTPS, so I've currently got 
the machine's Apache running HTTPS through port 80 rather than 443.


(My development machine isn't contrived at all, so no issue there.)

The contrived url for my Catalyst app looks like this:

  https://example.com:80/MyApp/some/page

My app initially works fine here using the FastCGI or CGI server script and the 
urls produced by uri_for() are mostly what is needed here but not quite.


An invocation of:

  https://example.com:80/MyApp/some/page

... would have page urls going to the likes of:

  https://example.com/MyApp/other/page

... which is correct except for the missing :80, because the result alone 
implies port 443 which isn't correct here.


Now from running the first url with ?dump_info=1 shows that the FastCGI/CGI 
program, namely Catalyst, *does* receive the necessary information to produce 
correct base urls.


Here's a relevant subset of Request details from dump_info:

bless({
  base = bless(do{\(my $o = https://example.com/MyApp/;)}, URI::https),
  headers = bless({
host = example.com:80,
https = on,
  }, HTTP::Headers),
  uri = bless(do{\(my $o = 
https://example.com/MyApp/some/page?dump_info=1;)}, URI::https),

}, Catalyst::Request)

The base and uri reflect the incorrect output, but the headers records the 
fact that both port 80 was invoked and https is on.  Using the latter 2 bits of 
information, Catalyst should be able to construct https://example.com:80; urls.


Therefore, can anyone tell me how to configure Catalyst so that it builds the 
urls I need, or alternately where in the Catalyst source I should look in order 
to create a patch to enable this?


Ideally this added smarts could make it into a CPAN release, if code changes are 
needed, but I would like to have this working quite soon, so if I knew what to 
patch in the meantime to get this to work, I would appreciate it.


Undoubtedly, Catalyst should simply handle this situation, but I'm not surprised 
that it doesn't yet, considering this is an edge case that the developers may 
not have encountered before.


Thank you. -- Darren Duncan

___
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] Best practice for setting up database in a complex project?

2010-07-16 Thread Darren Duncan

Matija Grabnar wrote:
I was wondering what the experienced Catalyst developers use to set up a 
database in a project.
Do you write the database definition mysql/postgresql format, and then 
dump schema to get the Perl classes, or do you write Perl class 
definitions and use something else to output the table creation 
statements for the

database of your choice?

And what do you do when the structure of the database changes (new 
tables, new columns, new indexes or foreign keys) - do you use a DB 
versioning thing, or do you do it by hand? If you do use a DB versioning 
tool,

which do you recommend?


What I like to do is write as much as is reasonably possible in SQL.

Supplementing Dave's response, I also like to exploit SQL stored procedures and 
define one for each distinct data manipulation or query operation.


So, rather than issue the bulk of an insert/update/delete/select from Perl, I 
wrap those statements in SQL stored procedures and then just invoke those from 
Perl instead.


Design-wise, you would typically have a declared stored procedure parameter for 
each bind variable that the underlying statement(s) would have if issued 
directly, but that you can save on duplication if your procedure is wrapping 
multiple statements that each take the same bind values.


On the Perl side, the DBI bind params would then map to procedure params, as the 
procedure call is then your SQL statement issued from Perl.


When you use SQL stored procedures to mediate access to your tables, then when 
you want to change the tables or columns or indexes etc that you have, it is 
less likely that you will have to make any changes to your Perl, as the 
appropriate manipulation or query changes may be confined to the database, so 
many changes won't require changing anything but the database.


-- Darren Duncan


___
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] Question on Perl versions with Catalyst

2010-07-07 Thread Darren Duncan

Joe Landman wrote:
  We are redoing one of our applications, and I wanted a quick sync 
against which Perl versions are currently blessed.  I remember that 
5.10.0 did not work due to a bug in the Perl base.  Are there any issues 
we need to be aware of for 5.12.0 or should we stick with 5.10.x (x 
greater than or equal to 1)?


My recommendation is to ignore the 5.10.x series, and go straight to 5.12.1+ if 
you want the newest production version, or use 5.8.x if you want to support 
older Perls.  The 5.12.x and 5.10.x were released close enough together, and the 
5.12.x benefit from the new and improved development process of making a release 
every month regardless of how much was changed.  Also, 5.12.x improves some of 
the features that 5.10.x added, such as making smart matching and Unicode work 
better.  Speaking for myself, I'm using 5.12.1 in production and for my work 
applications, and I'm using 5.8.1+ for my CPAN modules. -- Darren Duncan


___
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] perms on gen script/ files differ between platforms

2010-06-21 Thread Darren Duncan
I noticed today that generating a new Catalyst app under 2 different platforms, 
Mac OS X and Linux/CentOS, produces files with different sets of initial file 
permissions.


Both of these are the latest released Catalyst under Perl 5.12.1.

On Mac OS X, the initial 5 files in script/ had these permissions:

  -rwx--

... where the owner can execute but no one else can do anything.

On CentOS, the same files had these permissions:

  -rw-rw-r--

... where no one can execute but everyone can read.

So what is the reason for this difference?  Is it intentional or a bug?

Thank you. -- Darren Duncan

___
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] perms on gen script/ files differ between platforms

2010-06-21 Thread Darren Duncan

Florian Ragwitz wrote:

On Mon, Jun 21, 2010 at 07:05:56PM -0700, Darren Duncan wrote:

On Mac OS X, the initial 5 files in script/ had these permissions:

  -rwx--

... where the owner can execute but no one else can do anything.

On CentOS, the same files had these permissions:

  -rw-rw-r--

... where no one can execute but everyone can read.

So what is the reason for this difference?  Is it intentional or a
bug?


I'm guessing your umask settings on both systems differ.


Thanks for the pointer; I wasn't previously aware of the umask feature of 
Unixes, though I'm not surprised it exists either.


The umask does indeed differ on the 2 systems, but their values suggest this 
isn't the complete story.


Typing umask on the Mac OS X gives 0022 and on Linux gives 0002.  This 
would suggest default file permissions -rw-r--r-- on Mac OS X and -rw-rw-r-- 
on Linux.


So, umask can explain the Linux perms all by themselves but there must be more 
to it with the Mac OS X.


Regardless, I consider my question to be answered, so thank you.

-- Darren Duncan

___
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 install doesn't work at all... any ideas?

2010-06-09 Thread Darren Duncan

Sir Robert Burbridge wrote:
Hey can anyone help me figure out this issue?  I upgraded catalyst to 
v5.80024 (from CPAN).  A fresh install throws the following error.  I 
included module version numbers that seemed relevant ...


Moose: v1.07
Catalyst: v5.80024
Catalyst::Runtime: v5.80024
Catalyst::Devel: v1.27

snip

I updated to the latest Moose et al and then created a new Catalyst app et al as 
you did, and I'm not seeing any errors.


[Core Features]
- Test::More   ...loaded. (0.94 = 0.88)
- Catalyst::Runtime...loaded. (5.80024 = 5.80024)
- Catalyst::Plugin::ConfigLoader   ...loaded. (0.27)
- Catalyst::Plugin::Static::Simple ...loaded. (0.29)
- Catalyst::Action::RenderView ...loaded. (0.14)
- Moose...loaded. (1.07)
- namespace::autoclean ...loaded. (0.11)
- Config::General  ...loaded. (2.48)

Mind you, I also made sure to separately put Class::MOP up to date if that was 
needed, and I also did my tests on a different operating system, Mac OS X 
10.6.3.  I also had Perl 5.12.1, and I don't recall you saying what Perl version 
you had.


-- Darren Duncan

___
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] ANNOUNCE - Muldis D version 0.129.1

2010-05-19 Thread Darren Duncan
 commercial support.

And http://github.com/muldis/ is its main public GIT version control repository.

Thank you in advance for any interest in or support for this project that you
can give.  Any kind of support is welcome, from trying to update your own
projects to use Muldis D, or from contributing your time and expertise to
improving Muldis D or its implementations or ancillary projects, or promoting
this project in various media and forums.  Support is welcome in providing
significant financial sponsorship towards my further work, in which case you
have more of a say in its direction and priorities.  But mainly I want to see it
get used to enrich projects and their users and developers.

This project and ancillary projects are a serious endeavor that I intend to
commercially support over the long term, and others can do likewise.

Good day. -- Darren Duncan



___
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] Re: Alternatives to DBIx?

2010-04-17 Thread Darren Duncan

Adam Sjøgren wrote:

On Sat, 17 Apr 2010 19:15:14 +0100, Lyle wrote:

Adam Sjøgren wrote:



Ok, I'll bite: What system do you use instead of an object-relational mapper?



At the moment I just use DBI directly.

[...]

Thanks for the answer.

It is always nice to know what people like when they express contempt
for other things. It gives you a chance to understand where they are
coming from better.


Personally, I prefer a middle-ground between raw DBI+SQL and ORMs as they are 
currently known, and that's what my Muldis D language and database toolkit is 
meant to deliver.


People could treat it like a SQL templating system in the way that things like 
SQL::Abstract are treated, but that it is a lot more thorough in features and 
makes the SQL look more like Perl; your database tables are expressed as data 
type definitions plus declared variables of those types; your queries are 
expressed as mostly-declarational functions and procedures.


You can write Muldis D either in string form like with SQL or Perl, which is 
better when you're writing code entirely manually, and you can write it as Perl 
data structures, which is better if you are generating code using Perl, both 
forms equally expressive; the latter is the closest analogy to traditional SQL 
generators.


Muldis D is like a traditional ORM in that it has a variety of built-in features 
that SQL DBMSs in general lack, such as updateable views or collection-valued 
attributes, say to nest child records under parents.


But unlike typical ORMs, it unifies objects and the relational model, and so 
considers that there is no impedence mismatch, while ORMs say there is a 
mismatch and tries to treat the two things as separate.


In other words, Muldis D makes the database itself look more powerful or Perlish 
than it otherwise is, and so Perl programs can then use it as if it were just an 
ordinary programming language VM, based on types and routines like regular 
languages.


I am perhaps a few days away from a milestone in this project and I wasn't going 
to talk about it here before that; but this thread sort of forced my hand as I 
didn't want the option to go unmentioned in it.


-- Darren Duncan

___
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] KiokuDB, MongoDB and the NoSQL thing

2010-03-20 Thread Darren Duncan

As an addendum to this thread ...

It just occurred to me now, following an interview today with a developer of 
millions-users social-network games, that I could be embracing this NoSQL thing 
in an indirect way, taking into account that still I consider it just a 
reasonable compromise for some applications, but not a general database pancea.


Because Muldis D is designed from the start to be implementable over both SQL 
DBMSs of various capabilities and within general purpose languages, meaning that 
any functionality a DBMS doesn't natively support can be hoisted to the 
application, this structure is a natural fit for NoSQL.


NoSQL is all about keeping the main DBMS simple, supporting just a few native 
operations, and massively parallel.  And so, one could write Muldis D code and 
deploy it both over SQL and NoSQL, and in the latter case it would just do a lot 
of the work on the application side.  Essentially, Muldis D takes care of the I 
believe I did, Bob, so you can use a NoSQL store without doing the write a 
distributed map-reduce function in Erlang yourself, instead you just say what 
you want declaratively much like in SQL, and then the right thing happens.


Of course, that won't generally give you the consistency/integrity that a 
relational DBMS backend has over a NoSQL one, but at least you'll get the 
powerful queries part.


You heard it here first.

-- Darren Duncan

S.A. Kiehn wrote:

Thanks for the link Darren. I will read and ponder.

Also of interest, I seen that Search::GIN has had a new release 
http://blogs.perl.org/users/sawyer_x/2010/03/searchgin-004-finally-out.html.  
The post also mentions some docs explaining queries, but I have not 
found them yet. Active Search::GIN development would encourage KiokuDB 
usage I would think.


Thanks for the posts regarding this topic.

S. Kiehn

Darren Duncan wrote:

Here's something timely on Ars, in that I just discovered it now
around the time of this discussion thread:

http://arstechnica.com/business/data-centers/2010/02/-since-the-rise-of.ars

It lays out a summary of how the SQL and NoSQL worlds compare, and
what sort of trade-offs you get for each choice, and it introduces
several specific NoSQL projects.  I also learned something, such
that what CouchDB and MongoDB specifically represent data with is
JSON documents.

So basically, what you pick out of today's choices depends on your
priorities.



___
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] Which PHP framework is the most similar to Catalyst?

2010-03-20 Thread Darren Duncan

Julien Sobrier wrote:

Hello,
I need to help a project that will be developed with PHP. I really
love Catalyst, and I am looking for a similar framework in PHP.
Symphony seems to be the closed to Catalyst. Do you have any
suggestion?

Thank you
Julien


If the project hasn't been built yet, why don't you try convincing them to use 
the genuine article Catalyst?  Its not like there is a legacy PHP codebase, and 
if the other developers know PHP, it isn't that hard to learn Perl, especially 
when Catalyst or CPAN takes care of so much. -- Darren Duncan


___
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] KiokuDB, MongoDB and the NoSQL thing

2010-03-02 Thread Darren Duncan

S.A. Kiehn wrote:
I do not see many posts regarding uses of KiokuDB within Catalyst so I 
was curious about the opinion of the community in regards to its usage.  
Is it still to early within development?


Also, I have been reading more about the increase in the NoSQL interest, 
with a particular interest in the MongoDB database (it seems to be 
similar in some respects to KiokuDB), but I do not find Perl people in 
the discussion as much as others (Ruby, PHP).  Are there developers in 
the Catalyst community who lean toward NoSQL concepts over traditional 
RDMS's, or is best to view as a tool to use at times?


How about MongoDB?  Am I being suckered by another bandwagon?

Thanks, Scott K.


Well I happen to be strongly opinionated on this topic, so here goes ...

While these other DBMSs have their uses, I believe that anyone is misguided who 
figures they are superior solutions for most uses of relational databases.


I believe that the relational model of data is still the single best general 
solution that we have come up with for organizing and querying any non-trivial 
amount of data that is the least bit structured.  Especially so when that data 
needs to be or could possibly be worked with by multiple kinds of users or 
applications that may have different needs, and need their own views of that 
data.  It is also good for persisting data, but persistence isn't the main 
point; rather easy and flexible organization and querying is the point; 
persistence is optional, same as persisting an array of data is optional.


That said, while it does the job well enough many times, SQL is deeply flawed 
and doesn't represent the relational model of data properly, but just 
approximates it to varying degrees, this variance depends partly on the SQL DBMS 
in use, which range in features quite a bit.


I believe that quite often when people complain about relational databases, 
they are really complaining about SQL databases, as if those were the same, 
and so various solutions are proposed like ORMs or these NoSQL concepts.


But the problem is that they are throwing out the baby with the bathwater.  Yes, 
SQL is quite flawed, but the relational model it approximates is not (or it is 
much less flawed, if you want to argue that having something actually flawless 
is impossible).


I believe that the best solution is not to ditch everything, but rather to 
provide a DBMS that actually implements the full relational model of data, and 
not just an approximation, nor ditching the concept entirely.  If you do that, 
then a lot of these other kinds of DBMSs like so-called object-relational or 
object or key-value become redundant, because the full relational model 
incorporates their features.


For example, the full relational model supports having tuple/row and 
relation/table values as attributes/fields of other ones, and so you can 
natively model any arbitrarily complex data type that an object could model, 
without too much indirection (similarly to how many languages support having an 
array as an element of an array).  Hence ORMs are redundant and so are distinct 
concepts of object stores, or alternately they become a lot thinner.


And so, as a model of good community behaviour, I'm not just sitting around 
talking about what people should do, but I am going out and actually doing it, 
creating a DBMS that provides the full relational model (both as self-contained 
implementations as well as implementations over existing DBMSs), and right now. 
 Simultaneously taking what SQL should have been and all the good features of 
the SQL alternatives, elegantly integrated in one streamlined bloat-free package.


This project, with the umbrella name Muldis (see CPAN etc), is mostly 
pre-alpha right now, but I am filling in the gaps as soon as I can and I am 
confident it will be viable.  In fact, I released updates to 3 of 4 current 
sub-projects on CPAN earlier today.


So, to answer your question, go ahead and explore the alternatives you name, but 
I will say to anyone that the relational model is the single best general 
solution for data aggregation and processing.


-- Darren Duncan


___
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] Re: Catalyst 5.800013 - missing dependency version

2009-09-23 Thread Darren Duncan

Toby Corkindale wrote:
I am running the latest stable versions of Moose/Class-MOP and their 
dependencies.


to...@arya:~$ pmvers Moose
0.91
to...@arya:~$ pmvers Class::MOP
0.93


Meanwhile, Moose 0.92 and CMOP 0.94 came out half a day before your post.  See 
if those are any better. -- Darren Duncan


___
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] Reading Database At Startup

2009-08-16 Thread Darren Duncan

Ovid wrote:

For a personal project, I want users to be able to click on a letter and get a 
list of countries starting with that letter.  I can do this:


Considering that there are only about 250 countries in total, you should just 
list them all on one screen and be done with it.


I think that would be a lot more user friendly than requiring them to click a 
letter first, especially if they're not sure exactly how their country is 
spelled or what letter it might be under (eg, is Republic of Ireland under I 
or R).


Save clicking a letter when you're doing a list of cities or something.


my $letters = $c-model('DB')-storage-dbh-selectcol_arrayref(
'select distinct(substr(name,1,1)) as letter from country order by 
letter'
);
$c-stash-{letters} = $letters;


Also, to use 'distinct' I don't think you ever use parens; you just say select 
distinct foo-expr as bar from baz 


-- Darren Duncan


___
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 Apress book shipping now from Amazon.com

2009-07-28 Thread Darren Duncan

If you want it, you'll have to come here in person to pick it up. -- Darren 
Duncan

Ali M. wrote:

The extra one is mine!

Regards,
Ali

On Mon, Jul 27, 2009 at 11:06 PM, Darren Duncandar...@darrenduncan.net wrote:

Darren Duncan wrote:

Ari Constancio wrote:

For those interested, Amazon.com is shipping now pre-orders for The
Definitive Guide to Catalyst. Not sure about new orders, though.

I've had a different experience so far.  I pre-ordered the book on
amazon.ca back on June 19th, and it estimated it would ship July 10, the
release date. Then today I got a message from Amazon saying it had been
delayed, and now they say, I kid you not:

 Estimated ship date: August 05 2009 - October 21 2009

Now that's probably a glitch, which will be corrected shortly with a new
estimate, and usually my experience with Amazon is they ship things ahead of
their estimates.  But as a hedge I went and placed a separate amazon.com
order now, which it estimates to ship on July 17th.  The idea that when one
ships I'll cancel the other one (or end up with 2 copies if they ship
simultaneously).  So we'll see what I get first.

As an update, today (July 27) I received *both* copies in the mail, after
they had shipped on July 19 (.com) and July 22 (.ca).  Both in good
condition. -- Darren Duncan


___
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 Apress book shipping now from Amazon.com

2009-07-27 Thread Darren Duncan

Darren Duncan wrote:

Ari Constancio wrote:

For those interested, Amazon.com is shipping now pre-orders for The
Definitive Guide to Catalyst. Not sure about new orders, though.


I've had a different experience so far.  I pre-ordered the book on 
amazon.ca back on June 19th, and it estimated it would ship July 10, the 
release date. Then today I got a message from Amazon saying it had been 
delayed, and now they say, I kid you not:


  Estimated ship date: August 05 2009 - October 21 2009

Now that's probably a glitch, which will be corrected shortly with a new 
estimate, and usually my experience with Amazon is they ship things 
ahead of their estimates.  But as a hedge I went and placed a separate 
amazon.com order now, which it estimates to ship on July 17th.  The idea 
that when one ships I'll cancel the other one (or end up with 2 copies 
if they ship simultaneously).  So we'll see what I get first.


As an update, today (July 27) I received *both* copies in the mail, after they 
had shipped on July 19 (.com) and July 22 (.ca).  Both in good condition. -- 
Darren Duncan


___
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] More up-to-date version of Perl 5.10 ...

2009-07-20 Thread Darren Duncan

Kiffin Gish wrote:

Installed Catalyst and at the end it said that because of a bug in Perl
5.10 I need to update to a newer version. Which version do you recommend
that is the most stable for Catalyst?


The first Perl 5.10.1 release candidate is expected to be out in maybe a week or 
so, and would presumably be the newest stable shortly after.


Meanwhile, there is a maint-5.10 snapshot (aka 'RC0') that came out on July 7 
which is close to what 5.10.1RC1 would be but that it is *not* for production; 
see http://www.nntp.perl.org/group/perl.perl5.porters/2009/07/msg148270.html for 
info and to get it; note that installing it in standard locations will blow away 
a production 5.10.0 since it is still marked as 5.10.0.


Alternately, go older and try 5.8.9 or 5.8.8 for the alternate most stable right 
now.


-- Darren Duncan

___
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 Apress book shipping now from Amazon.com

2009-07-11 Thread Darren Duncan

Ari Constancio wrote:

For those interested, Amazon.com is shipping now pre-orders for The
Definitive Guide to Catalyst. Not sure about new orders, though.


I've had a different experience so far.  I pre-ordered the book on amazon.ca 
back on June 19th, and it estimated it would ship July 10, the release date. 
Then today I got a message from Amazon saying it had been delayed, and now they 
say, I kid you not:


  Estimated ship date: August 05 2009 - October 21 2009

Now that's probably a glitch, which will be corrected shortly with a new 
estimate, and usually my experience with Amazon is they ship things ahead of 
their estimates.  But as a hedge I went and placed a separate amazon.com order 
now, which it estimates to ship on July 17th.  The idea that when one ships I'll 
cancel the other one (or end up with 2 copies if they ship simultaneously).  So 
we'll see what I get first.


-- Darren Duncan

___
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] PostgreSQL 8.4 released

2009-07-01 Thread Darren Duncan

Joshua D. Drake wrote:

Thought I would let you know this little wonderful tidbit for the day.
PostgreSQL 8.4 has been released. You can check out the release here:

http://www.postgresql.org/about/news.1108


That's great news.  Postgres 8.4 introduces some features that I consider very 
valuable to have, and that makes possible some work that would otherwise be 
quite difficult.  For examples, common table expressions or named subqueries 
(WITH), with recursion.  This lets you apply to non-trivial database queries 
what are good practices in programming in general, such as factoring out 
repeated portions of a query into named subqueries so you only have to write 
that part once.  And the recursion which basically is predicated in the prior 
ability.  That's one of the things I appreciate the most. -- Darren Duncan


___
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] More natural access to model?

2009-05-12 Thread Darren Duncan

Paweł Tęcza wrote:

Dnia 2009-05-12, wto o godzinie 19:30 +0100, Matt S Trout pisze:

Well, that's a horrible idea.

The whole point of having a database is to -model- your data.

If you try and turn it into a giant hash, then of course you're going to
end up with nasty code.

I -could- explain how to clean that loop up a lot, but the reality is that
you should have actual columns for things and update your database as
required as new types of data need to be included - you'll have to update
the application anyway, so I don't see any reason not to update the database
at the same time ...


Intriguing post. My application and database design are still under
heavy development, so all ideas, suggestions and comments are very
welcome :D


A general rule of thumb is that you should be conceptualizing your databases 
similar to how you conceptualize your applications.


Your database schema, such as what tables you have, and their columns, and their 
column data types, and the relationships between tables and columns etc, these 
are like program code, such as how you choose to decompose your application into 
libraries and classes and class attributes and type constraints and input 
constraints and so on.  The actual data you put in your database tables is 
analogous to what data you put in your application variables or objects.


Generally speaking it should be natural to change your actual database schema as 
often as you change your application source code, where it makes sense; for 
example, changing your schema is a similar sort of operation to changing what 
attributes your object classes have or your constraints.


Or more accurately in practice, a database is more like (or in some cases, 
exactly like) a shared library, where you have some classes you write once and 
share in multiple applications, and if you change the library you have to 
consider that impact on all the applications that use it.  Hence people tend to 
be more conservative in database design changes, but still one shouldn't be 
afraid to do it, and all you really need is just proper communication and 
planning between the involved parties so it goes smoothly.


Also, same as classes can have multiple APIs, eg keeping old ones for backwards 
compatibility if old apps can't update, databases have things called views / 
virtual tables which let them also have multiple APIs; this is one of the main 
purposes of views in fact.


-- Darren Duncan

___
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: SimpleDB - Auth configuration made easy

2008-10-27 Thread Darren Duncan

Zbigniew Lukasiak wrote:

* Your passwords are stored in the 'password' field in your users
table and are not encrypted.


This is always a bad idea.  If someone ever gets direct database access, they 
now know each user's mindset as to how they choose passwords, and can 
subsequently login to the application as them or target them in a wider context 
where they may have used similar passwords elsewhere.  You always want passwords 
in a one-way hash, and if users forget their password, you don't tell it to 
them, but you have them make a new one.  Also reminding users of their password 
in an email message is also a bad idea. -- Darren Duncan


___
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: SimpleDB - Auth configuration made easy

2008-10-27 Thread Darren Duncan

Jason Kuri wrote:

If I explicitly override the default, by explicitly requesting
'clear', because my requirements explicitly need this ability, then
I must change the code to get rid of the warning?  Ahh, but it's for
the 'simple', who must be guided, and can't be bothered to read the
warnings in the text so bonk'em repeatedly in the logs till they
mind what you say.  Which is to explicitly not use the feature which
you've explicitly provided?  (sigh)

How about adding 'clear_please_please' ?

(Just because I like simple doesn't mean I _am_ 'simple' - and I
really do appreciate the simplicity enablers, really)


Matt suggested a way to turn off the warning also... but I am
skeptical... either we hold the newbies hand and protect him from
himself, and warn him if he's doing something dangerous or we
happily let them shoot themselves in the foot, assuming they'll
probably figure it out after the first time  Seems the two options
are out of sync with each other...

I'm not beyond convincing... just a bit skeptical Anybody else
want to weigh in... should we protect them, but allow them to throw
off the comfort blankets if they say 'PLEeease'?


I think a good approach is to have safer more secure defaults, and if users 
explicitly turn those off then have relevant warnings on by default, and if 
users really know what they're doing then they can explicitly turn those off.


For example, users can have an explicit no_warnings_plaintext_password or some 
such where warnings are turned on by default and off explicitly.


Generally speaking, those who know enough to handle less safe things also know 
enough how to ask the system to let them do those things.  People who don't know 
well enough for one aren't likely at the same time have to know to ask the 
system for help in pointing out unsafe behaviour so they're in trouble if unsafe 
is the default.  For people who do know things, having safe defaults is still 
good for working together with their desire to be lazy.


-- Darren Duncan

___
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] tips for troubleshooting/QAing Unicode

2008-09-28 Thread Darren Duncan

J. Shirley wrote:

Hey Darren, great post!

Can you post it on the wiki, perhaps at:

http://dev.catalystframework.org/wiki/faq link to Unicode
Troubleshooting in the Unicode section there?  It would be much
appreciated.

Thanks,
-J


I have gone and added a section to 
http://dev.catalystframework.org/wiki/gettingstarted/tutorialsandhowtos/using_unicode 
that has a slightly edited version of my email post.


In the process, I discovered that your wiki appears to have a Unicode 
handling problem, which I black-box debugged and present here.


If you go to the above url when you are not logged in and your browser has 
its cache/cookies/etc flushed beforehand, then my Japanese text sample will 
display correctly.  But if you login to your account and then view the 
page, then the Japanese text sample will not display properly.  Moreover, 
if you logout after being logged in and refresh the page again, it still 
doesn't display properly, but if you wipe your cache/cookies/etc (I haven't 
narrowed it down yet), and then refresh that page, then it displays properly.


I see this same behaviour on both Firefox 3.0.3 and Safari 3.1.2, both on 
Mac OS X 10.5.5 PPC.  A telnet to the server on port 80 also displays 
correctly, though that is only testing the not logged in example.


From what I have seen so far, I would guess that the wiki is sometimes 
encoding its http response as UTF-8 and other times as some single-byte 
encoding like ISOLATIN1 but it is still declaring that it is UTF-8.


I don't have the source code of the wiki or access to the server to test 
further though.


Someone please confirm the behaviour I'm seeing.  I hope my diagnosis will 
help fix it.


(On a tangent, I suggest declaring the encoding using uppercase UTF-8 and 
not lowercase utf-8 as the server currently is doing; I don't think this 
is the cause of the problem but it might be technically incorrect, unless 
those things are officially case-insensitive.)


Thank you. -- Darren Duncan

___
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] tips for troubleshooting/QAing Unicode (was Re: Passing UTF-8 arg in URL to DBIC search)

2008-09-28 Thread Darren Duncan

Lee Aylward wrote:

Great timing on this as I am currently struggling with some unicode text
not displaying correctly in an application I am working on. Per your
suggestion I put the Japanese text at the top of my template. All of a
sudden the browsers started displaying that and other non-ascii characters
correctly. The second I take away the Japanese text it goes back to just
showing question marks. I am seeing this behavior in both the test
server and Apache.

I have looked at the Content-Type header and it is definitely serving it
as utf-8, so I am at abit of a loss. There are no databases involved
here, but I am displaying information from IMDB::Film. Is there anything
in the actual HTML that needs to be set?


That seems strange.  I wonder if something in your template handler or 
other part of your app is trying to DWIM for you and is getting it wrong. 
Are your source files actually UTF-8, both the prior and new versions?  Are 
you explicitly declaring that in one place and not another?  I wouldn't 
expect the addition of Japanese text to suddenly make the other characters 
look correct by itself unless there's some DWIM going on.  I suspect you 
made some other change between the two versions as well, such as saving the 
source file in a different encoding.


Note that the reason I use a Japanese text example is because the vast 
majority of my normal program text would fit in the ASCII repertoire, and 
it would only be user data that might be Unicode, though most user data 
isn't.  And Japanese characters are known to not have a one-byte 
interpretation and they stand out clearly from latin letters at a glance. 
So in your own situation, the text you already have that doesn't display 
right, if it is literal text in your source code, should be a surrogate for 
my Japanese test example to see if things look right.  So see what your 
text editor says that your older/incorrect file version's encoding is.


-- Darren Duncan

___
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] tips for troubleshooting/QAing Unicode (was Re: Passing UTF-8 arg in URL to DBIC search)

2008-09-27 Thread Darren Duncan
Maybe you're already aware of this, but I've found from experience that 
troubleshooting encoding/Unicode problems in a web/db app can be difficult, 
especially with multiple conversions at different stages, but I've come up 
with a short generic algorithm to help test/ensure that things are working 
and where things need fixing.  Note that these details assuming we're using 
Perl 5.8+.


1. Make sure all your text/code/template/non-binary/etc files are saved as 
UTF-8 text files (or they are 7-bit ASCII), and you have a Unicode-savvy 
text editor.


2. Have a use utf8; at the top of every Perl file, so Perl treats your 
source files as being Unicode.


3. Place a text string literal in your program code that you know isn't in 
ASCII ... for example I like to use the word 'サンプル', which is what came 
out of Google's translation tool when I asked it to translate the word 
'sample' to Japanese.  Then setup your program to display that text 
directly in your web page text, without any escaping.


4. Make sure the HTTP response headers for the webpage with that text have 
a content-type charset value of UTF-8, and make sure that Perl is encoding 
its output as actual UTF-8; if you were doing it directly using STDOUT for 
example such as in a CGI, it could be: binmode *main::STDOUT, 
':encoding(UTF-8)'; or such.  Make sure your web browser is Unicode savvy.


5. At this point, if the web page displays correctly with the non-ASCII 
literal (and moreover, if you view source in the browser and the literal 
also displays literally), then you know your program can work/represent 
internally with Unicode correctly, and it can output Unicode correctly to 
the browser.  It is very important to get this step working first, in 
isolation, so that you are in a position to judge or troubleshoot other 
issues such as receiving Unicode input from a browser or using it with a 
database.


6. Next test that you can receive Unicode from the browser in the various 
ways, whether by query string / http headers or in an http post.  Eg try 
outputting a value and have the user submit it again, and compare for 
equality either in the Perl program or by displaying it again next to the 
original for visual inspection.  If any differences come up, then you know 
any fixes you have to do concern either how you read and interpret the 
browser request, or perhaps on how you instruct the browser on how to 
submit a request.  Once that's all cleared up, then you know your I/O with 
the web browser works fine.


7. To test a database, I suggest first using a known-good and Unicode savvy 
alternate input method for putting some Unicode text in the database, such 
as using an admin/utility tool that came with the DBMS.  Also make sure 
that the database is itself using UTF-8 character strings in its schema, eg 
that the schema is declared this way.


8. With a database known to contain some valid Unicode etc text, you first 
test simply selecting that text from the database and displaying it.  If 
anything doesn't match, it means you probably have to configure your DBMS 
client connection encoding so it is UTF-8 (often done with a few certain 
SQL commands), and then separately ensure that Perl is decoding the UTF-8 
data into Perl text strings properly.  Its important to make sure you can 
retrieve Unicode from the database properly so that you have a context for 
judging that you can insert such text in the database.


9. Next try to insert some Unicode text in the database using your program, 
then select it back to check that it worked.  If it didn't, then check DBMS 
client connection settings, or that Perl is encoding text as UTF-8 properly.


10. Actually, when you have a known-good external tool to help you, you can 
alternately start the DBMS tests with step 9, where your program inserts 
text, then you use the known-good tool to ensure it actually was recorded 
properly.


Anyway, that's it in a nutshell.  Now I'm sure many of you have already 
figured this out, but for those who haven't, I hope these tips help you. 
Adjust as appropriate to account for any abstraction tools or frameworks 
you are using which means your tests may also involve testing those tools 
or configuring them.


-- Darren Duncan

Hugh Hunter wrote:
I've been struggling with this for some time and know there must be an 
answer out there.


I'm using URL arguments to pass parameters to my controller.  It's a 
site about names, so take the url http://domain.com/name/Jesús (note the 
accented u).  The Name.pm controller has an :Args(1) decorator so Jesús 
is stored in $name and then passed to my DBIC model in a -search({name 
= $name}) call.  This doesn't manage to find the row that exists in 
mysql.  When I dump $name I get:


'name' = 'Jes\xc3\xbas'

which I think I understand as being perl's internal escaping of utf-8 
characters.


I've done everything recommended on 
http://dev.catalystframework.org/wiki/gettingstarted/tutorialsandhowtos/using_unicode

[Catalyst] Re: CGI.pm and Catalyst?

2008-03-07 Thread Darren Duncan

At 11:39 AM +0100 3/7/08, Aristotle Pagaltzis wrote:

It's a really really REALLY bad idea to mix your display logic
into your controllers, much less your model.

Most people therefore say that you should use a template system
with a minilanguage. But the reason that doing this is good is
that it forces you to write your display logic in a separate file
without easy access to the rest of the code.

In other words, it forces you to properly separate concerns: the
controllers only translate HTTP into model and view calls, and
only the model has business logic, and the view does nothing else
than translate the stash into output.

But the language in which your display logic is written doesn't
much matter. (In fact, the minilanguages are usually terrible,
like writing shell and awk scripts when you could be writing
Perl.) It's not an issue to write Perl to generate your output,
as long as you keep that Perl code in separate modules whose
*only* job is to render the stash.


Speaking for myself (who is now on the cusp of starting to use 
Catalyst for the first time, and is now reading the book to learn 
it), I have for the last several years been writing my new web 
applications with very few external dependencies, with said 
applications using DBI and SQL directly, and producing their own 
HTML, both without help from a generic templating wrapper or generic 
DBI wrapper.


That said, the applications were well structured and highly resembled 
the MVP practices that Catalyst is built on.  Practically all of the 
code was in modules, except for a thin wrapper which invoked the 
otherwise controller main in an eval block so to trap and report 
otherwise unhandled compile or runtime exceptions.  Its controller 
logic and HTML-making view code were in separate per-application 
modules; the controller examined user input, determined what page to 
display (using the path_info mainly) and gathered data to use; the 
view was invoked almost just before the controller exited, and 
rendered the page the controller told it to do.  Utility modules 
wrapped DBI, and wrapped the web client input/output (including 301s 
etc), uri generation, and managed sessions (the last 3 with CGI.pm 
and CGI::Session and File::VirtualPath) and the stash.  For 
configuration, the controller starts by do-ing a Perl file that 
simply contained an anonymous Perl hash declaration, so Perl itself 
is the config file parser.  Many more similarities that I won't 
detail here.


Suffice it to say that as I've been reading the book, I very much 
understand the reasoning of how Catalyst-using applications, and the 
framework, are structured, as its essentially the same as what I was 
doing, but that with Catalyst a greater part of the codebase will be 
generified and higher quality.  The first main benefit I anticipate 
getting from switching to Catalyst is improved server portability, 
and in particular the ability to develop and test an app without 
running it on the actual Apache server.


Getting back to the topic at hand, I think it works very well for a 
view to simply be written in Perl, and in many cases it seemed to 
work better than the templating approach I had seen in PHP 
applications.


That said, as per the examples in the book, I intend to try using a 
non-Perl template approach (TT or something) at the same time as 
adopting Catalyst, and see how well that works out.


At the same time, I'll also move to using an alternate database 
access method than direct DBI+SQL, which would be my first use of 
Muldis DB.  Note that many of my database queries are relatively 
complicated and would have required writing a lot of SQL anyway were 
I to use any other DBI wrappers / ORMs, afaik.


-- Darren Duncan

___
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/