Re: [Catalyst] FormValidator::Simple Sillyness
* Christopher H. Laco [EMAIL PROTECTED] [2006-08-29 21:15]: So, imho, FV::S is not very object vs. class friendly. If I needed to set two different sets of messages for two seperate parts of an app that just happen to have the same action name (like save, load, delete, add, or anything else that is just descript), I'm screwed. This is even worse if you're running one process (Cat app) that hosts multiple sites within it, and each site might have it's own set of messages for form validation (aka, Mango). I switched from HTML::Widget to CGI::FormBuilder as I found to have not enough control over the the rendering of my forms in HTML::Widget. CGI::FormBuiler plays very nice with Catalyst thanks to Catalyst::Plugin::FormBuilder. If you take care to name your formfields the same as your database columns, a simple map allows easy transfer from or to the database. Your TT-templates can be as simple as [%Catalyst.form.render%] if you accept the standard layout and all fields have class and ID fields to be used with your CSS. Karl aka CountZero at Perlmonks ~~~ This message and any attachments are confidential. If you have received this message in error please delete it from your system. If you require any assistance please notify the sender. Thank You. ~~~ ___ 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] FormValidator::Simple Sillyness
I currently use $c-localize in my templates to allow foreign language labels / messages, I struggled a little with HTML::Widget to do this where as with CGI::FormBuilder it was relatively straight forward, so at the moment ;-) I'm also a fan of CGI::FormBuilder. It can also (don't want to start a flame war) generate simple javascript based client validation code, which could help on heavily loaded servers, client performs validation before post, but server also performs same validation. Your probably right about being able to get the same level of control in HTML::Widget but for me it wasn't as straight forward as CGI::FormBuilder. Jason Crummack Easysoft Limited A. Pagaltzis wrote: * [EMAIL PROTECTED] [EMAIL PROTECTED] [2006-08-30 10:05]: I switched from HTML::Widget to CGI::FormBuilder as I found to have not enough control over the the rendering of my forms in HTML::Widget. You can use a custom container class if the default rendering is close to what you want, or you can build the form entirely by hand in the template if you need to do something very specific. That’s all the control over rendering that I need. Regards, ___ 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] Plugins vs. Base Controllers
Matt S Trout wrote: [..] If your only argument is I need $c you can usually do a controller, view or model with an ACCEPT_CONTEXT method. Often you only actually need the app instance (i.e. the MyApp class name in 5.70) not the full request context. Could someone point me example (some basic template, existing code) of this? eloy -- [EMAIL PROTECTED] jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej ___ 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] Announce Catalyst::Plugin::DBIC::TemplateMaker
On 8/30/06, Kieren Diment [EMAIL PROTECTED] wrote: It does virtually nothing, apart from saving you some typing. You must resolve any related columns to a properly stringified name for example. Maybe it should've been a Catalyst::Helper ? Then it could be used through Catalyst's default code-generating interface (i.e. myapp_create.pl). -Nilson Santos F. Jr. ___ 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] Plugins vs. Base Controllers
Check out the thread summary for this thread at: http://www.gossamer-threads.com/lists/catalyst/users/9312?search_string=Plugins%20vs.%20Base%20Controllers;#9312 and toward the bottom Matt gives and example and pointed me to a module that was using it. --john - Original Message From: Krzysztof Krzyzaniak [EMAIL PROTECTED] To: The elegant MVC web framework catalyst@lists.rawmode.org Sent: Wednesday, August 30, 2006 7:18:33 AM Subject: Re: [Catalyst] Plugins vs. Base Controllers Matt S Trout wrote: [..] If your only argument is I need $c you can usually do a controller, view or model with an ACCEPT_CONTEXT method. Often you only actually need the app instance (i.e. the MyApp class name in 5.70) not the full request context. Could someone point me example (some basic template, existing code) of this? eloy -- [EMAIL PROTECTED] jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej ___ 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/ ___ 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] Announce Catalyst::Plugin::DBIC::TemplateMaker
On 30/08/06, Nilson Santos Figueiredo Junior [EMAIL PROTECTED] wrote: On 8/30/06, Kieren Diment [EMAIL PROTECTED] wrote: It does virtually nothing, apart from saving you some typing.You must resolve any related columns to a properly stringified name for example.Maybe it should've been a Catalyst::Helper ?Then it could be used through Catalyst's default code-generatinginterface (i.e. myapp_create.pl).Dunno how that would help. It's a temporary method to be called during development that returns a very very basic template . There's no place for it in code generation just during dev for working up a template. Anyway I can see some holes in the docs to be patched for 0.02 and then some extemely primitive form generation fro 0.03 :) ___ 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] Plugins vs. Base Controllers
John Napiorkowski wrote: Check out the thread summary for this thread at: http://www.gossamer-threads.com/lists/catalyst/users/9312?search_string=Plugins%20vs.%20Base%20Controllers;#9312 and toward the bottom Matt gives and example and pointed me to a module that was using it. --john - Original Message From: Krzysztof Krzyzaniak [EMAIL PROTECTED] To: The elegant MVC web framework catalyst@lists.rawmode.org Sent: Wednesday, August 30, 2006 7:18:33 AM Subject: Re: [Catalyst] Plugins vs. Base Controllers Matt S Trout wrote: [..] If your only argument is I need $c you can usually do a controller, view or model with an ACCEPT_CONTEXT method. Often you only actually need the app instance (i.e. the MyApp class name in 5.70) not the full request context. Could someone point me example (some basic template, existing code) of this? Thank you, works like a charm. eloy -- [EMAIL PROTECTED] jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej ___ 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] Anyone actually using FastCGI with Apache (or even lighttpd)?
On 8/30/06, Matt S Trout [EMAIL PROTECTED] wrote: On 30/08/06, Jason Kohles [EMAIL PROTECTED] wrote: On 8/29/06, Matt S Trout [EMAIL PROTECTED] wrote: If somebody could write this up for Engine::FastCGI in the form of a patch I'm sure it could ship in 5.7002 I started to, but the workaround involves changing some environment variables in ways that (for Apache at least) require knowledge of the Apache configuration that FastCGI doesn't make available to the OK, how about a *documentation* patch outlining the issue and possible workarounds then please? Fair enough, see attachment... -- Jason Kohles [EMAIL PROTECTED] - http://www.jasonkohles.com/ A witty saying proves nothing. -- Voltaire FastCGI.diff Description: Binary data ___ 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] Is this right (Chained actions)
Okay,
Maybe a more simple explanation of my question. The documentation talkes about
using relative paths in the Chain attribute, however the :Chained('.') doesn't
work unless there is already a :Chained('/') for it to find. So if I want to
match, /templates/* I can do the following (somewhat contrived example
follows):
package myapp::templates
sub templates :Chained Args(1)
{
[...]
}
or if I want better control of the action name I can do:
package myapp::templates
sub list:Chained PathPart('templates') Args(1)
{
[...]
}
What I'd like to do is:
package myapp::templates
sub list:Chained PathPart('.') Args(1)
{
[...]
}
So that I get a way to start a chain from the current controller's namespace
without having to hardcode part of the namespace. However in this last example
what actually gets matched is /./* (it actually matches on the . as a
literal).
So I guess my confusion is in how differently the Path and PathPart attribute
work. The Path attribute defaults to matching the controller's namespace but
:PathPart acts more like :Local in that it matches to the action name. I wish
there was a good way to do something like the third example but I'm not seeing
it. What do you all think of this behavior and does anyone have a good way to
get a chain rooted to the controller namespace without have to hardcode some
part of the controller name? I'd like this for some custom controllers I am
making.
--john
___
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] auth::DBIC session problems
On Tue, Aug 15, 2006 at 12:01:34 -0400, [EMAIL PROTECTED] wrote: So I still have the problem where if I use Authentication::Store::DBIC, I cannot use a session plug-in because freeze() doesn't like coderefs, and my DBIC objects contain codrefs for their inflate/deflate methods. Okay, i finally figured this one out. Win Srv 2003 Apache 2.0.58/modperl These are the guilty parties. Update Tie::RefHash... The core version isn't thread safe, which means reindexing of refhashes on changed refaddr on either faked fork on windows, or threaded MPMs with apache 2. This causes the auth store registry to become effectively corrupted, since the indexing is wrong, and thus the store is saved in the session (instead of the store name). Sorry it took so long. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgp4cFxQCOyrm.pgp Description: PGP signature ___ 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] Fastest Perl HTTPD?
Hi, On 2006/08/28, at 12:48, Kaare Rasmussen wrote: I don't. But for me at least, what I'm looking for is a simpler HTTPD to power my back-end's with Catalyst apps. Even if ax2 is a little bit slower than Apache, it would be a good choice in some situations. Agreed. But that is asuming that the performance is similar to Apache/modperl, not say 10 times slower - or worse: excessive memory requirements. I doubt it will be slower than Apache. The network part should be as fast, given that most Danga::Socket and IO::AIO code is XS. The header parsing and dispatching could probably be slower, although there is a HTTP::Headers::XS already. Also I wonder if programming ax2 would be as easy as programming eg POE. Can it be extended beyond a webserver? For me ax2 would be uninteresting if it can only handle http events. I think you should look at qsmtpd as the source of inspirarion. Best regards, -- Pedro Melo JID: xmpp:[EMAIL PROTECTED] ___ 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::Engine::POE status
Hi, is anybody using the POE engine? I'm doing a standalone web-based perl App and it seems an excellent choice. Thanks in advance, -- Pedro Melo JID: xmpp:[EMAIL PROTECTED] ___ 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] Generate a URL for a given action
Hi,
I'm sure this is a no brainer but I just can't find it anywhere. Basically
what I am trying to find out is if there is a programmatic way to discover the
url for a given action in controller just by using the action name. Here is
the example I am trying to deal with:
package myapp::templates
##n ormal controller setup stuff
sub templates :Chained('/') CaptureArgs(0)
{
## Get the templates list from the model
}
sub list :Chained('templates') PathPart('') Args(0)
{
## Show a list of all templates found by the template action
}
sub template :Chained('templates') PathPart('') CaptureArgs(1)
{
## Retrieve info about a particular template
}
sub view :Chained('template') PathPart('') Args(0)
{
## View the template found by the template action
}
sub edit :Chained('template') PathPart('edit') Args(0)
{
my ($self, $c) = @_;
if( $c-request-method eq 'GET' )
{
##Just show the Form
}
elsif($c-request-method eq 'POST')
{
## Do some form processing and if everything saves okay...
$c-response-redirect(/templates);
}
}
Basically I'd like to replace the hardcoded path in the redirect(/templates)
since I am not too sure where this app will eventually sit in the web
hierarchy. Now, the docs for $c-get_uri says you can pass an action to it to
get the url, which seems to me what I want. If I did:
$c-response-redirect($c-uri_for('templates'));
Would this work correctly even if this controller ends up deeply nested?
--john
___
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] Generate a URL for a given action
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John
Napiorkowski
Sent: August 30, 2006 8:08 PM
To: catalyst@lists.rawmode.org
Subject: [Catalyst] Generate a URL for a given action
Hi,
I'm sure this is a no brainer but I just can't find it
anywhere. Basically what I am trying to find out is if there
is a programmatic way to discover the url for a given action
in controller just by using the action name. Here is the
example I am trying to deal with:
You've got it backwards. In your example the `list', `template' and `view'
actions all map to `/templates'.
You should have something like:
package MyApp::Controller::Templates;
sub template :Chained('/') :PathPart('') :CaptureArgs(1) {...}
sub list :Chained('template') :Args(0) {...}
sub view :Chained('template') :Args(0) {...}
See
http://search.cpan.org/~mramberg/Catalyst-Runtime-5.7001/lib/Catalyst/Dispat
chType/Chained.pm#Introduction for a good example.
*snip*
Basically I'd like to replace the hardcoded path in the
redirect(/templates) since I am not too sure where this app
will eventually sit in the web hierarchy. Now, the docs for
$c-get_uri says you can pass an action to it to get the url,
which seems to me what I want. If I did:
$c-response-redirect($c-uri_for('templates'));
Would this work correctly even if this controller ends up
deeply nested?
`$c-response-redirect($c-uri_for('templates'))' should work, since it's a
path relative to the current controller. The uri_for method should prepend
the URI with your app's base URL and the path to the controller, so that
should be all you need.
--john
___
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/
___
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/
