[Catalyst] Template render in parts
Hi all, I am trying to display the LDAP search entries using 'callback' option in the search method. I have been successful in handling the callback option and got 'one by one result'. But I found a problem in displaying the search entries in a Template using the catalyst framework. I want to display LDAP search entries in TT. But I want to show the search entries directly. When I receive the first search result, I want to show it (that result) in TT and the back-end process should automatically search the second entry and so on. Similarly, when I get the second search result, I want to show that result in TT and similarly the back-end process should automatically search the next entry and so on. It means when I get the search results directly, it should be ideally displayed in the TT without waiting for all the search results. For this mechanism, I used the Net::LDAP search method. Search method provides callback option to return one by one search results. For the template, I used Template::Alloy module. I used both modules (i.e. Net::LDAP and Template::Alloy) in my CGI application. Both work perfectly. Now I want to use this mechanism in Catalyst applications as well. I searched and designed the following module Catalyst::Helper::View::TT::Alloy. I believe it should work perfectly in place of the Template::Alloy module. Could you please give your comments/insights on this as I'm not completely sure about it. It would also be of immense help if you could refer me some other module which would/could work in place of the Template::Alloy module perfectly in the Catalyst framework for different applications. I would be grateful if any one help me how to access this module with Catalyst framework. Looking forward to a prompt response. -- Venish Khant www.deeproot.co.in ___ 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] Fetching URL Content
On Wed, Sep 2, 2009 at 6:25 PM, Trevor Phillips wrote: > I have a requirement to fetch URL content - this is currently mostly > to do with the View phase, to include chunks of HTML for core branding > in the templating. ie; Top header, footer, global nav, that sort of > thing. > > Ideally, I'd like to do it directly from the Template Toolkit > templates, but TT either can't do this, or it's really hard to Google > for. ^_^ > http://search.cpan.org/~evdb/Template-Provider-HTTP-0.02/lib/Template/Provider/HTTP.pm But I can't imagine *ever* using that. Use a cron job to update local templates if you must. -- Bill Moseley mose...@hank.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] Fetching URL Content
On Wed, Sep 2, 2009 at 6:25 PM, Trevor Phillips
wrote:
> I have a requirement to fetch URL content - this is currently mostly
> to do with the View phase, to include chunks of HTML for core branding
> in the templating. ie; Top header, footer, global nav, that sort of
> thing.
>
> Ideally, I'd like to do it directly from the Template Toolkit
> templates, but TT either can't do this, or it's really hard to Google
> for. ^_^
> It would be nice to cache locally the content, even if for a short
> period. Or ideally, to cache permanently unless there's a
> "Cache-Control: no-cache" request header to force an update.
>
> ie; something like:
> [% INCLUDE "http://central.server.com/branding/header.html"; cache="5
> min" %]
>
> Can TT do anything like this? It doesn't need to be parsed by TT
> (although having the option for TT to parse it would be useful).
>
> The next idea would be to have a Controller fetch the content for the
> remote URLs, and either shove them in the stash, or cache them to
> disk, so that TT can then reference them. Would this just be a case of
> doing a usual LWP UserAgent Request, or does Catalyst have built-in
> handling or plugins to aid in this?
>
> Hmmm. It could be implemented as a Model as well, I guess...
>
> Any ideas/tips/best practices?
>
> Thanks.
>
>
Putting it into the template definitely falls under the bad idea category.
Having something like this as a plugin is also a very bad idea.
While you could, very easily, create this behavior by extending View::TT it
is better to put this in a very simple model class. The caching would be
very easy as well.
You could then just wrap one of the LWP::UserAgent and be done. I'm
currently doing something similar with Web::Scraper, and it works quite
well.
This is a non-tested/typed up example of what I have (I don't remember
exactly which app has it :/). This is just an example of a thin model that
can be used to accomplish mostly what you want, not really for you to just
copy and paste in. You can add in caching as necessary.
package MyApp::Model::Scraper;
use Moose;
use Web::Scraper;
BEGIN { extends "Catalyst::Model"; }
has 'scraper' => {
is => 'rw',
isa => 'Web::Scraper',
default => sub {
scraper { ... }
}
};
sub fetch {
my ( $self, $url ) = @_;
return $self->scraper->scrape( URI->new( $url ) );
}
no Moose;
__PACKAGE__->meta->make_immutable;
___
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] Fetching URL Content
I have a requirement to fetch URL content - this is currently mostly to do with the View phase, to include chunks of HTML for core branding in the templating. ie; Top header, footer, global nav, that sort of thing. Ideally, I'd like to do it directly from the Template Toolkit templates, but TT either can't do this, or it's really hard to Google for. ^_^ It would be nice to cache locally the content, even if for a short period. Or ideally, to cache permanently unless there's a "Cache-Control: no-cache" request header to force an update. ie; something like: [% INCLUDE "http://central.server.com/branding/header.html"; cache="5 min" %] Can TT do anything like this? It doesn't need to be parsed by TT (although having the option for TT to parse it would be useful). The next idea would be to have a Controller fetch the content for the remote URLs, and either shove them in the stash, or cache them to disk, so that TT can then reference them. Would this just be a case of doing a usual LWP UserAgent Request, or does Catalyst have built-in handling or plugins to aid in this? Hmmm. It could be implemented as a Model as well, I guess... Any ideas/tips/best practices? Thanks. -- Trevor Phillips - http://dortamur.livejournal.com/ "On nights such as this, evil deeds are done. And good deeds, of course. But mostly evil, on the whole." -- (Terry Pratchett, Wyrd Sisters) ___ 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] Testing OpenID Logins + more
On Sep 2, 2009, at 10:48 AM, Tomas Doran wrote:
On 1 Sep 2009, at 04:43, fREW Schmidt wrote:
I'd really like to start testing my controllers, and I wished I'd
started sooner, but oh well. The biggest barrier at this point is
the login system. It uses OpenID for auth, which is where the
hard stuff comes from.
Why bother with the complexity when testing if it isn't the OpenID
stuff your testing specifically.
I'd arrange for the relevant tests to supply a custom config file
(I do this by mangling MYAPP_CONFIG env variable in the tests,
although I'm sure there are more elegant solutions)..
This is what I've adopted. I have "permanent" config in myapp.yml and
then whatever site customization in myapp_local.yml and then a
configuration file specifically for testing (substituting DB config
normally) myapp_test.yml
And then a test like:
BEGIN {
$ENV{MYAPP_CONFIG_LOCAL_SUFFIX} = "test";
}
use strict;
use warnings;
use Test::More "no_plan";
use Test::WWW::Mechanize::Catalyst;
# etc...
That will pick up the right config and override your core stuff where
needed/desired. I don't know if this is a widespread practice but
I've been doing it for a long time now and really like it.
-Ashley
___
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] Testing OpenID Logins + more
On Aug 31, 2009, at 8:43 PM, fREW Schmidt wrote: I'd really like to start testing my controllers, and I wished I'd started sooner, but oh well. The biggest barrier at this point is the login system. It uses OpenID for auth, which is where the hard stuff comes from. I *have* looked at the tests for the OpenID module for catalyst auth, and although I'll surely end up using something like that, it's pretty intimidating. Does anyone have any existing basic tests for OpenID stuff, to test their server, as opposed to the OpenID module, that they might be willing to share? I'd really appreciate it. In the meantime I'll be trying to look more at Ashley's stuff. Hey there. The test applications (there are two in the t/ dir) are also in slight disarray. Which is to say, they used to be one test application but due to forking issues (it had to talk to itself to provide:consume) I split them where splitting means make exact copies of the first and renamed each: Provider and Consumer respectively. Each has been tweaked slightly, and the config of one probably contains erroneous artifacts from bug fixing, compounding the difficulty of comprehending them. I'm somewhat proud to say the current dev version is passing its tests (so far on all test reports). If you wait awhile I may clean them up, generalize, and Pod them. Tuits are always the issue. I'm going to do one more dev release turning on all the "live" tests for everyone (it's an ENV triggered test now) and if that passes in the wild I'll do a 0.15 which I hope will have some cleanup in the test code for the curious but... I have considered doing the Provider app as a standalone release so it could be used in testing. If anyone thinks that's worthwhile, send a name you'd think sensible (CatalystX::Test::OpenID::Provider?) and feature wishlist. Again, it's a tuit issue and I'd way behind on plenty. I think t0m had the right idea though. Don't test it, or don't unit test it. Running live or in a staging server, I'd use a known OpenID account to do a Selenium/WWW::Mech style test. -Ashley ___ 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] Class data in a Moose::Role plugin
On Wed, Sep 2, 2009 at 7:30 AM, Tomas Doran wrote: > Bill Moseley wrote: > >> I also tried with Catalyst::ClassData. Must be missing something. >> > > Nope, you're not missing anything - class data in roles doesn't play > nicely. > > This would all be a lot easier (or not needed) if we had an app class > instance, rather than it being a class.. > True. In my case what I did was use package lexicals. Wasn't sure about that because not sure how Moose does its magic. Thanks, -- Bill Moseley mose...@hank.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] Testing OpenID Logins + more
On Wed, Sep 2, 2009 at 12:48 PM, Tomas Doran wrote: > > On 1 Sep 2009, at 04:43, fREW Schmidt wrote: > >> I'd really like to start testing my controllers, and I wished I'd started >> sooner, but oh well. The biggest barrier at this point is the login system. >> It uses OpenID for auth, which is where the hard stuff comes from. >> > > > Why bother with the complexity when testing if it isn't the OpenID stuff > your testing specifically. > > I'd arrange for the relevant tests to supply a custom config file (I do > this by mangling MYAPP_CONFIG env variable in the tests, although I'm sure > there are more elegant solutions).. > Awesome! This is one of the main things I wanted. I'll let you know how it works out. > You can then change the authentication config to use different auth modules > (for example authenticating a hard-coded list of test users with known > roles) for the purposes of testing your controllers. > > You still want to do _some_ testing of login / logout etc, but there is no > point in jumping through hoops for _all_ of your controller testing. > Yeah, especially since it would mean my controller tests would have to load of TWO catatlyst servers every time, which is just silly. -- fREW Schmidt http://blog.afoolishmanifesto.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] Feedback requested on HTML::FormHandler's new widget system
Matt Whipple wrote: From my perspective the output/rendering of the form data normally represents a static view of the data, a single state which will generally not require any return communication with the system which renders it. I therefore see a more independent treatment of widgets the best option to allow those widgets to fit into the most places, and be made the most accessible for future growth. Rather than treating the widgets as roles to be pulled into the form system, they could be external objects with a common interface which are pushed into and piped from. This aids in separation of concerns and could lead to afar more flexible, robust widget framework which is more conducive to collaboration and extension within and without the larger system. Interesting. The difficulty I see here is that the definition of various aspects of the presentation is currently done in the form/fields, and if I understand you correctly you are suggesting that that sort of definition should be done in some entirely different object. I am not really clear on how what you are proposing is different from a template system, which is basically an external system into which you push your variables, with a particular template defining the "interface". You might be interested in the new 'result' object, which separates static from dynamic but in rather the opposite direction. Only the dynamic data is stored in the result objects. If you want to render from a result object it uses the static information in the form/fields to create the HTML. You can have multiple result objects which all refer to the same static form. This architecture is particularly suited to persistent forms. Gerda ___ 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 handle development vs production, required vs recommended module dependencies
Am 02.09.2009 um 19:44 schrieb Tomas Doran: On 31 Aug 2009, at 02:44, Daniel Austin wrote: Interested to hear how others might be handling this. It seems to work for us but I'm still learning Module::Install. I tend to use the excellent Module::Install::AuthorRequires and Module::Install::AuthorTests - as things which are not required will not be installed / run on the author side, so in my opinion you get less hassle by just requiring everything for authors who are checking the code out of revision control. Or create a second distribution MyApp::Devel which contains the devel modules only. 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] Where to add access control? Override execute() or dispatch()?
On 30 Aug 2009, at 21:17, Bill Moseley wrote: I'm trying to decide if this is the best approach, or if would be better to test the ACL before dispatching. The issue is if the request is for /foo/bar, and an ACL rule blocks that, should Foo::(begin|end|auto) still run? Or should it act as if the /foo/bar action doesn't exist and not run any begin, auto, or end in the Foo controller? I think that either would be a valid design decision. I don't think that entirely shortcutting dispatch gives you as much flexibility, and I tend to do the 'hard' part of the hit in the terminus action anyway, so running the begin action isn't a big deal for me. I personally prefer it to be done on a per-action basis, as I _want_ begin / end / auto to run even in the case where the action itself is denied (as this gives you the chance to 'whitelist' the action given special conditions for one example, or to use the end action to serialize an 'access denied' REST response back in a site with an API for another example). 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] How to handle development vs production, required vs recommended module dependencies
On 31 Aug 2009, at 02:44, Daniel Austin wrote: Interested to hear how others might be handling this. It seems to work for us but I'm still learning Module::Install. I tend to use the excellent Module::Install::AuthorRequires and Module::Install::AuthorTests - as things which are not required will not be installed / run on the author side, so in my opinion you get less hassle by just requiring everything for authors who are checking the code out of revision control. 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] Testing OpenID Logins + more
On 1 Sep 2009, at 04:43, fREW Schmidt wrote: I'd really like to start testing my controllers, and I wished I'd started sooner, but oh well. The biggest barrier at this point is the login system. It uses OpenID for auth, which is where the hard stuff comes from. Why bother with the complexity when testing if it isn't the OpenID stuff your testing specifically. I'd arrange for the relevant tests to supply a custom config file (I do this by mangling MYAPP_CONFIG env variable in the tests, although I'm sure there are more elegant solutions).. You can then change the authentication config to use different auth modules (for example authenticating a hard-coded list of test users with known roles) for the purposes of testing your controllers. You still want to do _some_ testing of login / logout etc, but there is no point in jumping through hoops for _all_ of your controller testing. Hope this helps. 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] Feedback requested on HTML::FormHandler's new widget system
Hi, I'm a recent adopter of HFH, and was drawn to it partly in hopes of having a decently clean solution for form rendering (I've begun a system but don't think it will be usable anytime in the near future) so I'll contribute my 2 cents. From my perspective the output/rendering of the form data normally represents a static view of the data, a single state which will generally not require any return communication with the system which renders it. I therefore see a more independent treatment of widgets the best option to allow those widgets to fit into the most places, and be made the most accessible for future growth. Rather than treating the widgets as roles to be pulled into the form system, they could be external objects with a common interface which are pushed into and piped from. This aids in separation of concerns and could lead to afar more flexible, robust widget framework which is more conducive to collaboration and extension within and without the larger system. ___ 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] Splitting up a large application: Shared config and templates for multiple applications
> >> http://github.com/rodrigolive/catalystx_featurizer >> > > Nice :) > > I'll look into this more closely when I have chance (this week hopefully) > and give you some deeper feedback. > Cool, I appreciate your feedback on this. BTW, I've just now reblessed the module *CatalystX::Features* since the "rizer" suffix is sortta of a in-joke here at $work... Besides it's 2 bytes shorter ;) So finally I put it here, with a little PODing in Features.pm: http://github.com/rodrigolive/catalystx_features Hopefully I'll have some time this weekend to cpanize this thing and do a dev release. > > One of the things I've been thinking about significantly is how 'features' > can ship templates in whatever the feature author's preferred template > language is, but allow customisation of those templates (or, more > importantly, of the fragments those templates are made from) in a different > template language - so using feature X doesn't force the application author > to have to use TT or Mason or whatever. > > I'm interested in your approach to this - given you've obviously thought of > this (on some level at least), as you're already supporting TT and Mason. > I think I grasp the concept, but I haven't come across the need... just yet. I guess it would take some abstracting while going from the app to the feature and back. Or maybe it would need to trap some of the internal view engines to capture that precompiled template, just before it get's evaled and/or run into HTML or whatever the template becomes. Well, somewhere in between the template engine and the Catalyst controller there must be a spot where we could just talk plain perl and let things communicate regardless of the templating engine in use. Indeed you hit a sensitive note here. The "merging" of two parts (myapp + myfeature) is quite complex. To the point merging could become a separate module entirely. I even thought of separating parts of the module into a different module called i.e. CatalystX::Merge, but I pulled back, at least for now, to keep things concise. cheers, rod ___ 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] How to handle development vs production, required vs recommended module dependencies
Hello I'm curious how other Catalyst developers are managing their CPAN module dependencies. I see our current application as having four types of module dependencies: * Modules that are required for the application to run *at all*. These are specified using "requires" statements in Makefile.PL (and also, the "all from" statement which points at the main Catalyst application class). * Modules that are not required, but if present, add additional functionality. These are specified using "recommends" statements in the Makefile.PL. * Modules that are only needed by developers. -- Some of these are just needed for testing (eg HTML validator) so I use "test_requires". That seems to work fine but I don't get prompted "Do you want to permanently install these" which is what I was expecting for some reason. -- Others, like Catalyst::Devel are needed for any kind of development and not just to run tests. But they're not needed for production and should not be a dependency. I specify these using "requires" but I have it inside an "if block" which checks the command line to see if Makefile.PL is being run for a developer or not. * Finally, there are modules which are recommended for developers but not required (for example, Devel::Cover for code coverage). I specify these using "recommends", but again it's inside the same if block described above. Interested to hear how others might be handling this. It seems to work for us but I'm still learning Module::Install. Thanks Dan ___ 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] And lo, doth the spice flow once more
The mailman queue runner apparently decided to implode over the bank holiday weekend. I've delivered a short sharp blow to the rump with the flat of a chainsaw and it appears to be going again. Apologies for the mail delivery delays. -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.ukhttp://shadowcat.co.uk/blog/matt-s-trout/ ___ 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] TEST - Please ignore.
Tomas Doran wrote: Test email, please ignore. And the list is fixed. mailman-- Thanks mst! 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] Where to add access control? Override execute() or dispatch()?
I'm in the process of adding custom access control for actions. I've been looking over C::P::Authorization::ACL. It overrides execute() which is run for every method called by the dispatcher, which includes begin, auto, the action itself, and end. Depending on how the ACLs are specified, the plugin wll block access to the actual action, but begin, auto, and end will still run. I'm trying to decide if this is the best approach, or if would be better to test the ACL before dispatching. The issue is if the request is for /foo/bar, and an ACL rule blocks that, should Foo::(begin|end|auto) still run? Or should it act as if the /foo/bar action doesn't exist and not run any begin, auto, or end in the Foo controller? -- Bill Moseley mose...@hank.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] Class data in a Moose::Role plugin
Bill Moseley wrote: I also tried with Catalyst::ClassData. Must be missing something. Nope, you're not missing anything - class data in roles doesn't play nicely. This would all be a lot easier (or not needed) if we had an app class instance, rather than it being a class.. 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] Testing OpenID Logins + more
Hey guys, I'd really like to start testing my controllers, and I wished I'd started sooner, but oh well. The biggest barrier at this point is the login system. It uses OpenID for auth, which is where the hard stuff comes from. I *have* looked at the tests for the OpenID module for catalyst auth, and although I'll surely end up using something like that, it's pretty intimidating. Does anyone have any existing basic tests for OpenID stuff, to test their server, as opposed to the OpenID module, that they might be willing to share? I'd really appreciate it. In the meantime I'll be trying to look more at Ashley's stuff. Thanks! -- fREW Schmidt http://blog.afoolishmanifesto.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] TEST - Please ignore.
Test email, please ignore. 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] Class data in a Moose::Role plugin
I also tried with Catalyst::ClassData. Must be missing something.
All modules up to date. On Perl 5.10.0.
$ catalyst.pl MyApp
$ cat lib/Catalyst/Plugin/Role.pm
package Catalyst::Plugin::Role;
use Moose::Role;
use MooseX::ClassAttribute;
class_has 'Cache' =>
( is => 'rw',
isa => 'HashRef',
default => sub { {} },
);
1;
$ script/myapp_server.pl
Could not load class (Catalyst::Plugin::Role) because :
Catalyst::Plugin::Role already has a metaclass, but it does not
inherit Moose::Meta::Class (Moose::Meta::Role=HASH(0xa38ff10)) at
/usr/local/share/perl/5.10.0/Moose.pm line 162
Moose::init_meta('Moose', 'metaclass', undef, 'for_class',
'Catalyst::Plugin::Role') called at
/usr/local/share/perl/5.10.0/MooseX/ClassAttribute.pm line 22
MooseX::ClassAttribute::init_meta('MooseX::ClassAttribute',
'for_class', 'Catalyst::Plugin::Role', 'metaclass', undef) called at
/usr/local/share/perl/5.10.0/Moose/Exporter.pm line 405
Moose::Exporter::__ANON__('MooseX::ClassAttribute') called at
/home/moseley/MyApp/script/../lib/Catalyst/Plugin/Role.pm line 3
Catalyst::Plugin::Role::BEGIN() called at
/usr/local/share/perl/5.10.0/MooseX/ClassAttribute.pm line 3
eval {...} called at
/usr/local/share/perl/5.10.0/MooseX/ClassAttribute.pm line 3
require Catalyst/Plugin/Role.pm called at
/usr/local/lib/perl/5.10.0/Class/MOP.pm line 134
eval {...} called at /usr/local/lib/perl/5.10.0/Class/MOP.pm line 134
Class::MOP::_try_load_one_class('Catalyst::Plugin::Role')
called at /usr/local/lib/perl/5.10.0/Class/MOP.pm line 95
Class::MOP::load_first_existing_class('Catalyst::Plugin::Role')
called at /usr/local/lib/perl/5.10.0/Class/MOP.pm line 140
Class::MOP::load_class('Catalyst::Plugin::Role') called at
/usr/local/share/perl/5.10.0/Catalyst.pm line 2563
Catalyst::setup_plugins('MyApp', 'ARRAY(0xa2d1598)') called at
/usr/local/share/perl/5.10.0/Catalyst.pm line 1028
Catalyst::setup('MyApp') called at
/home/moseley/MyApp/script/../lib/MyApp.pm line 35
require MyApp.pm called at script/myapp_server.pl line 66
main::__ANON__() called at script/myapp_server.pl line 107
BEGIN failed--compilation aborted at
/home/moseley/MyApp/script/../lib/Catalyst/Plugin/Role.pm line 3.
Compilation failed in require at
/usr/local/lib/perl/5.10.0/Class/MOP.pm line 134.
at /usr/local/lib/perl/5.10.0/Class/MOP.pm line 119
Class::MOP::load_first_existing_class('Catalyst::Plugin::Role')
called at /usr/local/lib/perl/5.10.0/Class/MOP.pm line 140
Class::MOP::load_class('Catalyst::Plugin::Role') called at
/usr/local/share/perl/5.10.0/Catalyst.pm line 2563
Catalyst::setup_plugins('MyApp', 'ARRAY(0xa2d1598)') called at
/usr/local/share/perl/5.10.0/Catalyst.pm line 1028
Catalyst::setup('MyApp') called at
/home/moseley/MyApp/script/../lib/MyApp.pm line 35
require MyApp.pm called at script/myapp_server.pl line 66
main::__ANON__() called at script/myapp_server.pl line 107
Compilation failed in require at script/myapp_server.pl line 66.
With Catalyst::ClassData:
mose...@bumby2:~/MyApp$ cat lib/Catalyst/Plugin/Role.pm
package Catalyst::Plugin::Role;
use Moose::Role;
use Catalyst::ClassData;
__PACKAGE__->mk_classdata( 'foo' );
1;
mose...@bumby2:~/MyApp$ script/myapp_test.pl /
Could not load class (MyApp) because : Could not load class
(Catalyst::Plugin::Role) because : Can't locate object method
"mk_classdata" via package "Catalyst::Plugin::Role" at
/home/moseley/MyApp/script/../lib/Catalyst/Plugin/Role.pm line 5.
Compilation failed in require at
/usr/local/lib/perl/5.10.0/Class/MOP.pm line 134.
...
--
Bill Moseley
mose...@hank.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/
[Catalyst] Feedback requested on HTML::FormHandler's new widget system
A new widget system for HTML::FormHandler is currently under
development, and it would be nice to get feedback from those who might
be interested in it before putting it out in a release.
It's currently in the HTML::FormHandler repository on github:
http://github.com/gshank/html-formhandler/tree/master
I've copied the current version of HTML::FormHandler::Manual::Rendering
at the end of this email.
Please respond offlist or on #formhandler.
Thanks,
Gerda Shank
=
=head1 NAME
HTML::FormHandler::Manual::Rendering
=head1 SYNOPSIS
HFH has a number of different rendering methods.
1. Handcoded html with no assist from HFH at all
2. Use templates and the field 'widget' to determine the template snippet
3. Use a rendering role in your form class, like Render::Simple
and now:
4. Automatically installed rendering widgets using a combination of
rendering roles, which can easily be customized by the user.
=head1 Rendering with Widgets
All FormHandler widgets are Moose roles.
Default widget roles are installed into HTML::FormHandler::Widget. They
include
widgets for the fields in the distribution. Each field can render itself
with
C<< $field->render >>. The widget rendering roles are applied at build
time in
each field object.
The name space used to look for the widget roles can be specified on a
form or
field basis by setting 'widget_name_space' to a scalar name space, like:
has '+widget_name_space' => ( default => 'MyApp::Form::Widget' );
or to an arrayref of name spaces:
has '+widget_name_space' => ( default => sub { ['MyApp::Form::Submit',
'MyApp::Form::Widget' ]);
The HTML::FormHandler::Widget name space is always searched as the last
name space.
This means that you can set up an application or form specific set of
widgets.
Widgets in a widget directory (specified in widget_name_space) are
located in either
a 'Field', 'Wrapper', or 'Form' subdirectory.
The form's rendering role is looked for in the widget name space plus
'Form'. The
default form rendering roles are in HTML::FormHandler::Widget::Form. The
form
widget is specified in the form with 'widget_form'.
package MyApp::Form;
has '+widget_form' => ( widget_form => 'Simple' );
...
The 'wrapper' for field rendering can also be specified with
'widget_wrapper'.
The widget specified will be looked for in the widget directories' 'Wrapper'
subdirectory. It contains a 'wrap_field' method which is called from the
Field
widgets. The wrap_field method takes the basic rendered field (passed
from the
field widget) and wraps it with HTML. The defaults provided are 'Div'
and 'Table'.
You can specify a wrapper class for all the fields in the form by setting
'widget_wrapper' in the form class, or you can set them individually by
setting
'widget_wrapper' on individual fields.
has 'some_field' => ( widget_wrapper => 'MyWrapper' );
The 'widget' attribute is set to a default in FormHandler fields, or you
can
set it to a different widget in your field declarations.
has 'another_field' => ( widget => 'MyWidget', widget_wrapper =>
'MyWrapper' );
Can be set in the form:
widget_name_space
widget_wrapper
widget_form
Can be set in the field:
widget_name_space
widget_wrapper
widget
The widget_name_space and widget_wrapper will be copied into the fields
from the
form if they are not already defined.
By default, a form will use the Form::Simple and Wrapper::Div widgets.
If you
want to use the table format you can change the 'widget_form' and
'widget_wrapper'
attributes in the form, or do it on new:
my $form = MyApp::Form->new( widget_form => 'Table', widget_wrapper
=> 'Table' );
The form widgets will not be applied if a 'render' method already exists
in the form,
such as is the case when you've done a 'with' for
L.
=head1 Customized Widgets
You can create custom widgets for your complete application or on a
per-form basis.
One possible layout for your widgets;
lib/MyApp/Form
lib/MyApp/Form/Widget/Form
lib/MyApp/Form/Widget/Field (contains MyWidget.pm)
lib/MyApp/Form/Widget/Wrapper
Create custom widgets and put them in the respective directories, and
then specify your
widget name space:
MyApp::Form::User:
...
has '+widget_name_space' => ( default => 'MyApp::Form::Widget' );
..
has 'some_field' => ( widget => 'MyWidget' );
Your rendering widgets will be applied into your field classes.
=head1 Creating Widgets
The new widgets are designed to be used with either the original
FormHandler
form objects or the new L objects. For that
reason,
you should use C<< $field->result >> to access the current value, errors
and
'fif' (fill-in-form) in field widgets, so that they will work
for both form and result rendering.
The basic structure for a field widget:
package MyApp::Form::Widget::Field::MyWidget;
use Moose::Role;
sub render
{
my ( $self, $result ) = @_;
$result ||= $self->re
Re: [Catalyst] Splitting up a large application: Shared config and templates for multiple applications
On 28 Aug 2009, at 17:55, Rodrigo wrote: Anyone building applications out of multiple small Catalyst applications like this? How do you set up the apps to share templates and a config? Anything more interesting than passing in paths? I have a working module called CatalystX::Featurizer that I've been using in an app at $work. It's still at a very early stage, but I'm just going to push early. No POD included, no tests... You've been warned. :D http://github.com/rodrigolive/catalystx_featurizer Nice :) I'll look into this more closely when I have chance (this week hopefully) and give you some deeper feedback. One of the things I've been thinking about significantly is how 'features' can ship templates in whatever the feature author's preferred template language is, but allow customisation of those templates (or, more importantly, of the fragments those templates are made from) in a different template language - so using feature X doesn't force the application author to have to use TT or Mason or whatever. I'm interested in your approach to this - given you've obviously thought of this (on some level at least), as you're already supporting TT and Mason. 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] ActionClass vs. Moose Role?
On 28 Aug 2009, at 19:05, Bill Moseley wrote:
Well, if you were going to write something like RenderView now would
you still write it as an ActionClass?
Yes, as Render view isn't something I would ever want two of them on
the same action.
As a counter example, Catalyst::ActionRole::ACL is _much better_ as an
action role, as then it plays nicely with Catalyst::Action::REST
(which should itself be an actionrole!) and other things..
The purpose is to have a standard end() that I use in multiple
applications -- similar to RenderView as I mentioned.
Yeah, in your case, I would probably just go with a controller role
which wraps the end method, as this is conceptually simpler than an
actionclass, but either is a perfectly appropriate decision.
Anyway, using "before 'end'" is probably the way to go in the role
instead of "sub end".
Yes, that's significantly better, due to the fact that methods from
roles will be silently ignored if the local class has a method of that
name.
What I'd be doing is something like this:
package MyApp::Role::Foo;
use Moose::Role -traits => 'MethodAttributes';
sub end : Action {}
before 'end' => sub { # Your code here };
package MyApp::Controller::Foo;
use Moose;
BEGIN { extends 'Catalyst::Controller' }
with 'MyApp::Role::Foo';
# Works like this, OR you can say:
# sub end : Action {
# # Your code here, will get wrapped with your modifier.
# }
BTW -- will the helpers for catalyst.pl start generating Moose-ified
context and controller classes at some point soon?
Yes, this is in the pipeline right now - but nobody has wanted to
tackle it till the GSOC -Devel refactoring is complete. This is
hopefully going to be brushed up and merged fairly soon now. :)
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/
