Re: [Catalyst] Instant CRUD with DBIC::Schema
On 03/10/2008 07:14 AM, Zbigniew Lukasiak wrote: Hi Peter, On Wed, Feb 20, 2008 at 7:48 PM, Peter Karman [EMAIL PROTECTED] wrote: Also look at CatalystX::CRUD::Model::DBIC. Feedback appreciated. I had today another look at CatalystX::CRUD - it is promising, but I think there is too many indirection layers in it. I usually fault the other direction, so that's an interesting read. For DBIC it requires configuration of both CatalystX::CRUD::Model::DBIC and CatalystX::CRUD::Object::DBIC. I believe it could work with just one - for example CatalystX::CRUD::Model::DBIC where you could configure what methods on the object and how to call them to implement the needed interface. Or perhaps you could all of it move to CatalystX::CRUD::Model and add configuration to interface it to DBIC and RDBO - they are not that different. What do you think? I believe some reduction of the number of modules used will simplify the whole thing. :) could be said for Catalyst in general... Maybe we could start the discussion with what you interface you need from the database model? My assumptions are: 1. CRUD is not just databases. I have a CatalystX::CRUD::Model::SVN and CatalystX::CRUD::Model::File (the latter as part of the core CX::CRUD dist). I'm also going to be working on a ::LDAP implementation, which is a database but not a SQL-based ORM type one. 2. The Model class interacts with many Objects. The Model searches and fetches, returning array or iterator or count. The Object is singular. It creates/reads/updates/deletes one item (a db row, a file, etc). I know that the DBIC ResultSet combines some of those features into one class, allowing you to update/delete/etc multiple rows at a time. I find that less simple, conceptually, even if it is more convenient to use. Simple is not always the same as convenient, in my book. Or otoh, a simple user interface might well be convenient to the user, but a real pita (i.e. not simple) to the developer who must implement it. 3. Users of a CX::CRUD::Model::* should not, in the common case, need to override or configure the ::Object class. It's there to implement the basic create/read/update/delete methods for the Model-specific object. But it should be, for all practical purposes, invisible to the user. That's why there is evil AUTOLOAD hackery in the base Model. For a ORM like RDBO or DBIC, the Object class consists of easy pass-throughs to the appropriate method on the delegate() object. But check out CatalystX::CRUD::Object::File for one case where it is not so simple. If you need to override the behaviour of the ::Object class for any given CX::CRUD::Model, especially for an ORM, I suspect that it should really be overridden outside of Catalyst altogether, in the delegate class. These are thin Models. I do like the idea of simplifying. What I hear you saying is that getting rid of the Object class would simplify things. I don't think it would. I think it would require mixing 2 different concepts (the thing that gets objects, and the object itself). I tried to keep the API as high-level and simple as I could. Individual implementations (like that for RDBO and DBIC) can get more complicated because they have to implement an API that isn't necessarily like their own. I think of it like DBI and the various DBD drivers. That said, if you have specific changes you'd like to see, I'm open to persuasion. I'm just not persuaded yet. :) -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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] Base controllers and multiple inheritance
Byron Young wrote on 3/6/08 12:31 PM: $class-NEXT::new() doesn't do the right thing with this crazy diamond-ish inheritance I have, and I think using Class::C3 in my base classes while Catalyst::Controller and C::C::HTML::FormFu use NEXT is causing some problems. You might try the C::Plugin::C3 as well. IIRC, I had to do that when I mixed NEXT-based controllers with C3-based controllers. The plugin overrides NEXT to make it Just Work. As an aside -- I wish I had seen your CatalystX::CRUD::Controller before! I actually based mine off of your C::C::Rose::CRUD but wanted to use DBIC and C::C::HTML::FormFu, so I made my own. Anyway, kudos! Consider contributing a CX::CRUD::Controller::FormFu then! :) If you based yours off the Rose::CRUD API, you're mostly there. -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ 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] Base controllers and multiple inheritance
Byron Young wrote on 3/5/08 4:29 PM:
Everything looks good, right? My List actions work! However, the CRUD
actions don't work because the FormConfig actions seem to have been
ignored -- $c-stash-{form} is undef :(
I wouldn't expect anything in stash() to persist from request to request. Don't
do anything with stash during new(). new() is called once per app life, at
startup. stash() is for each request.
Does anyone have any suggestions? Should I just forego using new() and
do initial setup the first time auto() is called in each of my base
controllers?
depends on what kind of thing you are setting up. I have used multiple
inheritance in my controllers to good effect (see CatalystX::CRUD::Controller
and its descendents for example). In general, only set up things in new() (or
its cousins) for stuff you want to set up once per app: config, persistent
objects, etc. IME, there isn't much you want like that.
--
Peter Karman . http://peknet.com/ . [EMAIL PROTECTED]
___
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] Session Expiry
Bill Moseley wrote on 3/1/08 9:55 AM:
Or, is this an issue with using a session store that supports expires
times? Using a different store (like the database) would mitigate the
problem because I could use a much longer expires time for the cron job
that purges old session data than the $c-config-{session}{expires}
time. Still, that doesn't *solve* the issue.
but it does solve the issue, if the issue is having 2 different expires settings
to keep in sync.
seems like the Cache store should reset the expires time on the session data
each time, rather than having a separate 'expires' entry in the cache. AFAIK it
is the only session store class to do that.
I don't know if that is a fault with how the Cache store itself is implemented,
or with the implementation of the superclass.
--
Peter Karman . http://peknet.com/ . [EMAIL PROTECTED]
___
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] Instant CRUD with DBIC::Schema
On 02/20/2008 09:17 AM, Alex Povolotsky wrote: Hello! Scaffold seems to be a good thing, but it is using CDBI. Maybe something like it with DBIC exists? Also look at CatalystX::CRUD::Model::DBIC. Feedback appreciated. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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] using frontend proxy with non-/ PATH_INFO
Here's my setup:
* frontend Apache running mod_proxy, proxying at /myapp
* backend Cat dev server on :3000
I have this config in Apache:
# proxy for MyApp
Directory /path/to/MyApp/trunk/root/static
Order deny,allow
Allow from all
/Directory
Alias /static /path/to/MyApp/trunk/root/static
# neither of these result in PATH_INFO set correctly on backend
RewriteEngine on
RewriteRule ^/myapp$ http://localhost:3000/[P]
RewriteRule ^/myapp/(.*)$ http://localhost:3000/$1 [P,L]
# this second config per the Cat cookbook - makes no difference.
#ProxyRequests off
#Proxy *
#Order deny,allow
#Allow from all
#/Proxy
#ProxyPass/myapp http://localhost:3000/
ProxyPassReverse /myapphttp://localhost:3000/
If I am reading Apache docs and Cat code correctly, the issue is that the path
'myapp'
after the / isn't being passed on to the back end. Nor should it be. The
problem, though,
is that uri_for() needs to know about it in order to create working URLs.
Here's how I fixed the problem, using a local config option called
'prepend_path_info',
but I am hoping someone will show me how my setup is flawed and thus avoid
having a hacked
local Cat lib.
--- /usr/local/lib/perl5/site_perl/5.8.8/Catalyst/Engine/CGI.pm Thu Sep 20
04:29:41 2007
+++ lib/Catalyst/Engine/CGI.pm Mon Feb 11 09:27:07 2008
@@ -137,6 +137,10 @@
}
# set the request URI
+if ( $c-config-{prepend_path_info} ) {
+$base_path = $c-config-{prepend_path_info} . $base_path;
+}
+
my $path = $base_path . ( $ENV{PATH_INFO} || '' );
$path =~ s{^/+}{};
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
___
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] installing Catalyst::Plugin::Authentication::Store::LDAP
On 01/25/2008 06:51 PM, Jay K wrote: Catalyst::Authentication::Store::XYZ Catalyst::Authentication::Credential::XYZ What's the recommended approach for existing stores and credentials? Rename them and mark the old ones as deprecated? Create new stubs with the new names that just subclass the existing plugins? Well - Overall to update to the new naming scheme and then deprecate the old ones, yes. Catalyst::Plugin::Authentication::Store::LDAP 0.0601 is now marked at deprecated. Catalyst::Authentication::Store::LDAP 0.1000 is now the latest and greatest. Both just uploaded to CPAN etc. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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] How to use dbh in the model
On 01/29/2008 05:29 AM, Richard Jones wrote: package MyApp::Model::DBI; __PACKAGE__-config( dbi = DBIx::Simple-new(__PACKAGE__-dbh), ); but obviously not: Can't use string (MyApp::Model::DBI) as a HASH ref while strict refs in use at /usr/local/share/perl/5.8.7/Class/Accessor/Fast.pm line 38. MyApp::Model::DBI connect_info is automatically loaded from the global config file. I need to get the models dbh into DBIx::Simple-new(). What am I doing wrong? override new() instead? See the Catalyst::Component docs. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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] installing Catalyst::Plugin::Authentication::Store::LDAP
On 01/24/2008 05:09 PM, Jay K wrote: Hi all, I can shed some light here. As of Catalyst::Plugin::Authentication version 0.10003 - the default naming for stores and credentials is Catalyst::Authentication::Store::XYZ and Catalyst::Authentication::Credential::XYZ Jay, Thanks. That's a helpful clarification. I didn't realize the naming convention had changed myself. What's the recommended approach for existing stores and credentials? Rename them and mark the old ones as deprecated? Create new stubs with the new names that just subclass the existing plugins? pek -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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] OT: YUI v Ext JS
Ashley wrote on 1/25/08 6:44 PM: * Does Ext JS's grid have all the same goodies as YUI's DataTable? I haven't used Ext yet. But have you looked at: http://developer.yahoo.com/yui/examples/datatable/dt_cellediting.html ? * Is Ext JS completely stable across IE, FF, and Safari (Opera is sort of out of scope for this). * Do YUI's considerable other offerings (I'm looking for a site-wide library, not just grids) outweigh the positive aspects of Ext JS? * Would anyone, knowing *both*, pick YUI over Ext JS? I can't speak to Ext's stability (though I imagine it's fine considering its origins) but it seems like a false dilemma. Can't you use both together? Ext started out as an extension to YUI and still maintains compatability AFAIK. From the Ext FAQ: Your choice of base libraries/adapters will most likely be driven by whether or not you already use an external library for something that Ext does not provide. For example, YUI includes some components like a history manager that Ext does not provide. In that case, you may want to include the YUI adapter.[...] I have used the YUI history manager to good effect (see http://catalyst.perl.org/calendar/2007/7) so if Ext had some widget I really wanted, I would just use both together. -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ 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] installing Catalyst::Plugin::Authentication::Store::LDAP
On 01/24/2008 07:07 AM, rahed wrote: Hi, I tried to install Catalyst::Plugin::Authentication::Store::LDAP but it fails during t/01-pre_realms_api.t test. The message is: IO::Socket::INET: connect: timeout at t\01-pre_realms_api.t line 23. Both on Solaris10 and windows. Do I miss something? I noticed it fails also with CPAN Testers. you did not miss anything. There are tests for this timeout issue in svn already but I am waiting on some other issues before making a new release of ::Store::LDAP. The tests try and access openldap.org and timeout if they can't reach it. So you can safely ignore those test failures for now. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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] installing Catalyst::Plugin::Authentication::Store::LDAP
On 01/24/2008 03:45 PM, Andrew Peebles wrote: Peter Karman wrote: On 01/24/2008 02:49 PM, Andrew Peebles wrote: perl -MCPAN -e 'install Catalyst::Authentication::Store::LDAP' CPAN: Storable loaded ok Going to read /root/.cpan/Metadata Database was generated on Wed, 23 Jan 2008 23:30:57 GMT Warning: Cannot install Catalyst::Authentication::Store::LDAP, don't know what it is. you forgot the ::Plugin part My original email stated the error message coming from Catalyst, I just cut-n-pasted it: [warn] Store class Catalyst::Authentication::Store::LDAP not found, trying deprecated ::Plugin:: style naming. Then I tried to install the package listed in the warning ... ??? what does your config and 'use Catalyst qw( ... )' look like? The default Authentication plugin will try and load the Store and Credential plugins from the config, IIRC. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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] installing Catalyst::Plugin::Authentication::Store::LDAP
On 01/24/2008 03:22 PM, Jonathan Rockway wrote: Peter Karman [EMAIL PROTECTED] writes: On 01/24/2008 02:49 PM, Andrew Peebles wrote: perl -MCPAN -e 'install Catalyst::Authentication::Store::LDAP' CPAN: Storable loaded ok Going to read /root/.cpan/Metadata Database was generated on Wed, 23 Jan 2008 23:30:57 GMT Warning: Cannot install Catalyst::Authentication::Store::LDAP, don't know what it is. you forgot the ::Plugin part Isn't that deprecated? not when trying to install from CPAN, AFAIK. The name of the package is Catalyst::Plugin::Authentication::Store::LDAP. That's why CPAN claims not to know about Catalyst::Authentication::Store::LDAP. The deprecated ::Plugin part comes into play when the base C::P::Authentication plugin tries to load Store and Credential classes. But hey. I'm just a lowly maintainer. I could be way off on all this. :) -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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: REST - like uri design for CRUD
Peter Karman wrote on 1/20/08 7:53 PM: Aristotle Pagaltzis wrote on 1/20/08 7:36 PM: * Peter Karman [EMAIL PROTECTED] [2008-01-20 22:10]: there's no checking of HTTP method at all. Yikes!! img src=http://example.org/foo/id/42/delete; I actually consider that a feature, since it seems legit to me that a GET could act on an object. That's not REST, but RPC, as you indicated. In my apps, I do server-side auth checks to verify that users can't act on data they should not have access to. Then again, all my apps use POST to delete too. :) That said, I did enable a method-check in v0.23 with a configuration option to turn it off. That API is intentionally RESTish It’s not REST if it ignores the uniform interface – it’s RPCish. URI design is completely orthogonal to REST. you are right of course. /me adds CatalystX::CRUD::REST to todo list... /me crosses item off list http://search.cpan.org/~karman/CatalystX-CRUD-0.23/lib/CatalystX/CRUD/REST.pm Thanks, Aristotle, for pointing out my naive understanding of REST. This thread helped me write the API in the module above. Comments, suggestions always welcome. pek -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ 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] REST - like uri design for CRUD
Zbigniew Lukasiak wrote on 1/20/08 1:56 PM: I know this has been discussed already - but I can't find it in the archives. What I conjured is: /class/search /class/id//view /class/id//update /class/create Update and create use really the same logic and templates - so I just forward to a create_or_update action from them. What are your opinions? that's essentially the CatalystX::CRUD::Controller API: http://search.cpan.org/~karman/CatalystX-CRUD-0.22/lib/CatalystX/CRUD/Controller.pm That API is intentionally RESTish, though there's no checking of HTTP method at all. -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ 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: REST - like uri design for CRUD
Aristotle Pagaltzis wrote on 1/20/08 7:36 PM: * Peter Karman [EMAIL PROTECTED] [2008-01-20 22:10]: there's no checking of HTTP method at all. Yikes!! img src=http://example.org/foo/id/42/delete; That API is intentionally RESTish It’s not REST if it ignores the uniform interface – it’s RPCish. URI design is completely orthogonal to REST. you are right of course. /me adds CatalystX::CRUD::REST to todo list... -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ 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] View plugin for excell/OO
Angel Kolev wrote on 1/14/08 6:50 AM: Jens Gassmann wrote: Hi Angel, Is there any catalyst 'View' plugin for excel/open office sheets? http://search.cpan.org/~stevan/Catalyst-View-Excel-Template-Plus-0.01/lib/Catalyst/View/Excel/Template/Plus.pm jens I want to export SQL with DBIx::Class to excel sheet, but Catalyst-View-Excel-Template-Plus is not enough documented. Can anyone show me examples pls. Thanks. Look at CatalystX::CRUD::View::Excel. http://search.cpan.org/~karman/CatalystX-CRUD-View-Excel-0.03/ -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ 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] View plugin for excell/OO
On 01/14/2008 08:01 AM, Angel Kolev wrote: the file archive_report.tt is in MyApp/root/src/sheets xls that i receive is named myapp_archives_export.xls what are the contents of MyApp/root/src/sheets ? That's what will matter. Is that template actually getting called? -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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] ResultSet renderer?
On 01/04/2008 04:20 PM, Bruce J Keeler wrote: Greetings, Catalystos! I'm looking to find or create a canned solution for rendering DBIx::Class::ResultSets as paged, sortable HTML tables. All of the examples I've seen do this manually, foreaching through the resultset, spitting out trs and tds and so on. Seems like the sort of wheel that shouldn't need to be reinvented. Rose::DBx::Garden::Catalyst and CatalystX::CRUD do most of this. See the advent article http://catalyst.perl.org/calendar/2007/7 Of course, that's for RDBO and not DBIC. I have uploaded a 0.01 version of CatalystX::CRUD::Model::DBIC that might be useful to look at. I'm sure the templates generated by RDGC could be adapted to use it instead. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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: Database connections leaking
On 12/30/2007 02:54 PM, Aristotle Pagaltzis wrote: [F'up-to dbix-class] * Matt S Trout [EMAIL PROTECTED] [2007-12-24 19:30]: You might want to see about ripping out the C::M::DBI connection management and using a DBIx::Class::Storage::DBI object instead - the Model::DBI code originates from a copy of the DBIx::Class code but I'm unaware of whether bugfixes and refactorings have been propagated to it. Might it be worthwhile to rip the code out of both and put it in a separate DBIx::EnsureConnected or something like that, and then make sure that such objects can be used in place of plain DBI handles, so that anyone who needs this functionality can use that instead of maintaining the $N'th copy of the code? How is this different than DBI's own connect_cached() method? http://search.cpan.org/~timb/DBI-1.601/DBI.pm#connect_cached -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ 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: retrieving multiple values from forms
On 12/17/2007 05:27 PM, A. Pagaltzis wrote:
The sane thing is to have *TWO* methods, one that *always*
returns a scalar, and one that *always* returns a list. (Or
rather, an arrayref, because if it’s just a list, it is easy to
improperly treat it like a scalar, whereas if it’s an arrayref
it’s impossible to forget to unpack the array when you meant to
do that.)
I did something similar in my last $job, where I just had a begin() block in my
Root.pm
that reset params-{foo} to always return an arrayref.
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Plugin::Authentication::Store::LDAP problems
On 11/12/2007 06:17 AM, Matija Grabnar wrote: Is anybody using Catalyst::Plugin::Authentication::Store::LDAP ? I tried using it on my Debian stable install, and I've been unable to make it work: a) instalation test fail because the ldap server ldap.openldap.org used in the tests is not responding. that's not an ideal test. Should probably have some kind of timeout and skip() associated. I'll look at that. b) When I attempt to set up exactly (copy/paste except for bind parameters) according to documentation, Catalyst crashes because $c-authenticate is not defined. hm. sounds like you might not have the most current Catalyst::Plugin::Authentication module installed. What version are you running? c) When I replace $c-authenticate with c-login, I get a message saying default_store is not defined. Does anybody know what I'm doing wrong? Without seeing some code and your config, we can only guess. If you can create a small, reproducable test case, all the better. Incidentaly: I've got LDAP authentication working with Apache. Is there an authentication method that simply takes over the username and password that Apache got from the user? I believe Apache stores the user name from its auth in the REMOTE_USER env var. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: [OT] Search Solution
On 11/09/2007 02:00 AM, David Morel wrote: have a look there: http://www.gossamer-threads.com/lists/catalyst/users/ and search for lucene, plucene, xapian, swish-e, etc actually the threads I found seem shorter than I remember, but I just had a very quick look. I posted this link awhile back too: http://www.mail-archive.com/[EMAIL PROTECTED]/msg06061.html -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] ANNOUNCE: Rose::DBx::Garden::Catalyst
I've just uploaded Rose::DBx::Garden::Catalyst 0.01 to CPAN.
http://search.cpan.org/dist/Rose-DBx-Garden-Catalyst/
This is an alternative to the Catalyst::Example::InstantCRUD app. The main
differences are:
* uses Rose::DB::Object and Rose::HTML::Objects instead of DBIx::Class and
HTML::Widget
* uses CatalystX::CRUD::Model::RDBO and CatalystX::CRUD::Controller::RHTMLO
* relies heavily on the Yahoo UI library (http://developer.yahoo.com/yui/)
The idea behind this project is to make it easy to quickly bootstrap a web UI
to your existing
database. It has been tested with PostgreSQL 8.x, YUI 2.3.1 and
Rose::DBx::Garden 0.03.
From the SYNOPSIS:
# create a Catalyst app
catalyst.pl MyApp
# create a Rose::DBx::Garden::Catalyst script
cat mk_cat_garden.pl
use Rose::DBx::Garden::Catalyst;
use MyDB; # isa Rose::DB
my $garden = Rose::DBx::Garden::Catalyst-new(
catalyst_prefix = 'MyApp',
garden_prefix = 'MyRDBO',
db = MyDB-new,
tt = 1, # make Template Toolkit files
);
$garden-plant('MyApp');
# run your script
perl mk_cat_garden.pl
# start your Catalyst dev server
cd MyApp
perl script/myapp_server.pl
# enjoy the fruits at http://localhost:3000/rdgc
Feedback, comments, patches, tests, docs, etc., all welcome.
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: [OT] Search Solution
On 11/09/2007 03:47 PM, Octavian Rasnita wrote: Do you have a recommendation for a good perl module that can be used easyly for creating a spider that should index a web site? If you don't need UTF-8, check out Swish-e. It has a spider and parser. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] A question on persistence with sessions or similar
Joe Landman wrote on 11/6/07 9:40 PM: Hi Folks: Here is what I want to do. I want to preserve values of stuff across the life of a session, without having to jump through hoops to do it. I want it to survive redirects in the app. It would be nice if it were just like stash. Really, it is very simple. And I thought I had it. $c-flash $c-session That does what you describe. -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New auth stuff and LDAP store...
Thanks to Adam, mst and jshirley for bringing me into the Cat fold. Catalyst-Plugin-Authentication-Store-LDAP-0.0600 was just pushed to CPAN. This brings the LDAP auth plugin up to speed with the current C::P::Authentication realms API. On 09/24/2007 12:22 PM, Peter Karman wrote: On 09/24/2007 11:55 AM, Peter Karman wrote: As I have the time (and who knows how long that will last...), I'd still like to bring the LDAP plugins up to speed. I'll hack on it a bit today and see where I get. These patches seem to bring the LDAP plugins up the latest Authentication API, to support realms, etc. ___ List: [EMAIL PROTECTED] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/ -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
