[Catalyst] RFC: new helper api

[Devin Austin]

Howdy all,

I've put together an RFC for the new Catalyst::Helper API.
The body text is located below, but it is also available here in a pretty
formatted version:
http://www.codedright.net/2009/06/rfc-catalysthelper-api.html

For the improvement of the Catalyst::Helper API and Catalyst development in
general, comments are of the utmost importance.  The more feedback
I can get, the better and quicker the API will be completed.

Thank you kindly!

-dhoss

*Intro:
*This document is to get opinions on a new, up to date set up  and
refactoring of the Catalyst::Helper API.

*What We Have*
Currently, all template/image data is hideously store inline with code in
the __DATA__ section of Catalyst::Helper.pm.  The API is designed to handle
data this way, which is wrong wrong wrong for a number of reasons:

   1.  You have to actually delve into Catalyst internals to edit any of
   these files
   2.  If you create a helper, your data must be inline as well.
   3.  Its current layout does not reflect the directory hierarchy of a
   Catalyst application, thus making it pretty dang hard to expand
   upon/upgrade.

There are no methods to allow you to edit previously created files, unless
you want to create your own helper and feverishly create your own file
modification method(s).
I can attest to the stress this causes, as I've been doing a good deal of
yak shaving cleaning this code up and creating the proper tests for it.
It's not a very fun ordeal at this point.

*What we want*
>From the feedback I've gathered thus far:

We *do* want previously created helper files to be modifiable via
Catalyst::Helpers.  For instance, updating Makefile.PL, updating myapp.conf
to reflect changes, updating DBIC schema files to reflect database changes
(with minimal pain). Also, add an infrastructure for modifying existing
catalyst code, e.g. moving Catalyst::Helper::AuthDBIC from an  experimental
proof of concept to something that people might actually want to use for
their own stuff.

We *do* want to be able to remove a good deal of the boilerplate code that
still seems to need to be created manually, for each app, even though it's
the exact same code for each instance.

We *do* want to set up the helper files in the hierarchy that a Catalyst
application is created in, thus cutting quickly to the chase in the way of
creating an app.  It's a simple name and Template::Toolkit variable
translation, then writing the file to the filesystem process then.  This
gets our binary data out of the API code, the template data out of the API
code, and generally makes every one more happy.

With this said, here are some more specific ideas that have been passed my
way that I think would really help further advance our precious Helper API:


   1.  Beat up MooseX::Getopt to deal with pass-through options, so you can
   deal with passing data structures as arguments easier. Not to mention
   actually start USING it in the Helper API.
   2. Add a feature to write out DBIC schema files for deployment.  Yes,
   make_schema_at does this, but you have to write your own little script to
   enjoy this morsel of functionality.  It would be nice to have it packaged up
   and ready to go for you.
   3. Have something like TTSite, but less sucky.  Perhaps there could be a
   default layout that can be created, or you can create your own sort of skin
   and have that the default generation.  Or, better yet, packaged skins that
   users can submit to $somewhere and have the author choose a "theme" for
   their app. For instance, using $javascript framework and $css framework to
   do so, like in chapt 11 of the upcoming book (Example usage:
   http://www.uow.edu.au/~kd21/ )

These are the current ideas I have, and that others have submitted.  Sure
this RFC is a bit bare, but we don't have a whole ton to work with at the
moment with Catalyst::Helper, so we need more feedback to beef things up.


-- 
Devin Austin
http://www.codedright.net
http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!
___
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] ACL Error: deny_access_unless

[Gordon Stewart]

> http://omni.state51.co.uk/~t0m/MyApp.tgz - there is your tarball  
> back, with git history of everything I did for your perusal.

I cannot seem to download the tarball from your site.  Did you give me an
internal website?

Regards 

Gordon 




___
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] Applying external web server authentication: is there a better way?

[Stuart Watt]

Many thanks, Tomas, just what I needed. Right now I'm still on 5.7 due 
to an immediate release, but next week I'll go to 5.8, and then I'll be 
happy to review and test a better solution. Credential::Remote looks 
like what I didn't find. When I started working with this authentication 
issue, I wouldn't even have understood Credential::Remote type code, but 
by Monday I'll be better placed and have time enough to give it a 
thorough test.


All the best
Stuart


Tomas Doran wrote:

Stuart Watt wrote:
I'm developing an app which uses IIS and FastCGI as its back end. 
Also, we are expected by the client to use Windows integrated 
authentication in the server -- this is an intranet app, so no login 
screen should be expected.


trying to read the one already performed, so I put together a 
Catalyst::Authentication::Credential::Environment module, that simply 


