Once the maintenance stuff is out of the way, I'd like to add this
flourish of syntactic sugar:
$s = new CGI::Session( driver:mysql, undef , { Handle = $dbh } );
Can be rewritten as:
$s = new CGI::Session($dbh);
That's a good idea - especially, since this would make it very easy to
use
I understand that the purpose of the param method is to give me a way to
store variables in $self without potentially colliding with C::A's use of
the same name.
If that's correct, wouldn't it be easier just to choose a naming convention
within C::A (perhaps a prefix: __C_A__) and document that
Mark Jason,
Thanks for your feedback.
Mark Stosberg wrote:
Here's some initial feedback, along with a simple patch below that might get
clobbered by e-mail wrapping.
I would include rm_denied() in the plugin, as well as hooking
this into setup:
$self-run_modes( 'rm_denied' =
There's also the added benefit that you can call params in list context
to get an array containing all the information you have stored in
params() which can make debugging a little bit easier.
I understand that the purpose of the param method is to give me a way to
store variables in $self
That is making the assumption that C::A will always be implemented as a
hash. The documentation says nothing about how C::A is implemented and
therefore makes no guarantees that it won't be an array, or array of
hashes, or anything else.
Speaking of which, who wants to take the first stab at
From: Michael Peters [EMAIL PROTECTED]
Not just that, but it also provides an easy way to pass variables
between methods as well as communicating between plugins and other base
classes.
I'm not an OO guru. If I'm off base please forgive me. But, what's the
difference between
From: Andrew Brosnan [EMAIL PROTECTED]
Just speaking generally about OO, I always figure it's dangerous to
monkey with the object's underlying data structure. Might it change in
the future? Who knows.
I agree with that if I'm acessing C::A's underlying data structure. What I'm
getting at is why
I'm not arguing whether setter/getters are good or bad. Just why I'm forced
to use C::A's. Why is that the only way to avoid stepping on C::A's
variables?
It sounds like you want to rewrite the contract. Currently, the contract states
if you use the param method and its implicit get/set
On 7/4/05 at 2:06 PM, [EMAIL PROTECTED] (Mark Fuller) wrote:
From: Michael Peters [EMAIL PROTECTED]
Not just that, but it also provides an easy way to pass variables
between methods as well as communicating between plugins and other
base classes.
I'm not an OO guru. If I'm off base
Mark Fuller wrote:
From: Michael Peters [EMAIL PROTECTED]
Not just that, but it also provides an easy way to pass variables
between methods as well as communicating between plugins and other base
classes.
I'm not an OO guru. If I'm off base please forgive me. But, what's the
difference
I agree with that if I'm acessing C::A's underlying data structure. What I'm
getting at is why does C::A force its underlying data structure upon me?
Shouldn't I be able to access $self any way I want? Shouldn't there be a way
to prevent me from stepping on C::A's data structure without
Mark Fuller wrote:
No. It's my $self, right? So, I can make any assumptions about how *I*
implement myself, right? I subclassed C::A and I don't want to collide (or
*access*) any of *its* variables. I can understand C::A making me use a
setter/getter method to access *its* variables. But, why
On 7/4/05, Mark Fuller [EMAIL PROTECTED] wrote:
From: Michael Peters [EMAIL PROTECTED]
Not just that, but it also provides an easy way to pass variables
between methods as well as communicating between plugins and other base
classes.
I'm not an OO guru. If I'm off base please forgive me.
From: Michael Peters [EMAIL PROTECTED]
If you want to store your stuff in the $self blessed hash, then go ahead
and do it.
Wait. That sounds like what I'd like to do. Is there a way I can bless my
own sliver of $self and store my own data structure there without trampling
on C:A's use of $self
On 2005-07-04, Dan Horne [EMAIL PROTECTED] wrote:
It seems to me that the namespace issue is problematic. For instance what
constitutes a C::A attribute? How about a plugin? For example -- and it's a
contrived example, I'm afraid -- CGI::Application::Plugin::DBH uses
$self-{__DBH} to store
On 7/4/05, Mark Fuller [EMAIL PROTECTED] wrote:
From: Michael Peters [EMAIL PROTECTED]
If you want to store your stuff in the $self blessed hash, then go ahead
and do it.
Wait. That sounds like what I'd like to do. Is there a way I can bless my
own sliver of $self and store my own data
Following are replies to Dan and Andrew:
From: Dan Horne [EMAIL PROTECTED]
It seems to me that the namespace issue is problematic. ... but what if I
unknowingly wrote a plugin that uses the same attribute,
From what I gather, plug-ins rely upon a namespace mechanism C::A
recommends. Why can't
From: Cees Hek [EMAIL PROTECTED]
1. You need to make sure that you use your own namespace so as not to
collide with anyone else. You suggested that CGI::App use __C_A__ as
a prefix, but it really should be you that uses a prefix.
If C::A provided the namespace, wouldn't this reduce the chances
Hello all,
I'm trying to work on a distributed base class of mine
(CGI::Application::Search) that I want to slim down and make use of the
call back system so that I don't have to tell my users that they need to
override me setup(), etc when they want to extend it.
In doing this, I've run into a
On 7/4/05, Cesar Alba [EMAIL PROTECTED] wrote:
Going a little futher on the answer I found that the CGI.pm header
shows that :standard just imports almost everything. The export_tag's
to avoid is :cgi and :all which is a superset of :cgi. If you want to
use CGI.pm to make HTML, use :html and
Wow, you've been busy ;) Not leaving much for the rest of us! /tease
To give you all an update, I had a hard drive fail in the box I was
going to host the CGI::Session project on. Given the age of the box, I
figured it was doomed to entirely fail at some point, so I swapped in
another box.
21 matches
Mail list logo
