Re: [cgiapp] Re: multiple run modes in template and form validation
- I assume you are using ValidateRM. There's an option to pass arguments to HTML::FillINForm. Sounds like you need 'ignore_fields' there. More details in the FiF docs. Thanks, Mark. Works perfectly - I should have found this myself. Mike - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: C::A::Dispatch changes
Mark Stosberg wrote:
Michael,
First, thanks for picking up the torch of implementation on this.
No problem. I'm just trying to finalize the API and haven't actually started the
implementation yet, so you might want to wait to thank me :)
:app - will be converted into the module name using the same current rules. So
module_name
will become
Module::Name
I'm also thinking about adding the rule that
module-name
would become
ModuleName
As long as no one has underscores in their module names, we're safe.
That could be worked around if it comes up.
That's a pretty rare case, but right now, the user can just override
get_module_name(). I don't plan on taking this method away.
I'm pretty sure at this point I can keep all of the old stuff functioning the
same if the old interface is used. But I would encourage users to use the new
API to accomplish the same goals.
That works for me. I haven't yet started using the module.
One detail you didn't cover in your write was named params:
':app/:rm/:id'
Right, sorry about that.
:app and :rm would be reserved key names, but anything else would simply
populate $self-param(.
I think that's Rails default dispatching, and is a pattern I like.
Adding named params for me is the most significant functionality
difference over what's there now.
I could help wit the code for it, if you'd like.
Right now I have this module in a svn repo, but I've been recently intrigued by
svk, so I wouldn't mind trying it out with others to see how it works with this.
One detail to keep in mind for implementation is that functions like
'uri_for' and 'link_to' will be accessing the same internal data
structure. I suppose all that means for now is that '@TABLE' be
accessible somewhere as part of the CGI::App object.
Right, another thing I forgot to mention. CAD would probably come with an
additional module to be used as a plugin for you C::A based modules as well if
you want uri_for() and link_to().
I'm thinking about naming this module C::A::Dispatch::Plugin. This would put it
under the CAD namespace since it's part of the same distro, but would mean it
doesn't follow the C::A::Plugin namespace that other plugins go in. Will this be
a problem? I wouldn't think so, since it's not a plugin that can be used on it's
own, but only if CAD is sending the request to app.
This will mean that CAD will have to pass the dispatch table to the C::A object
so that plugin can get to it. So maybe $self-param('dispatch_table') ? I just
want to make sure that I don't clobber something someone's app already has.
When we get to implementing 'uri_for', we may possibly want to create an
alternate representation of it that is easier to do reverse lookups on.
Yeah, I think this table should be optimized for reverse lookups (if CAD::Plugin
is loaded) and also changed into a some sort of compiled/cached version for
normal dispatches to make them faster under persistent environments (probably
with the option to turn this on/off, maybe named 'cache'?). There's no reason
the table needs to be parsed on each request if that can be avoided.
--
Michael Peters
Developer
Plus Three, LP
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] C::A::Dispatch changes
Michael Graham wrote:
This looks great! I like the lower case params.
that seems to be the general consensus, so that's probably the way it'll go.
I'm also thinking about adding the rule that
module-name
would become
ModuleName
I like this a lot, too.
I think it covers the last real popular case for module names.
# in httpd.conf
CGIAPP_DISPATCH_TABLE_CLASS MyProject::Dispatch
# in MyProject/Dispatch.pm
package MyProject::Dispatch;
our @TABLE = (...);
Would it be a bad thing to force mod_perl users to use a subclass of
CA::Dispatch? Something like this:
# in httpd.conf
PerlHandler MyProject::Dispatch
# in MyProject/Dispatch.pm
package MyProject::Dispatch;
use base 'CGI::Application::Dispatch';
sub dispatch_table { ... };
Yeah, that's probably a better idea. But I think I'll name the method
default_dispatch_table() and it will be used if no table is specified. This
makes the implementation of the default table
[
'' = $default,
':app/:rm' = {}
]
pretty easy to do.
--
Michael Peters
Developer
Plus Three, LP
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Working with proxies.
Hello. I already have those pragmas inside templates - as meta tags. So it's not browsers fault. But I doubpt that proxy parses html - adding that to header should do the trick as this Free Proxy claims that it folows some RFC regulation related to caching/proxying. Thanks. - Original Message - From: Cees Hek [EMAIL PROTECTED] To: Webmaster Techcode.NET [EMAIL PROTECTED] Cc: CGIAPP cgiapp@lists.erlbaum.net Sent: Thursday, December 15, 2005 3:14 PM Subject: Re: [cgiapp] Working with proxies. On 12/14/05, Webmaster Techcode.NET [EMAIL PROTECTED] wrote: I have problems with my application when it's accessed via Proxy. Aparently it's output get's cached - so user always get's login form over and over. Sounds like the proxy is setup to cache everything, instead of just content that has proper caching headers set. Just add the following to your app and maybe it will stop the proxy from caching: $self-header_add(-pragma = 'no-cache'); That is from memory, so I might be off slightly, but if you search the internet for 'HTTP cache control headers' you will probably come up with lots of info. Cheers, Cees
[cgiapp] Re: C::A::Dispatch changes
On 2005-12-15, Michael Peters [EMAIL PROTECTED] wrote:
As long as no one has underscores in their module names, we're safe.
That could be worked around if it comes up.
That's a pretty rare case, but right now, the user can just override
get_module_name(). I don't plan on taking this method away.
Works for me.
One detail you didn't cover in your write was named params:
':app/:rm/:id'
Right, sorry about that.
:app and :rm would be reserved key names, but anything else would simply
populate $self-param(.
Great.
I think that's Rails default dispatching, and is a pattern I like.
Adding named params for me is the most significant functionality
difference over what's there now.
I could help wit the code for it, if you'd like.
Right now I have this module in a svn repo, but I've been recently intrigued
by
svk, so I wouldn't mind trying it out with others to see how it works with
this.
I recently installed svk on my laptop play with as well. I still prefer
darcs, but I'm willing to be cooperative. (My first impression of svk
was that it took 4 steps to do what darcs get does in one.)
Right, another thing I forgot to mention. CAD would probably come with an
additional module to be used as a plugin for you C::A based modules as well if
you want uri_for() and link_to().
I'm thinking about naming this module C::A::Dispatch::Plugin. This would put
it
under the CAD namespace since it's part of the same distro, but would mean it
doesn't follow the C::A::Plugin namespace that other plugins go in. Will this
be
a problem? I wouldn't think so, since it's not a plugin that can be used on
it's
own, but only if CAD is sending the request to app.
That's a workable solution, although I think it also works to have the
other part be in the standard C::A::P name space, and have the
dependency be documented. I don't think of URL building as a part
of dispatching, just inter-related.
This will mean that CAD will have to pass the dispatch table to the C::A
object
so that plugin can get to it. So maybe $self-param('dispatch_table') ? I just
want to make sure that I don't clobber something someone's app already has.
I would follow the same conventions we recommend for plugin namespaces:
In order to avoid namespace conflicts within a CGI::Application object, plugin
developers are recommended to use a unique prefix, such as the name of plugin
package, when storing information. For instance:
$app-{__PARAM} = 'foo'; # BAD! Could conflict.
$app-{'MyPlugin::Module::__PARAM'} = 'foo'; # Good.
$app-{'MyPlugin::Module'}{__PARAM} = 'foo'; # Good.
Yes, it means accessing the objects internals, but that's an invitation we
extend to all the current plugin authors anyway.
When we get to implementing 'uri_for', we may possibly want to create an
alternate representation of it that is easier to do reverse lookups on.
Yeah, I think this table should be optimized for reverse lookups (if
CAD::Plugin
is loaded) and also changed into a some sort of compiled/cached version for
normal dispatches to make them faster under persistent environments (probably
with the option to turn this on/off, maybe named 'cache'?). There's no reason
the table needs to be parsed on each request if that can be avoided.
Sounds good.
Mark
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Working with proxies.
I do the following:
use POSIX qw( strftime );
$self-header_add(
# date in the past
-expires = 'Sat, 26 Jul 1997 05:00:00 GMT',
# always modified
-Last_Modified = strftime('%a, %d %b %Y %H:%M:%S GMT', gmtime),
# HTTP/1.0
-Pragma= 'no-cache',
# HTTP/1.1
-Cache_Control = join(', ', qw(
no-store
no-cache
must-revalidate
post-check=0
pre-check=0
)),
);
It's a whole bunch of guns, but one of them usually ends up working.
Rob
On 12/15/05, Webmaster Techcode.NET [EMAIL PROTECTED] wrote:
Hello.
I already have those pragmas inside templates - as meta tags. So it's not
browsers fault.
But I doubpt that proxy parses html - adding that to header should do the
trick as this
Free Proxy claims that it folows some RFC regulation related to
caching/proxying.
Thanks.
- Original Message -
From: Cees Hek [EMAIL PROTECTED]
To: Webmaster Techcode.NET [EMAIL PROTECTED]
Cc: CGIAPP cgiapp@lists.erlbaum.net
Sent: Thursday, December 15, 2005 3:14 PM
Subject: Re: [cgiapp] Working with proxies.
On 12/14/05, Webmaster Techcode.NET [EMAIL PROTECTED] wrote:
I have problems with my application when it's accessed via Proxy.
Aparently it's output get's cached - so user always get's login form over
and over.
Sounds like the proxy is setup to cache everything, instead of just
content that has proper caching headers set. Just add the following
to your app and maybe it will stop the proxy from caching:
$self-header_add(-pragma = 'no-cache');
That is from memory, so I might be off slightly, but if you search the
internet for 'HTTP cache control headers' you will probably come up
with lots of info.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] C::A::P::Session
Just started working with CGI::Application::Plugin::Session and am confused about a few things: 1) I'm used to CGI::Session, where I have to assign a cookie name and the deal with a session id generated by C::S and written into the cookie. How is the session id and cookie name handled in C::A::P::S? Here's what I'm doing (pretty typical): - when script is started I use the prerun to check to see if 'logged-in' is still TRUE. If not, I show the login screen. Otherwise I grab the session values for use in the script. Is C::A::P::S going to work? 2) why do coders preface 'logged-in' with a tilde, e.g., '~logged-in'? What's wrong with 'logged-in'? Thanks, Brad - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
