Re: How to ...
Joel Bernstein wrote:
On 5 Mar 2010, at 13:37, Emmanuel Quevillon wrote:
By the way, I use a self coded 'new' method to create my object.
Would it be the problem?
Yes. But you omitted the code that doesn't work, so... Good luck!
/joel
oops sorry,
sub new {
my($class, %args) = @_;
my $self = $class-SUPER::new(%args);
$self-_init(%args);
$self-_build_types(%args);
return $self;
}
Later in the code is try $self-so_type(), nothing is returned...
--
-
Emmanuel Quevillon
Biological Software and Databases Group
Institut Pasteur
+33 1 44 38 95 98
tuco at_ pasteur dot fr
-
Re: How to ...
Stevan Little wrote:
On Mar 5, 2010, at 9:06 AM, Emmanuel Quevillon wrote:
Joel Bernstein wrote:
On 5 Mar 2010, at 13:37, Emmanuel Quevillon wrote:
By the way, I use a self coded 'new' method to create my object.
Would it be the problem?
Yes. But you omitted the code that doesn't work, so... Good luck!
/joel
oops sorry,
sub new {
my($class, %args) = @_;
my $self = $class-SUPER::new(%args);
$self-_init(%args);
$self-_build_types(%args);
return $self;
}
Later in the code is try $self-so_type(), nothing is returned...
Honestly, this should work, however you very well might be doing
something in _init or _build_types that causes the problem. Perhaps
showing us some more code would help.
You might also try changing your new to this:
sub BUILD {
my($self, $args) = @_;
$self-_init(%$args);
$self-_build_types(%$args);
}
.. which is a little more Moosey.
- stevan
I tried without success :
Here are the methods :
sub BUILD {
my($self, $args) = @_;
$self-_init(%$args);
$self-_build_types(%$args);
}
sub _init {
my($self, %args) = @_;
my($output, $cut_type, $format, $style) =
$self-_rearrange([qw/OUTPUT CUT_TYPES FORMAT STYLE/], %args);
$format$self-_set_format (lc($format));
$cut_type $self-_set_cut_types($cut_type);
$self-_set_style (lc($style) || 'text');
$self-_set_output($output);
return $self;
}
sub _build_types {
my($self, %args) = @_;
$self-{_types} = [ ];
foreach my $type (sort { $a cmp $b } @{$self-cut_types()}){
$type = lc($type);
my $obj = Bio::Restriction::Analysis::FramedCut::$type;
$self-add_type($obj-new(%args));
}
return;
}
If I put some print into these method, nothing is printed out on my
screen. Looks like there are not called at all. :(
I'm really lost :(
--
-
Emmanuel Quevillon
Biological Software and Databases Group
Institut Pasteur
+33 1 44 38 95 98
tuco at_ pasteur dot fr
-
Re: How to ...
Emmanuel,
Are you trying to wrap bioperl modules? The use of $self-_rearrange()
gives it away, not to mention the 'so:x' (sequence ontology).
You should probably use delegation, or something like MooseX::NonMoose;
bioperl's class structure has issues (believe me, I'm a core dev for the
project).
chris
(PS: FWIW, I'm rewriting some of the core modules in Moose but they need
serious work)
On Fri, 2010-03-05 at 15:49 +0100, Emmanuel Quevillon wrote:
Stevan Little wrote:
On Mar 5, 2010, at 9:06 AM, Emmanuel Quevillon wrote:
Joel Bernstein wrote:
On 5 Mar 2010, at 13:37, Emmanuel Quevillon wrote:
By the way, I use a self coded 'new' method to create my object.
Would it be the problem?
Yes. But you omitted the code that doesn't work, so... Good luck!
/joel
oops sorry,
sub new {
my($class, %args) = @_;
my $self = $class-SUPER::new(%args);
$self-_init(%args);
$self-_build_types(%args);
return $self;
}
Later in the code is try $self-so_type(), nothing is returned...
Honestly, this should work, however you very well might be doing
something in _init or _build_types that causes the problem. Perhaps
showing us some more code would help.
You might also try changing your new to this:
sub BUILD {
my($self, $args) = @_;
$self-_init(%$args);
$self-_build_types(%$args);
}
.. which is a little more Moosey.
- stevan
I tried without success :
Here are the methods :
sub BUILD {
my($self, $args) = @_;
$self-_init(%$args);
$self-_build_types(%$args);
}
sub _init {
my($self, %args) = @_;
my($output, $cut_type, $format, $style) =
$self-_rearrange([qw/OUTPUT CUT_TYPES FORMAT STYLE/], %args);
$format$self-_set_format (lc($format));
$cut_type $self-_set_cut_types($cut_type);
$self-_set_style (lc($style) || 'text');
$self-_set_output($output);
return $self;
}
sub _build_types {
my($self, %args) = @_;
$self-{_types} = [ ];
foreach my $type (sort { $a cmp $b } @{$self-cut_types()}){
$type = lc($type);
my $obj = Bio::Restriction::Analysis::FramedCut::$type;
$self-add_type($obj-new(%args));
}
return;
}
If I put some print into these method, nothing is printed out on my
screen. Looks like there are not called at all. :(
I'm really lost :(
Re: How to ...
On Mar 5, 2010, at 10:35 AM, Emmanuel Quevillon wrote:
Hi Chris,
I know you're a core dev;)
Well not a wrapper I'm just extending restriction::analysis and wanted to do
it with moose. But apparently it is much difficult than expected.
Moreover I'm nit really comfortable with moose, I must admit I don't
understand all the concepts :(.
I didn't realize 'rearrange' would break moose. But anyway it looks like even
the subs around moose'new methods are not called. It is really obscure for me
at this time.
It's not that it breaks moose (or vice versa). BioPerl has a specific named
argument syntax and related methods that are problematic when mixed with Moose;
in BioPerl all named arguments in bioperl start with '-' to distinguish them
from simple positional arguments. With Moose OTOH, I think everything is
treated as named by default in the constructor (e.g. no '-' needed), but the
behavior can be overridden with BUILDARGS (please correct me if I'm wrong moose
illuminati).
Regardless I'm pretty sure _rearrange() doesn't work w/o '-', so I could
definitely foresee some problems here going back and forth between Moose and
BioPerl without doing some work in BUILDARGS.
Either I'll stay with the current biopel code structure or if someone has an
explanation
I wouldn't want to dissuade you from using Moose; I'm using it extensively in
non-bioperl-based work, along with DBIx::Class. Hence the reason I'm writing
up a library of Moose-based BioPerl classes.
Anyway, I suggest MooseX::NonMoose (I see Stevan and Jesse have already
responded likewise) and going from there.
Anyway thanks for your helps
Emmanuel
np.
chris
Le 5 mars 2010 à 16:53, Chris Fields cjfie...@illinois.edu a écrit :
Emmanuel,
Are you trying to wrap bioperl modules? The use of $self-_rearrange()
gives it away, not to mention the 'so:x' (sequence ontology).
You should probably use delegation, or something like MooseX::NonMoose;
bioperl's class structure has issues (believe me, I'm a core dev for the
project).
chris
(PS: FWIW, I'm rewriting some of the core modules in Moose but they need
serious work)
On Fri, 2010-03-05 at 15:49 +0100, Emmanuel Quevillon wrote:
Stevan Little wrote:
On Mar 5, 2010, at 9:06 AM, Emmanuel Quevillon wrote:
Joel Bernstein wrote:
On 5 Mar 2010, at 13:37, Emmanuel Quevillon wrote:
By the way, I use a self coded 'new' method to create my object.
Would it be the problem?
Yes. But you omitted the code that doesn't work, so... Good luck!
/joel
oops sorry,
sub new {
my($class, %args) = @_;
my $self = $class-SUPER::new(%args);
$self-_init(%args);
$self-_build_types(%args);
return $self;
}
Later in the code is try $self-so_type(), nothing is returned...
Honestly, this should work, however you very well might be doing
something in _init or _build_types that causes the problem. Perhaps
showing us some more code would help.
You might also try changing your new to this:
sub BUILD {
my($self, $args) = @_;
$self-_init(%$args);
$self-_build_types(%$args);
}
.. which is a little more Moosey.
- stevan
I tried without success :
Here are the methods :
sub BUILD {
my($self, $args) = @_;
$self-_init(%$args);
$self-_build_types(%$args);
}
sub _init {
my($self, %args) = @_;
my($output, $cut_type, $format, $style) =
$self-_rearrange([qw/OUTPUT CUT_TYPES FORMAT STYLE/], %args);
$format$self-_set_format (lc($format));
$cut_type $self-_set_cut_types($cut_type);
$self-_set_style (lc($style) || 'text');
$self-_set_output($output);
return $self;
}
sub _build_types {
my($self, %args) = @_;
$self-{_types} = [ ];
foreach my $type (sort { $a cmp $b } @{$self-cut_types()}){
$type = lc($type);
my $obj = Bio::Restriction::Analysis::FramedCut::$type;
$self-add_type($obj-new(%args));
}
return;
}
If I put some print into these method, nothing is printed out on my
screen. Looks like there are not called at all. :(
I'm really lost :(
Le 5 mars 2010 à 16:53, Chris Fields cjfie...@illinois.edu a écrit :
Emmanuel,
Are you trying to wrap bioperl modules? The use of $self-_rearrange()
gives it away, not to mention the 'so:x' (sequence ontology).
You should probably use delegation, or something like MooseX::NonMoose;
bioperl's class structure has issues (believe me, I'm a core dev for the
project).
chris
(PS: FWIW, I'm rewriting some of the core modules in Moose but they need
serious work)
On Fri, 2010-03-05 at 15:49 +0100, Emmanuel Quevillon wrote:
Stevan Little wrote:
On Mar 5, 2010, at 9:06 AM, Emmanuel Quevillon wrote:
Joel Bernstein wrote:
On 5 Mar 2010, at 13:37, Emmanuel Quevillon wrote:
By the way, I use a self coded 'new' method to create my object.
Would it be the problem?
Yes. But you omitted the code that doesn't work, so... Good luck!
/joel
Re: How to ...
Thanks Chris you lighted my lantern about differences between Moose
and BioPerl behaviors. Great!
Emmanuel
Le 5 mars 2010 à 17:55, Chris Fields cjfie...@illinois.edu a écrit :
On Mar 5, 2010, at 10:35 AM, Emmanuel Quevillon wrote:
Hi Chris,
I know you're a core dev;)
Well not a wrapper I'm just extending restriction::analysis and
wanted to do it with moose. But apparently it is much difficult
than expected.
Moreover I'm nit really comfortable with moose, I must admit I
don't understand all the concepts :(.
I didn't realize 'rearrange' would break moose. But anyway it looks
like even the subs around moose'new methods are not called. It is
really obscure for me at this time.
It's not that it breaks moose (or vice versa). BioPerl has a
specific named argument syntax and related methods that are
problematic when mixed with Moose; in BioPerl all named arguments in
bioperl start with '-' to distinguish them from simple positional
arguments. With Moose OTOH, I think everything is treated as named
by default in the constructor (e.g. no '-' needed), but the behavior
can be overridden with BUILDARGS (please correct me if I'm wrong
moose illuminati).
Regardless I'm pretty sure _rearrange() doesn't work w/o '-', so I
could definitely foresee some problems here going back and forth
between Moose and BioPerl without doing some work in BUILDARGS.
Either I'll stay with the current biopel code structure or if
someone has an explanation
I wouldn't want to dissuade you from using Moose; I'm using it
extensively in non-bioperl-based work, along with DBIx::Class.
Hence the reason I'm writing up a library of Moose-based BioPerl
classes.
Anyway, I suggest MooseX::NonMoose (I see Stevan and Jesse have
already responded likewise) and going from there.
Anyway thanks for your helps
Emmanuel
np.
chris
Le 5 mars 2010 à 16:53, Chris Fields cjfie...@illinois.edu a écr
it :
Emmanuel,
Are you trying to wrap bioperl modules? The use of $self-
_rearrange()
gives it away, not to mention the 'so:x' (sequence ontology).
You should probably use delegation, or something like
MooseX::NonMoose;
bioperl's class structure has issues (believe me, I'm a core dev
for the
project).
chris
(PS: FWIW, I'm rewriting some of the core modules in Moose but
they need
serious work)
On Fri, 2010-03-05 at 15:49 +0100, Emmanuel Quevillon wrote:
Stevan Little wrote:
On Mar 5, 2010, at 9:06 AM, Emmanuel Quevillon wrote:
Joel Bernstein wrote:
On 5 Mar 2010, at 13:37, Emmanuel Quevillon wrote:
By the way, I use a self coded 'new' method to create my
object.
Would it be the problem?
Yes. But you omitted the code that doesn't work, so... Good
luck!
/joel
oops sorry,
sub new {
my($class, %args) = @_;
my $self = $class-SUPER::new(%args);
$self-_init(%args);
$self-_build_types(%args);
return $self;
}
Later in the code is try $self-so_type(), nothing is returned...
Honestly, this should work, however you very well might be doing
something in _init or _build_types that causes the problem.
Perhaps
showing us some more code would help.
You might also try changing your new to this:
sub BUILD {
my($self, $args) = @_;
$self-_init(%$args);
$self-_build_types(%$args);
}
.. which is a little more Moosey.
- stevan
I tried without success :
Here are the methods :
sub BUILD {
my($self, $args) = @_;
$self-_init(%$args);
$self-_build_types(%$args);
}
sub _init {
my($self, %args) = @_;
my($output, $cut_type, $format, $style) =
$self-_rearrange([qw/OUTPUT CUT_TYPES FORMAT STYLE/], %args);
$format$self-_set_format (lc($format));
$cut_type $self-_set_cut_types($cut_type);
$self-_set_style (lc($style) || 'text');
$self-_set_output($output);
return $self;
}
sub _build_types {
my($self, %args) = @_;
$self-{_types} = [ ];
foreach my $type (sort { $a cmp $b } @{$self-cut_types()}){
$type = lc($type);
my $obj = Bio::Restriction::Analysis::FramedCut::$type;
$self-add_type($obj-new(%args));
}
return;
}
If I put some print into these method, nothing is printed out on my
screen. Looks like there are not called at all. :(
I'm really lost :(
Le 5 mars 2010 à 16:53, Chris Fields cjfie...@illinois.edu a écr
it :
Emmanuel,
Are you trying to wrap bioperl modules? The use of $self-
_rearrange()
gives it away, not to mention the 'so:x' (sequence ontology).
You should probably use delegation, or something like
MooseX::NonMoose;
bioperl's class structure has issues (believe me, I'm a core dev
for the
project).
chris
(PS: FWIW, I'm rewriting some of the core modules in Moose but
they need
serious work)
On Fri, 2010-03-05 at 15:49 +0100, Emmanuel Quevillon wrote:
Stevan Little wrote:
On Mar 5, 2010, at 9:06 AM, Emmanuel Quevillon wrote:
Joel Bernstein wrote:
On 5 Mar 2010, at 13:37, Emmanuel Quevillon wrote:
By the way, I use a self coded 'new' method to create my
object.
Would it be the
Re: How to quickly invalidate an object
Seems to me it would be better to get rid of the objects instead of trying to make them throw exceptions when they are touched. Do you have a real reason to leave these deleted objects around for people to call methods on? It seems a more sensible option would be to remove them with a Cundef $foo or something. - Stevan On Oct 19, 2009, at 7:44 PM, Yuri Shtil wrote: I designed an Moose object hierarchy that have: - simple(scalar) attributes like name etc - parametrized role based attributes and methods via MooseX::Role::Parameterized - regular Moose methods via MooseX::Method The objects represent persistent things in the back end like but not quite a database. Most of the objects can be deleted from the back end via the Remove method. This method marks the object as deleted, however the Perl object obviously exists until out of scope. The problem is that it still has all properties and methods and can be operated upon. What would be a quick way to disable (most) of its attribute and methods? For example I would like to leave the name attribute alone, but have all other attributes/methods throw an exception or set an error when invoked. -- Yuri
Re: How to quickly invalidate an object
2009/10/20 Yuri Shtil yu...@juniper.net: I thought a top posting was a no-no :-) . Please see my reply below. Bottom posting is even more annoying if you don't actually edit the quoted text.
Re: How to quickly invalidate an object
2009/10/20 Yuri Shtil yu...@juniper.net:
The problem is that it still has all properties and methods and can be
operated upon.
What would be a quick way to disable (most) of its attribute and methods?
For example I would like to leave the name attribute alone, but have all
other attributes/methods throw an exception or set an error when invoked.
Separate those attributes into a separate role or base class, and then
create a class:
package Disabled;
use Moose;
use Carp;
use namespace::clean;
extend Base::Class;
sub AUTOLOAD { croak This object is no longer active }
to disable an object, rebless to that class:
sub remove { bless $_[0], Disabled }
Re: How to make this nicer
Hans Dieter Pearcey wrote: On Sun, May 03, 2009 at 11:00:30AM -0700, Yuri Shtil wrote: I have a bunch of subclasses of X like this all having similar code. For example in the class X::Procedure I would have the same code with procedure replaced by step. use MooseX::Role::Parameterized hdp. This works perfectly, thank you. I have one more question. How do I access the container object (where the with is) from the role method? -- Yuri
Re: How to make this nicer
Chris Prather wrote: On Thu, Jun 4, 2009 at 10:34 PM, Yuri Shtilyu...@juniper.net wrote: How do I access the container object (where the with is) from the role method? $self ? -Chris The first thing on the arg list to self is the parameter, no self here. The named parameter consumer points to Moose::Meta::Class. How do I extract the real class from it? -- Yuri
Re: How do I do this the Moose way?
MooseX::ClassAttribute would likely help.
However what your doing is not really all that bad if your only doing
it in one place.
Personally I would make the dbh a regular attribute and use some kind
of dependency injection to provide the actual DBI handle.
- Stevan
On May 5, 2009, at 12:59 PM, Dan Horne wrote:
Hi
I have an application base class that is inherited by all classes
within an application. It has a couple of globals that are also
accessible to the subclasses - namely a database handle and a
Log4perl logger. For example, the db handle code looks something like:
our $DBH;
sub dbh {
my $self = shift;
unless ($DBH) {
$DBH = DBI-connect(...);
}
return $DBH;
}
How would I go about achieving this functionality using a Moose idiom?
Dan
Re: How to make this nicer
On Sun, May 03, 2009 at 11:00:30AM -0700, Yuri Shtil wrote: I have a bunch of subclasses of X like this all having similar code. For example in the class X::Procedure I would have the same code with procedure replaced by step. use MooseX::Role::Parameterized hdp.
Re: how to trigger actions on Role use
On Thu, Apr 23, 2009 at 03:57:32PM +0100, Mark Morgan wrote: Cheers to both yourself and Steven Little. That looks to do exactly what I was looking for. I didn't like my current implementation, but couldn't find an alternate way of doing same. A parameterized role might still be the wrong way of conceptualizing it; for example, if you just want a way to essentially curry in some defaults for creating attributes, making some sugar around has() with Moose::Exporter would be better. It's hard to tell from your example whether there's really a meaningful set of behaviors encapsulated by this role (and has some attributes that look like this, without consistent names doesn't count). Depending on the number of possible values for 'boolean_filters', and their possible variance in definition, it could make more sense to make a role per filter. (stevan suggested this on irc.) Anyway, roles are awesome, but not the solution to every problem. hdp.
Re: how to trigger actions on Role use
On Thu, Apr 23, 2009 at 02:43:37PM +0100, Mark Morgan wrote:
Based on the above, the adding of the attributes should be done for
the entire class once, when the role is first used. I don't like
having to wrap constructor creation to handle this, better that there
should be an on-role-included hook that could be tied into. Does such
exist? I've not seen anything documented for this type of behaviour.
No, and it usually means you're doing something wrong. Adding new attributes
to a *class* when you create an *object* definitely fits. Use
MooseX::Role::Parameterized.
package DoesBooleanFilter;
use MooseX::Role::Parameterized;
parameter boolean_filters = (isa = 'ArrayRef[Str]', required = 1);
role {
my $p = shift;
for my $filter (@{ $p-boolean_filters }) {
has $filter = (
is = 'ro',
predicate = has_$filter,
);
}
};
package SomeClass;
use Moose;
with 'DoesBooleanFilter' = { boolean_filters = [ qw(hello goodbye) ] };
hdp.
Re: How to call post-constructor automatically
BUILD if I recall is called on every class in the inheritance chain so you
would only need it set once to get this behavior.
--Original Message--
From: Yuri Shtil
To: Yuval Kogman
Cc: moose@perl.org
Sent: Oct 20, 2008 6:23 PM
Subject: Re: How to call post-constructor automatically
Yuval Kogman wrote:
On Thu, Oct 16, 2008 at 14:38:37 -0700, Yuri Shtil wrote:
The trick is I want the method be called implicitly as a part of new.
It is almost as having a hidden subclass of Two with a call to
post_constructor in its BUILD method.
I think this is exactly what you want,
sub BUILD {
shift-post_constructor;
}
in Two will work as you expect.
That will be called even if a subclass adds another BUILD method,
but of course 'post_constructor' will be overridable normally (i'm
guessing that's why you don't want to just use BUILD?).
Thank you Yuval,
However I want to avoid putting the call into each BUILD that is the
last in the hierarchy. If I decide to subclass from Two, I have to move
the call manually. The idea behind my question is to be able to check if
all constructors worked correctly, for example consumed all named
parameters.
--
Yuri
Sent via BlackBerry from T-Mobile
Re: How to call post-constructor automatically
On Thu, Oct 16, 2008 at 14:38:37 -0700, Yuri Shtil wrote:
The trick is I want the method be called implicitly as a part of new.
It is almost as having a hidden subclass of Two with a call to
post_constructor in its BUILD method.
I think this is exactly what you want,
sub BUILD {
shift-post_constructor;
}
in Two will work as you expect.
That will be called even if a subclass adds another BUILD method,
but of course 'post_constructor' will be overridable normally (i'm
guessing that's why you don't want to just use BUILD?).
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
Re: how to handle error with type constraint
Hi John,
Thanks for you reply.
My example is just academic, as I am only starting playing with Moose.
My application will have to issue reports and retrieve some indicators on
various equipments on a network backbone.
I will to open tcl, and snmp session for each equipment. Now, my plan is to
initiate those sessions, set some environment variables, perform some basic
task while the object get instantiated.
I am trying to figure out the best way to encapsulate those sessions and
report some failure to the caller.
If someone has some good advises on how to achieve this...
Regards,
Vincent.
2008/9/22 John Napiorkowski [EMAIL PROTECTED]
--- On Mon, 9/22/08, vincent roudil [EMAIL PROTECTED] wrote:
From: vincent roudil [EMAIL PROTECTED]
Subject: how to handle error with type constraint
To: moose@perl.org
Date: Monday, September 22, 2008, 9:40 AM
Hello Moose,
I am just starting to explore Moose. This is probably
something simple, but
I can't figure out the best way to do this.
With the Moose type constraint, I would like to get control
of the error
handling when the type is invalid.
Here is an example.
a class host, with 2 attributes, name and ip_addr, with a
control on the IP
address validity:
# package host.pm
package host;
use Moose;
use Moose::Util::TypeConstraints;
use Regexp::Common qw /net/;
subtype IPAddr
= as Str
= where {/^$RE{net}{IPv4}$/}
= message { 'invalid IP address'};
has 'ip_addr' = (isa = 'IPAddr', is
= 'ro', required = 1);
has 'name' = (isa = 'Str', is
= 'ro', required = 1);
1;
# end package host.pm
The type constraints works fine. Only that when the IP
address is invalid
the program dies, with great verbosity.
I would just like when IP address is invalid, to print a
message in a log
file, and that the creation of the instance fails quietly,
so I could use
the host class like this:
# main.pl:
use host;
my $h=host-new(name='jupiter',
ip_addr='10.10.10.1');
if ($h) {
print $h-name. created successfully with the IP
address .$h-ip_addr;
}
If someone could point me to the right direction, that
would be great.
Thanks in advance.
Vincent.
Hey,
For me I would try to clearly separate my business logic validation needs
from type constraints on my storage classes or domain model. There are a
few reasons for this, mostly having to do with separation of concerns and
the fact that incoming user data will likely have a few different validation
paths at some point. Also you can create reuseable validation classes.
I don't know your exact problem domain, but for me as a web developer I am
doing a lot of validation and error messaging for incoming post params. For
that I use Data::FormValidator, and make as many custom classes as I need.
Then I'd try to have some sort of workflow on the incoming params to first
validate and then if valid pass on to the domain model. I try to see my
type constraints as a sort of last chance to catch problems before they
generate a hard error in my database.
The only downside to my method is that you end up rewriting validation code
a few times. I know there are new tools cropping up to help with this,
Reaction and Ernst from what I understand are attempts to let you infer your
business validation needs from the type constraints on your storage object,
but yet retain enough flexibility when your business validation needs
different from the domain constraints. I haven't had time to play with
these yet, but maybe someone else on the list will jump in.
Until then I recommend having user input validation as a first layer before
it tries to hit your Moose attributes.
my $0.02
John Napiorkowski
Re: how to handle error with type constraint
--- On Mon, 9/22/08, vincent roudil [EMAIL PROTECTED] wrote:
From: vincent roudil [EMAIL PROTECTED]
Subject: how to handle error with type constraint
To: moose@perl.org
Date: Monday, September 22, 2008, 9:40 AM
Hello Moose,
I am just starting to explore Moose. This is probably
something simple, but
I can't figure out the best way to do this.
With the Moose type constraint, I would like to get control
of the error
handling when the type is invalid.
Here is an example.
a class host, with 2 attributes, name and ip_addr, with a
control on the IP
address validity:
# package host.pm
package host;
use Moose;
use Moose::Util::TypeConstraints;
use Regexp::Common qw /net/;
subtype IPAddr
= as Str
= where {/^$RE{net}{IPv4}$/}
= message { 'invalid IP address'};
has 'ip_addr' = (isa = 'IPAddr', is
= 'ro', required = 1);
has 'name' = (isa = 'Str', is
= 'ro', required = 1);
1;
# end package host.pm
The type constraints works fine. Only that when the IP
address is invalid
the program dies, with great verbosity.
I would just like when IP address is invalid, to print a
message in a log
file, and that the creation of the instance fails quietly,
so I could use
the host class like this:
# main.pl:
use host;
my $h=host-new(name='jupiter',
ip_addr='10.10.10.1');
if ($h) {
print $h-name. created successfully with the IP
address .$h-ip_addr;
}
If someone could point me to the right direction, that
would be great.
Thanks in advance.
Vincent.
Hey,
For me I would try to clearly separate my business logic validation needs from
type constraints on my storage classes or domain model. There are a few
reasons for this, mostly having to do with separation of concerns and the fact
that incoming user data will likely have a few different validation paths at
some point. Also you can create reuseable validation classes.
I don't know your exact problem domain, but for me as a web developer I am
doing a lot of validation and error messaging for incoming post params. For
that I use Data::FormValidator, and make as many custom classes as I need.
Then I'd try to have some sort of workflow on the incoming params to first
validate and then if valid pass on to the domain model. I try to see my type
constraints as a sort of last chance to catch problems before they generate a
hard error in my database.
The only downside to my method is that you end up rewriting validation code a
few times. I know there are new tools cropping up to help with this, Reaction
and Ernst from what I understand are attempts to let you infer your business
validation needs from the type constraints on your storage object, but yet
retain enough flexibility when your business validation needs different from
the domain constraints. I haven't had time to play with these yet, but maybe
someone else on the list will jump in.
Until then I recommend having user input validation as a first layer before it
tries to hit your Moose attributes.
my $0.02
John Napiorkowski
Re: how to handle error with type constraint
Vincent,
The simplest way to do this is to catch the exception, so wrap the
object creation inside an eval { } and if you get an exception write
the info to your log file.
There is a way to alter the Moose error handling behavior, but it
would be overkill in this case where simple exception handling would
suffice.
- Stevan
On Sep 22, 2008, at 9:40 AM, vincent roudil wrote:
Hello Moose,
I am just starting to explore Moose. This is probably something
simple, but
I can't figure out the best way to do this.
With the Moose type constraint, I would like to get control of the
error
handling when the type is invalid.
Here is an example.
a class host, with 2 attributes, name and ip_addr, with a control
on the IP
address validity:
# package host.pm
package host;
use Moose;
use Moose::Util::TypeConstraints;
use Regexp::Common qw /net/;
subtype IPAddr
= as Str
= where {/^$RE{net}{IPv4}$/}
= message { 'invalid IP address'};
has 'ip_addr' = (isa = 'IPAddr', is = 'ro', required = 1);
has 'name' = (isa = 'Str', is = 'ro', required = 1);
1;
# end package host.pm
The type constraints works fine. Only that when the IP address is
invalid
the program dies, with great verbosity.
I would just like when IP address is invalid, to print a message in
a log
file, and that the creation of the instance fails quietly, so I
could use
the host class like this:
# main.pl:
use host;
my $h=host-new(name='jupiter', ip_addr='10.10.10.1');
if ($h) {
print $h-name. created successfully with the IP address .$h-
ip_addr;
}
If someone could point me to the right direction, that would be great.
Thanks in advance.
Vincent.