Doh, you appear to have duplicated a chunk of effort:

http://dev.catalyst.perl.org/repos/Catalyst/branches/Catalyst-Plugin-Authentication/credential_remote/lib/Catalyst/Authentication/Credential/Remote.pm 



Is there another simple but better way to achieve this? Ideally one 
which avoids the deprecated $c->request->user. I'm only starting to 
use Catalyst for authentication stuff.


Not at the moment / in a released state.

The next Catalyst release will add $c->req->remote_user for this. 
There is currently a failing test (for a bug which has been in 
Catalyst forever) in trunk, and I'm hoping to get this fixed before we 
release 5.80005.


I'm also going to be reviewing / merging this branch of 
Catalyst::Plugin::Authentication soonish (which I'm seriously late on 
already)!


So to answer your actual question, yes, what you're doing is the right 
thing to do, and will be present in 'officially released' software 
within the next couple of weeks max hopefully.


If you fancy reviewing the code I linked about, and trying it out to 
see if it works for you, and commenting on anything you think needs 
work (including documentation!), then that would be a great help :)


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/

--
This message was scanned by ESVA and is believed to be clean.
Click here to report this message as spam. 
http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=8D20F27F14.90E6C




--
Stuart Watt
ARM Product Developer
Information Balance
___
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] Applying external web server authentication: is there a better way?

[Tomas Doran]

Stuart Watt wrote:
I'm developing an app which uses IIS and FastCGI as its back end. Also, 
we are expected by the client to use Windows integrated authentication 
in the server -- this is an intranet app, so no login screen should be 
expected.


trying to read the one already performed, so I put together a 
Catalyst::Authentication::Credential::Environment module, that simply 


Doh, you appear to have duplicated a chunk of effort:

http://dev.catalyst.perl.org/repos/Catalyst/branches/Catalyst-Plugin-Authentication/credential_remote/lib/Catalyst/Authentication/Credential/Remote.pm

Is there another simple but better way to achieve this? Ideally one 
which avoids the deprecated $c->request->user. I'm only starting to use 
Catalyst for authentication stuff.


Not at the moment / in a released state.

The next Catalyst release will add $c->req->remote_user for this. There 
is currently a failing test (for a bug which has been in Catalyst 
forever) in trunk, and I'm hoping to get this fixed before we release 
5.80005.


I'm also going to be reviewing / merging this branch of 
Catalyst::Plugin::Authentication soonish (which I'm seriously late on 
already)!


So to answer your actual question, yes, what you're doing is the right 
thing to do, and will be present in 'officially released' software 
within the next couple of weeks max hopefully.


If you fancy reviewing the code I linked about, and trying it out to see 
if it works for you, and commenting on anything you think needs work 
(including documentation!), then that would be a great help :)


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/

[Catalyst] Applying external web server authentication: is there a better way?

[Stuart Watt]

I'm developing an app which uses IIS and FastCGI as its back end. Also, 
we are expected by the client to use Windows integrated authentication 
in the server -- this is an intranet app, so no login screen should be 
expected.


Picking up the user id is fairly easy - it's set as the REMOTE_USER CGI 
header by IIS authentication, and the engine puts it into the deprecated 
$c->request->user. I was using this as the identity (bad, I know) and 
got burned by the fact that we couldn't properly test multiple users 
with Test::WWW::Mechanize::Catalyst.


I wanted to switch to Catalyst::Plugin::Authentication. This seemed a 
little unusual when we aren't really doing any authentication, but 
trying to read the one already performed, so I put together a 
Catalyst::Authentication::Credential::Environment module, that simply 
reads (the still deprecated) $c->request->user. I didn't really want to 
do all the authentication with Catalyst::Plugin::Authentication, even 
though is seems possible. And testing was now easy, we got per-user 
sessions, and everything. Anyway, what I wrote as the main method was:


sub authenticate {
   my ( $self, $c, $realm, $auth_info ) = @_;
   $c->log->debug("Using environment authentication");
   my $username = $c->request->user();
   if ( defined( $username ) && ( $username ne '' )) {
   my $user_obj = $realm->find_user( { username => $username }, $c );
   if ( ref( $user_obj ) ) {
   $user_obj->id( $username );
   return $user_obj;
   }
   }
   return;
}

Is there another simple but better way to achieve this? Ideally one 
which avoids the deprecated $c->request->user. I'm only starting to use 
Catalyst for authentication stuff.


All the best
Stuart
--
Stuart Watt
ARM Product Developer
Information Balance
___
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/