Re: [Catalyst] FormHandler -- pro or con?
On Thu, Dec 9, 2010 at 2:44 AM, Toby Corkindale wrote: > (I do have some code that programmatically generates the form config > based on the object you're editting, although I use a precreated base > for it) Well - there is http://search.cpan.org/~gshank/HTML-FormHandler-Model-DBIC-0.14/lib/HTML/FormHandler/Generator/DBIC.pm -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] FormHandler -- pro or con?
On 7 December 2010 18:03, Octavian Rasnita wrote: > From: "Toby Corkindale" > >> On 1 December 2010 02:34, will trillich wrote: >>> Anybody else *dissing* FormHandler? We've started developing based on >>> FormHandler lately and haven't had troubles... yet? >> >> I'm running it, and have been very happy with it. >> It's nice that you can put all your common form elements into roles >> and then combine them. >> I'm familiar with Moose, so HFH's syntax came fairly naturally to me, >> but I guess it could be confusing to others? >> >> Performance is reasonable - and a lot faster compared to FormFu. >> >> Cheers, >> Toby > > > Is there a way of making H::FH beeing more elegant? > > I mean, is there a way of doing something to not need using Perl code for > creating the forms, but only using some configuration files like in H::FF's > case? I guess there is more than one way to do everything.. I didn't like having to write YAML for H:FF, since YAML is ugly, and then one needed to take multiple YAML files and merge them a lot, and.. ugh. Using Moose Roles for forms is awesome. But, that said, you could write your forms in some kind of DB or config file and load them up, but you miss out on the best bits of HFH that way. (I do have some code that programmatically generates the form config based on the object you're editting, although I use a precreated base for it) Toby ___ 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] Transferring control via root/auto
On Wednesday, December 08, 2010 07:31:42 am Tomas Doran wrote:
> On 7 Dec 2010, at 16:11, Ben van Staveren wrote:
> > You want to $c->detach('end') -- unless that's the default these
> > days. I use this pattern a lot and the only difference I see is that
>
> > I do:
> The end action will _always_ be run, there is no need to detach to the
> end action.
>
> However I'm not sure what doing $c->detach in auto will do (I guess
> the same as returning 0 - i.e. stop further actions from running), but
> I'm not sure - you should probably return 0 (to stop further dispatch)
> rather than detaching in the auto action..
Since auto is internally just another step in _DISPATCH (Catalyst gets to it
by calling forward and everything) detaching from it behaves as you'd expect
-- the action you detach to is run, and so is end, and the current dispatch
(including the rest of auto and running $c->action) is abandoned. So, possibly
there are *cleaner* ways to deal with situations like that (often involving
Chained), but if you want to do it, it shouldn't break on you.
Andrew
___
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] Transferring control via root/auto
Actualy I find that diagram to pretty much stick to the basic rules.
His auto code is the problem. While he's redirecting to the change
password, he is also re-entering auto. And, most probably the
conditions are met. A pretty straight forward solution is to do
something like:
if ($c->user_exists()&& $c->check_any_user_role('User')
&& $c->user->changePassword ) {
+ return 1 if $c->action->reverse eq 'users/loginedit';
$c->res->redirect($c->uri_for($c->controller('Users')->action_for('loginedit'),
[$c->user->id] ));
$c->detach();
On Wed, Dec 8, 2010 at 6:49 PM, Ashley Pond V wrote:
> On Wed, Dec 8, 2010 at 6:59 AM, Larry Leszczynski
> wrote:
>>
>> In situations like this I find this flow diagram helpful:
>>
>>
>> http://dev.catalystframework.org/attachment/wiki/WikiStart/catalyst-flow.png
>>
>> but I admit I am also not totally clear about how detach/go fit in...
>> Maybe someone has an updated diagram (or can update this one)?
>
> I did that diagram a loong time ago (2006?). I'd be glad
> to amend it and I can see obvious changes it needs but I'd probably
> need input from core devs to round it out "perfectly."
>
> -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/
>
--
Cosmin Budrica
Developer @ www.sinapticode.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] Configuration Management in Continuous Integration environments
Not exactly a Catalyst-specific query, however... Right, certainly loading all the deps onto your CI at the system/global level doesn't work when you've multiple projects, branches building that have conflicting dependency requirements. I've seen this problem solved by the "toolchain" method of committing deps along with each project so that the deps move along with the software they support. You could include both the source tarballs and the install dir(s) in your commits. Some purists condemn this, pointing to, e.g. DRY, but it can get the job done, which I think is what counts at the end of the day. I've also seen CI systems address this by creating their own entire build environments *at build time* -- see the Fedora Project's Koji. Again, this allows for multiple projects to build without trampling on one another's deps/envs. One downside is that your builds can take long while to complete. For faster build times, you may find the toolchain approach or even having multiple build systems works better for you. --Trevor Nicholas Wehr wrote: Hello everyone, First off, beware, I'm a bit nutty when it comes to configuration management. I've recently deployed a Hudson instance and wanted to move some Catalyst projects into it. What I'd like to solicit feedback on here is: /how are you managing your Perl dependencies in these build systems? /Here's some goals I have: * do not assume any non-core modules are installed on the build platform * use specific version of modules in the built product - product is a Catalyst website for example (@inc or use lib) * need to archive specific version of CPAN dependencies offline; this means we can recreate a product without an internet connection * allow for the rebuild of dependencies when the build platform has changed; this is meant to address a platform change from 32bit to 64bit What I'm looking at is either using local::lib or PREFIX & LIB w/ cpan. What do you think? Thanks in advance, -nicholas ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Transferring control via root/auto
On Wed, Dec 8, 2010 at 6:59 AM, Larry Leszczynski wrote: > > In situations like this I find this flow diagram helpful: > > http://dev.catalystframework.org/attachment/wiki/WikiStart/catalyst-flow.png > > but I admit I am also not totally clear about how detach/go fit in... > Maybe someone has an updated diagram (or can update this one)? I did that diagram a loong time ago (2006?). I'd be glad to amend it and I can see obvious changes it needs but I'd probably need input from core devs to round it out "perfectly." -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] Transferring control via root/auto
Hi -
On Wed, 08 Dec 2010 13:31 +, "Tomas Doran"
wrote:
>
> On 7 Dec 2010, at 16:11, Ben van Staveren wrote:
>
> > You want to $c->detach('end') -- unless that's the default these
> > days.
>
> The end action will _always_ be run, there is no need to detach to the
> end action.
>
> However I'm not sure what doing $c->detach in auto will do (I guess
> the same as returning 0 - i.e. stop further actions from running), but
> I'm not sure - you should probably return 0 (to stop further dispatch)
> rather than detaching in the auto action..
In situations like this I find this flow diagram helpful:
http://dev.catalystframework.org/attachment/wiki/WikiStart/catalyst-flow.png
but I admit I am also not totally clear about how detach/go fit in...
Maybe someone has an updated diagram (or can update this one)?
Thanks!
Larry
___
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] Transferring control via root/auto
On 7 Dec 2010, at 16:11, Ben van Staveren wrote:
You want to $c->detach('end') -- unless that's the default these
days. I use this pattern a lot and the only difference I see is that
I do:
The end action will _always_ be run, there is no need to detach to the
end action.
However I'm not sure what doing $c->detach in auto will do (I guess
the same as returning 0 - i.e. stop further actions from running), but
I'm not sure - you should probably return 0 (to stop further dispatch)
rather than detaching in the auto action..
However as noted elsewhere in this thread, I'd seriously recommend
using Chained dispatch rather than auto for this (if for no other
reason then it avoids the re-entering auto in the next request after
you redirect issue).
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/
