Re: [Catalyst] Mason view hackers (and other views), PING

2007-05-13 Thread Marc Espie
On Sat, May 12, 2007 at 02:09:31PM -0500, Dave Rolsky wrote:
 On Sat, 12 May 2007, Matt S Trout wrote:
 
 Something I'd be delighted if you'd have a think about: how to make Mason
 use intelligent search paths for Chained actions - the autohandler/dhandler
 etc. system is beautiful but it'll need a smart mapping from the cat 
 actions
 onto the mason paths to really make it go for Cat users.
 
 I'm not sure I follow.
 
 In my opinion, the dhandler portion of Mason is entirely superfluous when 
 using Catalyst. Catalyst already provides many dispatch options to do 
 similar things, including default() methods in your controller, which act 
 more or less exactly like dhandlers. I always kind of assumed default() 
 and auto() had been inspired by Mason, because they work so much like 
 Mason does.
 
 The autohandler stuff is still really useful, but I just use it for 
 wrapping header/footers or path-specific menus around the called 
 component.
 
 I guess my take on it is that you do the dispatching part in your 
 controller, and as part of that, you should also decide what component to 
 call for the view. The default for this in the Mason view seems to be the 
 same as that in the TT2 view, which is to use $c-req-match. That seems 
 reasonable to me.

This ties in directly to the question I asked a week ago: I have a Mason
app, I'd like to migrate it to Catalyst, but slowly. This is some kind of
`inside-out' thinking... I haven't really had time to make progress on
this one (busy refactoring a completely different perl 
projet -- OpenBSD's pkg tools), but in my case, I have some Mason stuff,
already complete with autohandlers, and I'd like to be able to have mason
`components' be catalyst invocations (including as subpart of pages) and
slowly migrate to a full catalyst.

I can rewrite the app as a catalyst app, and have a `flag day' where I
redeploy everything and forget the old app... but this is going to take
time. I would rather proceed bit by bit, and to this end, being able to
use more Mason-style organization from the catalyst side would be some
useful migration tool

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] catalyst on OpenBSD

2007-04-27 Thread Marc Espie
I'm happy to say that we now have catalyst in a stable state on OpenBSD.
We have most modules in the ports tree, a large subset of plugins working.
And DBIx::Class::C3_XS should join us next week. So a newcomer can now
just do pkg_add catalyst_tutorial and start playing.

Can someone please adjust the home page at http://www.catalystframework.org/
to mention OpenBSD in supported OSes ?

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] creating a model

2006-12-22 Thread Marc Espie
On Fri, Dec 22, 2006 at 01:47:08PM -0800, Octavian Rasnita wrote:
 
 Just learn and use Linux :) (Oops did I say that out loud?)
 
 I use Linux for running the created application, but not for developing it.
 I need to develop it under Windows, because Linux is a very poor operating 
 system, good for running servers, but not very good as a desktop.
 
 I am blind, and the accessibility of Linux GUIS are very poor, the screen 
 readers that work under Linux cannot compare with those that run under 
 Windows.
 
 I think the fact that the perl programs need to be ported to other 
 operating system sometimes with a pretty big effort, make it a less and 
 less popular language. Maybe perl6 will solve this, but I hope to live 
 until then. :-)
 
 Happy Holidays everyone!
 
 Thank you and I wish you the same.
 
 Happy holidays!
 
 Octavian

As far as I can tell, the main issue under Windows would be concurrency.

There is a POE engine, which can work as a single threaded solution.

Other than that, what's wrong with using Windows to talk to Linux ?
If your screen reading applications are so awesome, then use them through
putty to be able to access a linux shell !

You can also fairly well develop under windows if you choose. Samba works,
you know. You can access a Linux filesystem from Windows without any trouble
at all (and there are VNC clients and servers under linux as well)

I'm not blind, but I work all the time on Unix machines from a windows
station, at work, without any trouble at all.

I believe you will have to invest some time into figuring things out,
but I don't think the barrier is all that great, with a little ingenuity.

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Supporting multiple password types with C::P::Auth::Store::DBIC

2006-12-13 Thread Marc Espie
On Wed, Dec 13, 2006 at 12:16:30AM +0100, Daniel McBrearty wrote:
 Am migrating from an old system which used Basic Auth, to this plugin.
 As mentioned in a previous post, using
 
 password_type = crypted
 
 means that the old passwords still work. Nice ...
 
 But reading the docs for crypt I just noticed that it can screw up
 on unicode wide chars, so it looks like a good idea to migrate away
 from crypt to hashed. The best way to do this would be to make the
 plugin support both ... something like :

I really don't think it's a good idea to allow non-ascii characters
into passwords.

People will screw themselves over: choose a password with an é, change
machines, and realize you don't know how to enter an é from the new
setup.

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: Last Chance / Last Day: Webdevelopmentplatformcontestand Perl / Catalyst

2006-12-02 Thread Marc Espie
I would tend to agree.

Since I'm just currently learning Catalyst, I find the DBIx documentation
to be a bit on the poor side.

The examples are very simple, and not quite varied enough. Having a
complete description/usage of many-to-many schemas would help.


I've done some mistakes while setting up the schema, and I often end up
with very bad error messages, hard to figure out for a beginner, 
and DBI itself crashing... First time I saw perl dump core in a long while.


A reference documentation of all methods is also missing, in my opinion.

It's not always easy to figure out where to look, between Core, Relationship,
ResultSet, Schema, and whatnot...



Yes, I'm starting in the deep water, but the concrete example I have,
I'm trying to rebuild a web application which uses some Access databases.

The old pure HTML::Mason I have uses hand-crafted code to grab the
access stuff through DBD::Proxy, and copy it over to an sqlite database.

Well, I haven't been able to figure out how to explain to 
DBIx::Class::Schema::Loader to get the Access schema through the proxy,
so it's a stumbling block...

So here it is, after reading the documentation and trying out the samples,
catalyst looks interesting, but I'll have to spend still quite a bit of
time before I get anything useful out of it...

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Catalyst ported to OpenBSD

2006-11-06 Thread Marc Espie
This is just to notify you guys that I have imported a very large
subset of Catalyst into the OpenBSD ports tree, based in part on
Sean Comeau and Simon Dassow.

There's now more than enough for Task-Catalyst (imported as devel/catalyst)
and there's also a second helper port: devel/catalyst-tutorial, which bundles
enough stuff to run the tutorial.

We also activated perl support in fastcgi, giving us about 4 simple venues
for running catalyst applications between Apache, Apache-modperl, fastcgi,
and the catalyst web server.

I'm still making my way through the catalyst modules, but I think you
can safely write on the main page that catalyst is supported under OpenBSD.


___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/