Re: [Catalyst] $c->user->some_relationship always retrives user id from the db
> Which means the entire thing would be pointless. What you want to do
> really is
>
> $class->new({ %saved_stuff, -result_source => $schema->source($class) });
> $new_obj->in_storage(1);
>
> then it'll work "as if" you re-fetched the object (%saved_stuff being the
> return of $obj->get_columns). Making stuff work with only the PK stashed
> in the session is left as an exercise to the reader, but would probably
> be best done using Data::Thunk and Data::Swap.
/me confoos. Why not just use the shiny new freeze / thaw hooks?
Wouldn't it make sense to store a frozen version of the User row /
object in the session and then thaw it upon request? This seems like
it would be a really natural way to cache this information. Ideally,
the thawing would be a lazy operation as well i think.
I just bring this up because the code you just sent would not work
when one is using things like DigestColumns or EncodedColumn, which
are most commonly seen in User-type objects
--Guillermo Roditi (groditi)
___
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] $c->user->some_relationship always retrives user id from the db
> > I just bring this up because the code you just sent would not work
> > when one is using things like DigestColumns or EncodedColumn, which
> > are most commonly seen in User-type objects
>
> Don't those allow you to have a 'password' attribute stored in a
> 'password_hash' column or similar now?
>
> Anything else is going to clash somewhere or other.
EncodedColumn overrides set_column() i was originally wrapping the
accessor, but I couldn't find way to do that without messing with the
symbol table so, at the advice of claco, I overrode set_column() and
new() to encode the value at set time. I guess I could have created a
new accessor, or an expicit set_$column_from_plaintext() method, but I
never really thought about that. In any case, how would
update({password=> $xyz}) new({password => $xyz}) work? password =>
$xys would encode the value but password_hash => $xyz would keep it
untouched? I don't really know how I feel about creating such a
virtual column. It's doable but it means that columns would have to be
renamed to not conflict with the accessor. You eally should have
brought something like this up before release--there was no shortage
of emails sent to the list with regards to the proposed API and
behavior and you were present in IRC during the design discussions...
Anyone else have thoughts?
--Guillermo Roditi (groditi)
___
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] [OT] Request for help
Hi everyone, First, let me apologize if you are seeing this twice as a result of the cross post. As some of you may know, apart from being a module developer and occasional presence of the lists and IRC, I am a student of Economics at Northeastern University. I am preparing the final research paper for my Senior Economics Seminar and I was hoping that those of you who have participated in open source hacking while employed could help me out by answering couple of short questions. This only applies to those of you who have either contributed, or paid someone to contribute to an OSS while "on the clock". Please, please, please take 2 mins to answer (it's mostly one word answers) and send it back to [EMAIL PROTECTED] (don't reply to the list!) 1.) Name / alias, (last name optional) 2.) Company where development took place (optional) 3.) Were any of the contributions made simply to satisfy a license? (Yes, No) 4.) Were any releases, contributions made even though the license did not require you too? (yes, no) 5.) Was management, or your corporate environment receptive to participating in OSS? (yes, no) 6.) Why do you choose to participate in OSS? 7.) Do you feel there is an indirect return to contributing to OSS, and if so, what is it for you? 8.) Estimated value or (?:wo)?man-(?:months|days) of your yearly contributions ( optional ) Feel free to use your ohloh figures if you think they are accurate. Thank you so much to whoever can help! I need answers by Wednesday Mar 26 at the latest. I slacked off on my homework because I was too busy hacking on open source! If you know anyone else who wouldn't mind answering this please feel free to forward this. Remember, the more answers I get, the quicker I'll be able to resume helping the Moose + Catalyst effort. Thanks again, -- Guillermo Roditi (groditi) ___ 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] storing a list of items into the session
> $c->session->{mandator} = $c->model('MotsDB::Mandator')->find();
> $c->session->{mandators} = $c->model('MotsDB::Mandator');
I see two potential problems here
You are trying to store a resultset into the session. I made this same
mistake when I started using catalyst, don't worry. What's happening
is that your object is being serialized in between page views and you
are losing the DB connection there. DBIC allows you to freeze and thaw
objects and restore connections pretty easily, see the POD in
DBIx::Class::Schema for more info. I know that the object you got
using find() appears to work, but relationships will be broken. Either
properly freeze and thaw objects, or fetch them in every request.
Other potential problem
in scalar context $c->model('MotsDB::Mandator'); which is
functionally equivalent to $schema->resultset('Mandator') returns a
resultset, nor a list. If you would like to obtain the actual objects
instead of the resultsets use [ $c->model('MotsDB::Mandator') ] or
$c->model('MotsDB::Mandator')->all. The previous creates an arrayref
of all the items and the later returns a list of all the items
--
Guillermo Roditi (groditi)
___
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] Actions as Moose::Role
> Well - I was not sure about that - but with "use base > 'Catalyst::Controller';" I get: > > Could not load class (Base) because : Can't locate object method > "linearized_isa" via package "Moose::Meta::Role" at > > /home/zby/progs/Catalyst-Runtime/5.80/branches/moose/lib/Catalyst/ClassData.pm > line 23. Roles can't have base classes kids! The attributes problem is a known issue and it kills me as well and I promise you I am trying to fix it. Just give me some time and hopefully by the time we are merged back to 5.8 trunk then I'll have come up wit a work-around or a fix. It all stems from the compile vs run time thing (moose = run time). Ideas welcome -- Guillermo Roditi (groditi) ___ 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] Catalyst-Runtime 5.8000_04 shipped to CPAN
All of you who have experienced errors rooted in MooseX::Emulate/Adopt::Class::Accessor::Fast please please please send me error messages and show me the code that breaks. I think the trunk version fixes all your problems, but nobody has been able to accurately describe their problems or produce a simple failing test case. So, if my code is breaking your code, holla back! -- Guillermo Roditi (groditi) ___ 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] Catalyst-Runtime 5.8000_04 shipped to CPAN
On Sun, Dec 7, 2008 at 1:47 PM, Tomas Doran <[EMAIL PROTECTED]> wrote:
>
> I'm not sure if the correct fix for the lies in Catalyst, or MX::E::CAF,
> but:
>
> http://dev.catalystframework.org/svnweb/Catalyst/revision?rev=8781
>
> is the minimal test case I've been able to produce for the breakage of the
> Catalyst::Plugin::Authentication's tests and which people still using the
> back-compat auth plugins in their apps would be seeing (if any of them were
> trying it and shouting).
>
I think it's the fact that the mk_accessor call is in BEGIN {} because the
adopt happens at compile time, but the role application within it happens at
runtime.
I am giving this a wontfix until I can figure out if it is even fixable. I'm
not giving up on you, though. Why is it necessary to have the accessors
created at BEGIN time?
I'll experiment with having the role consumption happen in a BEGIN block,
but I don't know what the deal will be with it. I'll keep you all posted.
--
Guillermo Roditi (groditi)
___
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] Catalyst-Runtime 5.8000_04 shipped to CPAN
On Sun, Dec 7, 2008 at 4:38 PM, Tomas Doran <[EMAIL PROTECTED]> wrote: > > Please find attached a simple test case for the behavior needed by > Catalyst::Plugin::Cache::Curried (and anything else which says > __PACKAGE__->mk_accessors(qw/ meta /)) - found by looking at MojoMojo's > current test failures. Yeah dude. wontfix. You don't get to take over Moose's "meta" method. Immutable replaces the accessor when inlining the meta method. You can argue with Moose over who has the right to that particular method name, but that's out of the scope of my module. -- Guillermo Roditi (groditi) ___ 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] Catalyst-Runtime 5.8000_04 shipped to CPAN
On Tue, Dec 9, 2008 at 9:35 AM, Tomas Doran <[EMAIL PROTECTED]> wrote: > > I agree that all 'real' Moose classes shouldn't be breaking the meta method > like this, but the fact is that there *IS* real code out there which is > going to be broken by this, and it's something which we can _avoid_ breaking > without too much effort.. > As agreed, we'll replace calls to ->can with calls to ->meta->has_method to fix this. We will also have to use Class::MOP directly to find the metaclass instead of using ->meta. So, problem resolved, fix known. will fix and release when i have some time. some time later this week, maybe next. ___ 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] Catalyst-Runtime 5.8000_04 shipped to CPAN
> > HTML::Widget uses Class::Accessor::Chained::Fast, which overrides > make_accessor. As mk_accessors no longer uses make_accessor to generate the > coderef, this breaks horribly... > Uhm. wontfix? I don't even know how it would be possible to fix this. We'll stop using Adopt::CAF by default, which should stop these kinds of breakages. -- Guillermo Roditi (groditi) ___ 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] Catalyst-Runtime 5.8000_04 shipped to CPAN
> > Catalyst::Plugin::HashedCookies calls Catalyst::Request->make_accessor, > which in some ways is quite broken (as you're re-opening the package from > outside), but it isn't actually very hard to fix/support.. > Yeah, that's totally broken and I don't even know if we want to support this kind of behavior. mst suggested to "just die()" and I'm with him on this one. While I agree that just letting the code puke all over itself is ENOGOOD I think an explicit exception is not unreasonable. -- Guillermo Roditi (groditi) ___ 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] Catalyst-Runtime 5.8000_04 shipped to CPAN
> I've found some plugins which call mk_accessors more than once for the same > attribute / package, which fails. > > This is because, on the second application, the attribute is added with no > options, which results in the accessor methods for it being removed. Please > find test attached. > Fixed in trunk, your test added. -- Guillermo Roditi (groditi) ___ 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] catamoose now or when?
As one of the developers of Catalyst 5.8 and someone well-acquainted with both Moose and Catalyst and the Moose port of Catalyst, I would advise you to develop on 5.71, for 5.71 and keep an alternate test environment on which to test against 5.8. Once 5.8 is released and is on CPAN, go ahead and start developing for that. Until then, I wouldn't rush, back compat is there and you really do not want to have an app require something that is not on CPAN. On Wed, Mar 4, 2009 at 8:52 PM, Elliot Finley wrote: > Hello, > > I'm starting a new web app project that I need to deploy in about 2 > months. There will be ongoing updates to this app as time goes by. I'm new > to catalyst/moose/dbic but a long time Perl hacker. > > Considering the above, would I be better off starting with 5.71 or 5.8? > > TIA, > Elliot > > ___ > 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/ > -- Guillermo Roditi (groditi) ___ 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/
