Re: [Catalyst] Squatting::On::Catalyst
On Tue, Jul 29, 2008 at 02:08:21PM +0100, Chisel Wright wrote: On Tue, Jul 29, 2008 at 02:21:10PM +0200, Daniel McBrearty wrote: 1. letting users keep existing member and login creds 2. being able to cross ref to other parts of the site eg. for a certain node, easily have a discussion link, and the reverse link from the forum If you ever think of a good way of doing this, please let me know! Starter for 10. Controller Page discussion_controller MyForum::Thread discussion_action view discussion_field thread_id /Controller $c-uri_for( $c-controller($self-discussion_controller) -action_for($self-discussion_action), [ $current_page-id ] ); -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ 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] Duplicate entries with C::P::Session::Store::DBIC and MySQL
On Tue, Jul 29, 2008 at 12:49:17PM +0200, Tobias Kremer wrote:
Quoting Tobias Kremer [EMAIL PROTECTED]:
However, I'm unsure how to detect if the error really was a duplicate entry
error or something else.
die $@ if $@ $@ !~ /duplicate/i;
This doesn't work because different DBs throw different errors.
Also, flash() is supposed to always return a flash entry. So in case of a
duplicate error we'd have to do another find(). That'd be 3 queries in the
worst case.
Maybe it'd be better to ditch find_or_create in favor of something like this:
eval {
$row = $self-model-create( { ... } );
}
if( $@ $@ =~ /duplicate/ ) { # the question about detecting this remains
$row = $self-model-find( { ... } );
}
This would reduce the query to 1 at best and 2 at worst. On the other hand, I
fear that it's still possible that the find() doesn't actually find a row
because it was deleted in the meantime by the other request :(
It's still probably viable.
What I'd really like is to add some code to DBIC's storage to know what re
that /duplicate/ is on whatever DB so we can bury this away from the user
and DBIC can Just Use It for find_or_create on any supported database.
Maybe you could wander over to the DBIC list and poke at patching that
instead?
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
___
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] Squatting::On::Catalyst
On 30 Jul 2008, at 02:27, John Beppu wrote: On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty [EMAIL PROTECTED] wrote: my 0.05 (possibly a bit OT) : Off-topic or not, I think these are interesting and valid questions. I looked previously at a few ways of adding forums etc to the site using 3rd party code, indeed there are many possibilites (some perl, some not) The thing that was always a sticker for me was getting some kind of logical integration, ie: 1. letting users keep existing member and login creds Now that composition and embedding of web apps is becoming a reality, we have to start anticipating needs like this. For example, the documentation for an app that's built to be embedded could state that: It expects a user object to be in its session's u key. The app will expect to be able to call the -name method on this user object. (Some apps may want more... others less... this is just a hypothetical example.) If that key is undef, the app will assume the current session is not in a logged in state. I think being up-front about login policy would be enough to share users across multiple web apps joined together as one cohesive unit. I dont. Lets take the example of embedding a forum. It will most likely store its data in a DB of its own design. It will also quite likely have its own user table, and have FKs referencing that table see the problem? There's more to sharing users than just logging. I can't really see any way around that other than on a case-by-case basis sadly. Someone please feel free to correct me. -ash___ 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] Configuring a Controller from the config file
Hi,
I tried to set some config options for a controller with the config
file.
YAML-code:
---
name: MyApp
Controller::Root:
key: value
I'm using ConfigLoader and the debug shows that it successfully loaded
the yaml file.
In a method in my Root controller I tried to access those config
options via $self-config.
I had no luck. $c-config shows the hole config. I could access the
config options via
$c-config-{Controller::Root} but shouldn't it avaiable via $self-
config?
What am I missing?
moritz
___
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] Configuring a Controller from the config file
On Wed, Jul 30, 2008 at 8:38 AM, Moritz Onken [EMAIL PROTECTED] wrote:
---
name: MyApp
Controller::Root:
key: value
I had no luck. $c-config shows the hole config. I could access the config
options via
$c-config-{Controller::Root} but shouldn't it avaiable via $self-config?
You should use either $self-{key} or do the following:
__PACKAGE__-mk_accessors( 'key );
and then you can use $self-key to get that information.
-Brian
___
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] Squatting::On::Catalyst
--- On Wed, 7/30/08, Ash Berlin [EMAIL PROTECTED] wrote: From: Ash Berlin [EMAIL PROTECTED] Subject: Re: [Catalyst] Squatting::On::Catalyst To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Wednesday, July 30, 2008, 7:02 AM On 30 Jul 2008, at 02:27, John Beppu wrote: On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty [EMAIL PROTECTED] wrote: my 0.05 (possibly a bit OT) : Off-topic or not, I think these are interesting and valid questions. I looked previously at a few ways of adding forums etc to the site using 3rd party code, indeed there are many possibilites (some perl, some not) The thing that was always a sticker for me was getting some kind of logical integration, ie: 1. letting users keep existing member and login creds Now that composition and embedding of web apps is becoming a reality, we have to start anticipating needs like this. For example, the documentation for an app that's built to be embedded could state that: It expects a user object to be in its session's u key. The app will expect to be able to call the -name method on this user object. (Some apps may want more... others less... this is just a hypothetical example.) If that key is undef, the app will assume the current session is not in a logged in state. I think being up-front about login policy would be enough to share users across multiple web apps joined together as one cohesive unit. I dont. Lets take the example of embedding a forum. It will most likely store its data in a DB of its own design. It will also quite likely have its own user table, and have FKs referencing that table see the problem? There's more to sharing users than just logging. I can't really see any way around that other than on a case-by-case basis sadly. Someone please feel free to correct me. -ash --- On Wed, 7/30/08, Ash Berlin [EMAIL PROTECTED] wrote: From: Ash Berlin [EMAIL PROTECTED] Subject: Re: [Catalyst] Squatting::On::Catalyst To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Wednesday, July 30, 2008, 7:02 AM On 30 Jul 2008, at 02:27, John Beppu wrote: On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty [EMAIL PROTECTED] wrote: my 0.05 (possibly a bit OT) : Off-topic or not, I think these are interesting and valid questions. I looked previously at a few ways of adding forums etc to the site using 3rd party code, indeed there are many possibilites (some perl, some not) The thing that was always a sticker for me was getting some kind of logical integration, ie: 1. letting users keep existing member and login creds Now that composition and embedding of web apps is becoming a reality, we have to start anticipating needs like this. For example, the documentation for an app that's built to be embedded could state that: It expects a user object to be in its session's u key. The app will expect to be able to call the -name method on this user object. (Some apps may want more... others less... this is just a hypothetical example.) If that key is undef, the app will assume the current session is not in a logged in state. I think being up-front about login policy would be enough to share users across multiple web apps joined together as one cohesive unit. I dont. Lets take the example of embedding a forum. It will most likely store its data in a DB of its own design. It will also quite likely have its own user table, and have FKs referencing that table see the problem? There's more to sharing users than just logging. I can't really see any way around that other than on a case-by-case basis sadly. Someone please feel free to correct me. -ash I'm not sure we can have a fully sharable system for the reasons you mentioned. Everyone has particular needs and desires in the way they will name things, normalize/denormalise a database, etc. However I think it might be possible to define common functionality using Moose Roles and then letting people write their custom code against that. Then we could actually build shared bits that require models that do those roles. Something like: CatalystX-CommonModels /lib /CatalystX /CommonModels /Role User.pm /Provider Users.pm ..and so on for defining Controllers and commone View types, even Action objects. The common Role stuff would be defined by the community to have the minimal requirements. So then I could write a custom application, like say an addressbook app that expects a model that does the User Role. That User role could be defined by some existing other set of components, from maybe a Forum Application or just a roll your own application. This would enable interoperability without forcing a particular implementation. Your local implementation
Re: [Catalyst] 5.80 problem with Catalyst::Model::DBIC::Schema
On 18 Jul 2008, at 11:24, Tomas Doran wrote:
On 18 Jul 2008, at 04:14, Chris Dolan wrote:
So, I just tested 5.7099_02 to great success (bravo!) so I decided
to try 5.80 too.
When using SVN rev 8136, I get the error
-config-{schema_class} must be defined for this model
I am indeed setting that field (following the instructions in
Catalyst::Model::DBIC::Schema 0.20 to the letter) but it looks
like the schema_class is not getting propagated from the config to
the Catalyst::Model::DBIC::Schema instance via
Catalyst::Component::new.
Is this a known problem? Do I need any blead packages other than
Catalyst::Runtime for a proper test?
I haven't looked at this specific issue, but I'd be prepared to bet
it's a known issue, which I have looked into.
FYI, this issue has now been fixed.
Would be grateful if you could retest, and let us know if this fixes
the problem that you were seeing.
Cheers
t0m
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Squatting::On::Catalyst
The usual way to make things like this work is by having a standardised api. In the case of membership for a website, it might look something like: get_unique_user_id # of logged in user get_username_for_id( id ) Then if a forum has tables such as: thread - references username post - ditto and maybe methods like send_pm( user ) find_posts( user ) if you are prepared to sacrifice the actual foreign key relationship, not that big a thing IMHO, you can do it all through the API. The person that writes the forum code/schema can actually have two install options - with and without the user table. Cat almost has this in place at present. -- There's an infinite supply of time, we just don't have it all yet. ___ 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] deserializing key value pairs Catalyst::Controller::REST
Thanks Jochen and J.Shirley,
What I was trying to do is access parameters from the URL so i could have a
REST interface, something like
http://foo.bar.com/rest/v1/db/source_destination_mapt/1/destination_account/2
I ended up doing something like this
sub source_destination_map :Local :ActionClass('REST') {
my $self = shift;
my $c= shift;
$c-stash(source_account = shift);
$c-stash(@_);
}
and then access the parameters from the URI like this:
sub source_destination_map_GET {
}
sub source_destination_map_POST {
my $source_account = $c-{stash}-{source_account},
my $destination_account = $c-{stash}-{destination_account}
}
Are there some gotchas that i might be missing as a result of handling the
parameters like this for POST/PUT requests?
-Hani
On Fri, Jul 25, 2008 at 7:23 AM, J. Shirley [EMAIL PROTECTED] wrote:
On Fri, Jul 25, 2008 at 1:48 AM, Jochen Luig [EMAIL PROTECTED] wrote:
Hi Hani,
var postData =
source_account=1destination_account=2ingestor_id=10source_id=1
I think this is where it fails. As far as I can tell from your code,
postData should contain a JSON Object.
Try something like:
var postData = '{ source_account: 1, destination_account: 2,
ingestor_id: 10, source_id: 1 }';
On another note, make sure that YAHOO.util.Connect.asyncRequest doesn't
mess up your request somehow (is that YUI, btw?). I've just experienced
the same annoyance with Dojo, whose dojo.xhrPost is not exactly fond of
sending JSON-Objects. It helps to look at the request itself with some
tool like e.g. wireshark.
HTH,
Jochen
Right, Hani is sending url form encoded post body, which is not JSON
and will fail to be processed as JSON data. YUI can be used to
generate your JSON data, please read the documentation at
http://developer.yahoo.com/yui/json/
asyncRequest will not mess up any requests, I've thoroughly used YUI
in conjunction with C::C::REST and it has never let me down (IE6 is a
different story). As long as you stick to POST and GET, IE6 will be
fine.
Also, using Dumper inside of your controller is not recommended,
simply use the $c-log-_dump command. Additionally, using
$c-req-body is what C::C::REST uses, and after the deserialization
the data will be in $c-req-data and a simple:
$c-log-_dump( $c-req-data );
shows what exactly is in the request data that has been deserialized for
use.
___
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/
___
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] Squatting::On::Catalyst
--- On Wed, 7/30/08, Bruce Keeler [EMAIL PROTECTED] wrote: From: Bruce Keeler [EMAIL PROTECTED] Subject: Re: [Catalyst] Squatting::On::Catalyst To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Wednesday, July 30, 2008, 3:38 PM Daniel McBrearty wrote: The usual way to make things like this work is by having a standardised api. In the case of membership for a website, it might look something like: get_unique_user_id # of logged in user get_username_for_id( id ) Then if a forum has tables such as: thread - references username post - ditto and maybe methods like send_pm( user ) find_posts( user ) if you are prepared to sacrifice the actual foreign key relationship, not that big a thing IMHO, you can do it all through the API. The person that writes the forum code/schema can actually have two install options - with and without the user table. Cat almost has this in place at present. Seems to me the easiest way would be to have the forum module have it's own user table, keyed by the same user id as the core user table. Then it can store whatever it wants in there, like signatures, posting preferences or whatever. The core user table/object could have a few well-known attributes like real name, email address and so on, but not much else. If we could identify the core entities and attributes, we could write the generic interface and then write a default implementation in one or two of the popular or viable storage systems (DBIC comes to mind because that would be easy for me, as well as MooseX::Storage since that looks like it could be fun :) ) Then when someone creates a their Catalyst application, we say it's best practice that their User model either follow the interface (if they have to write their own, or have very custom needs) or extend one of the popular existing sample implementations. If they do that, what they get is the ability to just plug and run with any extended framework that needs that standard User object interface. Then we don't have to worry at all about how the implementation achieves it's ends, or if the developer has very custom needs. As long as the model implements the interface all will work as desired. After we had some common domain models we could move on and have similar for some basic things we all implement over and over, like a Login Controller, etc. We could stick all this under CatalystX namespace. How about 'CatalystX::DNA' or similar? Besides a User entity, what others do you all think we need? --jjnapiorkowski ___ 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/ ___ 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] 5.80 problem with Catalyst::Model::DBIC::Schema
On Jul 30, 2008, at 12:12 PM, Tomas Doran wrote:
On 18 Jul 2008, at 11:24, Tomas Doran wrote:
On 18 Jul 2008, at 04:14, Chris Dolan wrote:
So, I just tested 5.7099_02 to great success (bravo!) so I
decided to try 5.80 too.
When using SVN rev 8136, I get the error
-config-{schema_class} must be defined for this model
I am indeed setting that field (following the instructions in
Catalyst::Model::DBIC::Schema 0.20 to the letter) but it looks
like the schema_class is not getting propagated from the config
to the Catalyst::Model::DBIC::Schema instance via
Catalyst::Component::new.
Is this a known problem? Do I need any blead packages other than
Catalyst::Runtime for a proper test?
I haven't looked at this specific issue, but I'd be prepared to
bet it's a known issue, which I have looked into.
FYI, this issue has now been fixed.
Would be grateful if you could retest, and let us know if this
fixes the problem that you were seeing.
Cheers
t0m
Yep, that error is gone (tested 8171). The next error I see is:
[error] Caught exception in engine Can't use an undefined value as
an ARRAY reference at /Users/chris/Work/Catalyst/Catalyst-Runtime/
5.80/trunk/lib/Catalyst.pm line 1244.
where line 1244 is:
push( @{ $c-stack }, $code );
and stack comes from
has stack = (is = 'rw', default = sub { [] });
That looks pretty straightforward...
Email me off-list if I can provide any more helpful information about
my environment.
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/
