Menu
▾
▴
cgi-prototype-users — the general mailing list for CGI::Prototype
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
(6) |
Jun
(13) |
Jul
(3) |
Aug
(30) |
Sep
(42) |
Oct
(12) |
Nov
|
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ryan T. <li...@ry...> - 2005-06-26 18:47:41
|
Randal L. Schwartz <me...@st...> wrote: > Now, are you starting to see why I started with Class::Prototyped? I actually started to think, "prototyped objects are actually a little ... _fun_". Prototypes are sort of the Perl of object oriented programming. RE FAQ, I have not seen it, but let me know if you want anything (else) written up on this. Glad you liked! RT |
|
From: <me...@st...> - 2005-06-26 15:51:06
|
>>>>> "Ryan" == Ryan Tate <li...@ry...> writes:
Ryan> So I decided to extend your idea a bit to the following:
Ryan> sub My::App::app_enter{
Ryan> my $self = shift;
Ryan> my $per_hit = Class::Prototyped->new;
Ryan> $self->reflect->addSlots( 'per_hit*' => $per_hit,
Ryan> per_hit => $per_hit );
Ryan> }
Oooh. Cool. Shiny Object.
Now, are you starting to see why I started with Class::Prototyped?
I *knew* stuff like this would show up. :)
This is definitely going into my snippets file. I hope to have a
CGIP::Cookbook in a future release, or maybe we'll just take turns
updating CGIP::FAQ.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
|
|
From: Ryan T. <li...@ry...> - 2005-06-26 06:23:18
|
Randal L. Schwartz <me...@st...> wrote:
> Another way would be to put all your slots into one big "per hit" slot,
> and then ensure that this is cleared out:
>
> sub My::App::app_enter {
> my $self = shift;
> $self->reflect->addSlot(per_hit => {});
> }
I like this approach quite a bit.
After reading your message, though, I got a bit greedy and decided I
wanted to be able to add slots rather than just hash entries to per_hit,
so I could do cool things like autoload fields and coderefs that you don't
have to know are coderefs.
Then I got a bit lazy and decided I did not want to edit all my templates
to change things like "[% self.user %]" to "[% self.per_hit.user %]".
So I decided to extend your idea a bit to the following:
sub My::App::app_enter{
my $self = shift;
my $per_hit = Class::Prototyped->new;
$self->reflect->addSlots( 'per_hit*' => $per_hit,
per_hit => $per_hit );
}
I went through my classes and changed most every ->reflect->addSlots
to ->per_hit->reflect->addSlots, and things seem to be working fine. At
least, nothing has blown up yet ;->
I double-checked to make sure the 'per_hit*' parent classes were not
accumulating on top of one another, one for each hit. As I
suspected, writing a parent slot with the same name as
a previously-established parent slot seems to overwrite it.
One problem with this approach is that almost every slot I create seems to
be per_hit. I'm starting to think it would be smarter to create a
'persist*'/'persist' slot in the manner above, then in control_leave
iterate over
the slots and delete each one except 'persist'. This may be time consuming,
however.
RT
|
|
From: <me...@st...> - 2005-06-25 19:44:46
|
>>>>> "Randal" == Randal L Schwartz <me...@st...> writes:
Randal> sub My::App::control_enter {
Randal> my $self = shift;
Randal> $self->reflect->addSlot(per_hit => {});
Randal> }
That should be My::App::app_enter { }
control_enter would cause it to get cleared as you transition from one
handler to another, although that might be an interesting use.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
|
|
From: <me...@st...> - 2005-06-25 19:05:16
|
>>>>> "Ryan" == Ryan Tate <li...@ry...> writes:
Ryan> Hello,
Ryan> I recently moved a simple CGI::Prototype-based Web app over to a
Ryan> mod_perl2 installation. It wasn't too hard.
That's good to hear. I tried to design CGIP with mod_perl in mind,
but I had no current customers using mod_perl directly.
Ryan> One thing I eventually noticed: if you dispatch to objects
Ryan> representing particular classes, as CGI::Prototype::Hidden does (see
Ryan> name_to_page and its call to $package->reflect->object), you have to
Ryan> be careful to re-initialize slots as needed, because package objects
Ryan> are not garbage collected and thus will persist.
Yes. And this can be trouble, as you've seen.
Ryan> To handle initialization, for each class with slots I want killed
Ryan> before the next request, I do a control_leave with
Ryan> $self->reflect->deleteSlots(qw(userfoo userbar tempfoo tempbar)),
Ryan> along with $self->SUPER::control_leave(@_) for any classes above.
That would seem to be the logical place to do this.
Another way would be to put all your slots into one big "per hit" slot,
and then ensure that this is cleared out:
sub My::App::control_enter {
my $self = shift;
$self->reflect->addSlot(per_hit => {});
}
Through testing, I see that addSlot also throws away any previous
meaning for the slot, so this trashes the previous round data just
fine.
Then in any thing that needed it:
sub randomfunc {
my $self = shift;
my $per_hit = $self->per_hit;
$per_hit->{foo} = "bar";
}
In this case, you just need to keep your keys of $per_hit clean,
but you had to do that with slots anyway. :) This'll also be faster
than adding and deleting slots every time.
Ryan> PS Liked the first Linux Mag article.
Parts two and three coming up... :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
|
|
From: Ryan T. <li...@ry...> - 2005-06-25 18:50:30
|
Hello, I recently moved a simple CGI::Prototype-based Web app over to a mod_perl2 installation. It wasn't too hard. One thing I eventually noticed: if you dispatch to objects representing particular classes, as CGI::Prototype::Hidden does (see name_to_page and its call to $package->reflect->object), you have to be careful to re-initialize slots as needed, because package objects are not garbage collected and thus will persist. To handle initialization, for each class with slots I want killed before the next request, I do a control_leave with $self->reflect->deleteSlots(qw(userfoo userbar tempfoo tempbar)), along with $self->SUPER::control_leave(@_) for any classes above. If you fail to re-initialize your slots, they persist to the next hit, which is a feature if you know what you're doing and a bug otherwise. I have not yet found it useful to persist any slots. I am curious if name_to_page was made with an eye toward mod_perl -- was it foreseen that in a persistent environment one might need to initialize slots? I'm wondering if a better approach might be to make my own name_to_page that does $package->new, thus not requiring any initialization, but costing more (probably) in obj creation and requiring extra work to keep track of shortname (essentially page_to_name to remember what state name/package was used to gen the object). I have not yet found any slots I wish to persist so I end up having to remember to write an initializer for each slot I create. Cheers RT PS Liked the first Linux Mag article. |
|
From: <me...@st...> - 2005-06-22 00:27:33
|
>>>>> "Terrence" == Terrence Brannon <ba...@me...> writes: Terrence> Forgive me if I'm hallucinating, but I could've sworn that there was a Terrence> CGI::Prototype::PathInfo module or method in one of the earlier Terrence> releases. I've talked about it. Haven't gotten to it. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
|
From: Terrence B. <ba...@me...> - 2005-06-22 00:07:26
|
Forgive me if I'm hallucinating, but I could've sworn that there was a CGI::Prototype::PathInfo module or method in one of the earlier releases. Does anyone know of any such resource? I'm going to be doing some stuff which is mainly just wrapping static paths with common look and feel, and such support would be useful. -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality. |
|
From: <me...@st...> - 2005-05-12 01:01:44
|
I recently finished the third of three parts of my "intro to CGI::Prototype" talk, for my Linux Magazine column. You can see it on their site as it comes about, or on my site eventually at <http://www.stonehenge.com/merlyn/LinuxMag/col70.html> <http://www.stonehenge.com/merlyn/LinuxMag/col71.html> <http://www.stonehenge.com/merlyn/LinuxMag/col72.html> -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
|
From: <me...@st...> - 2005-05-03 14:16:20
|
>>>>> "LD" == LD <lds...@ya...> writes: LD> Possibly - but its real name (e.g., "Main") is properly spat out when LD> such a definition is within a template file; but not with the LD> above. Perhaps it needs detainting to work... From within a template file, "self" is a named class, if you're using CGI::Prototype::Hidden. I'm not sure how you're using the file above, but I bet "self" is not a named class any more. LD> Ahh, yep - that works. Cheers. Good. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
|
From: LD <lds...@ya...> - 2005-05-03 13:48:14
|
Hi there,
On 03/05/2005, at 9:28 PM, Randal L. Schwartz wrote:
> LD> sub someTemplate { \ <<'EOT'; }
> LD> [% self.CGI.header %]
> LD> [% self.CGI.h1(self.reflect.package) %]
> LD> EOT
> LD> ...I <..> get something like: PKG0x958d0c
>
> Well, that's probably the actual package name of that lightweight
> class.
Possibly - but its real name (e.g., "Main") is properly spat out when
such a definition is within a template file; but not with the above.
Perhaps it needs detainting to work...
> local $_ = $self->shortname;
> tr/_/ /;
tr/::/ /;
> s/\b([a-z])/\U$1/g;
Ahh, yep - that works. Cheers.
> "This (and other) tips will be found in the forthcoming
> CGI::Prototype::Cookbook, coming soon to a CPAN near you. Offer void
> where prohibited."
No doubt it'll be a useful resource...
with regards,
--
LD
|
|
From: <me...@st...> - 2005-05-03 11:29:56
|
>>>>> "LD" == LD <lds...@ya...> writes:
LD> Hi there,
LD> If I have the following as part of a template definition (in a file):
LD> [% self.CGI.h1(self.reflect.package) %]
LD> ...it returns the proper name as expected. If I however do:
LD> sub someTemplate { \ <<'EOT'; }
LD> [% self.CGI.header %]
LD> [% self.CGI.h1(self.reflect.package) %]
LD> EOT
LD> ...I instead get something like: PKG0x958d0c
Well, that's probably the actual package name of that lightweight
class.
Here's what I did for a client recently. In App.pm, I added
sub title {
my $self = shift;
local $_ = $self->shortname;
tr/_/ /;
s/\b([a-z])/\U$1/g;
return "Initech Corporation Conference Registration: $_";
}
And in my WRAPPER.tt, I have:
[% self.CGI.start_html("-title", self.title) %]
This defines the default titlebar related to the state name.
And yet, any specific state can provide
sub title { "Acquiring Remote Latinum" }
to override that.
"This (and other) tips will be found in the forthcoming
CGI::Prototype::Cookbook, coming soon to a CPAN near you. Offer void
where prohibited."
;-)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
|
|
From: Terrence B. <ba...@me...> - 2005-05-03 06:32:34
|
LD <lds...@ya...> writes:
> Hi there,
Hi LD,
> >
> If I have the following as part of a template definition (in a file):
> [% self.CGI.h1(self.reflect.package) %]
<h1>[% self.reflect.package %]</h1>
looks cleaner to my personal taste.
> >
> ...it returns the proper name as expected. If I however do:
> sub someTemplate { \ <<'EOT'; }
> [% self.CGI.header %]
> [% self.CGI.h1(self.reflect.package) %]
> EOT
I don't have an answer to your question, but would like to make a
comment.
One of my initial criticisms of the CGI::Prototype docs was what you
are doing here. The call to $self->CGI->header is more general and
will apply to many more pages/objects than the current page. It does
not belong in the same method as a page-local call such as
$self->reflect->package: it is application-wide not page-local.
I think it belongs in render_enter in a base class... then, if a
particular page needs to send a certain content type, it can override
the method.
--
Carter's Compass: I know I'm on the right track when,
by deleting something, I'm adding functionality.
|
|
From: LD <lds...@ya...> - 2005-05-03 01:45:35
|
Hi there,
If I have the following as part of a template definition (in a file):
[% self.CGI.h1(self.reflect.package) %]
...it returns the proper name as expected. If I however do:
sub someTemplate { \ <<'EOT'; }
[% self.CGI.header %]
[% self.CGI.h1(self.reflect.package) %]
EOT
...I instead get something like: PKG0x958d0c
How might this be fixed?
Cheers.
--
LD
|
|
From: <me...@st...> - 2005-04-28 16:07:31
|
>>>>> "Jim" == Jim Brandt <cb...@bu...> writes: Jim> And for what it's worth, CGI::Prototype::Hidden adds some nice Jim> features, so you may consider checking that out. Yeah, I should probably make it clearer that CGI::Prototype starts a bit too close to the metal. CGI::Prototype::Hidden (and the upcoming "when I get a few more tuits" CGI::Prototype::Pathinfo) are a much better starting framework for a "real" app. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
|
From: <me...@st...> - 2005-04-28 15:18:54
|
>>>>> "Matthew" == Matthew Browning <mb...@ma...> writes: Matthew> On Thursday 28 April 2005 06:25, LD wrote: >> >> What's the best way of including the output of Header and Footer in >> the render phase - i.e., as if you'd concated the output of: Header-> activate; Main->activate; Footer->activate; >> >> Any thoughts? >> Matthew> The functionality you're after is suggested in the docs of Matthew> CGI::Prototype::Hidden, here (link will probably wrap): Matthew> http://search.cpan.org/~merlyn/CGI-Prototype-0.9052/lib/CGI/Prototype/Hidden.pm#MANAGEMENT_SLOTS Matthew> I'd go easy using anything marked as `experimental' but I've had a go at Matthew> using this feature, purely as a point of interest, and it does work. Matthew> Be nice to see how this develops. Or, do as I've done, and put all that in WRAPPER.tt - you can do an amazing amount there. I've just finished a seriously fleshed out medium size project with CGIP, and I'm probably going to take my "this works, that doesn't" thoughts and put them into CGI::Prototype::Cookbook. For example, my top level class was GC::App... so I created GC/ttlib to hold all my INCLUDE'd files, because they'd sit alongside the rest of my app, but not get in the way of the files in GC/App/*.tt, which I reserved purely for state-based pages. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
|
From: Jim B. <cb...@bu...> - 2005-04-28 11:51:41
|
For standard header/footer stuff for pages, we take care of this on the template side since this tends to be view-like information. We put it in our wrapper.tt (along with error-handling code) so it gets run for each page. Then each page.tt only needs to handle display duties for the middle part of the page. With Template Toolkit, you can use INCLUDE to pull in other templates easily in the display phase. If you have dynamic data in your headers and footers, you can handle that a few ways. The easiest is probably to add subs to your App.pm base class and call back to them from TT. Since self is sent to the template, you can call any of the methods from there. Another way is to create new slots, generate the data in your pm files, stick the data in the slot, then reference it from the Template. In general, I've found that one pm = one page, so you usually won't create separate pm files for smaller components. If it is a shared component, you can stick it in App.pm. And for what it's worth, CGI::Prototype::Hidden adds some nice features, so you may consider checking that out. Hope this helps. Jim On Apr 28, 2005, at 1:25 AM, LD wrote: > Hi there, > > obviously an active list :-) > > Anyway - I'm so far really liking CGI::Prototype (with its simple MVC > implementation) but what I'm not clear on is the best way to > incorporate Reusable Components. > > Say you've got the following components which all inherit from > CGI::Prototype... > > Header: (reusable) > /Header.pm > /Header.tt > > Various Pages: > /Main.pm > /Main.tt > /Login.pm > /Login.tt > <...> > > Footer: (reusable) > /Footer.pm > /Footer.tt > > ...and somecgi.cgi which basically does > Main->activate; > > What's the best way of including the output of Header and Footer in > the render phase - i.e., as if you'd concated the output of: > Header->activate; Main->activate; Footer->activate; > > Any thoughts? > > Cheers, > LD > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Tell us your software development plans! > Take this survey and enter to win a one-year sub to SourceForge.net > Plus IDC's 2005 look-ahead and a copy of this survey > Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix > _______________________________________________ > cgi-prototype-users mailing list > cgi...@li... > https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users > ========================================== Jim Brandt Administrative Computing Services University at Buffalo |
|
From: Matthew B. <mb...@ma...> - 2005-04-28 09:57:31
|
On Thursday 28 April 2005 06:25, LD wrote: > > What's the best way of including the output of Header and Footer in > the render phase - i.e., as if you'd concated the output of: > Header->activate; Main->activate; Footer->activate; > > Any thoughts? > The functionality you're after is suggested in the docs of CGI::Prototype::Hidden, here (link will probably wrap): http://search.cpan.org/~merlyn/CGI-Prototype-0.9052/lib/CGI/Prototype/Hidden.pm#MANAGEMENT_SLOTS I'd go easy using anything marked as `experimental' but I've had a go at using this feature, purely as a point of interest, and it does work. Be nice to see how this develops. MB -- http://matthewb.org/public_key.txt |
|
From: LD <lds...@ya...> - 2005-04-28 05:26:03
|
Hi there, obviously an active list :-) Anyway - I'm so far really liking CGI::Prototype (with its simple MVC implementation) but what I'm not clear on is the best way to incorporate Reusable Components. Say you've got the following components which all inherit from CGI::Prototype... Header: (reusable) /Header.pm /Header.tt Various Pages: /Main.pm /Main.tt /Login.pm /Login.tt <...> Footer: (reusable) /Footer.pm /Footer.tt ...and somecgi.cgi which basically does Main->activate; What's the best way of including the output of Header and Footer in the render phase - i.e., as if you'd concated the output of: Header->activate; Main->activate; Footer->activate; Any thoughts? Cheers, LD |
|
From: Terrence B. <ba...@me...> - 2005-04-10 16:53:28
|
NAME
CGI::Prototype::Docs::Resources - links to CGI::Prototype resources
Mailing list
CGI::Prototype Mailing List
There is now a mailing list for discussing the use of CGI::Prototype, a
Perl module which allows for class and prototype-based object-oriented
development of CGI applications.
SUBSCRIBING
Via Mailman/Sourceforge
Visit <http://lists.sourceforge.net/lists/listinfo/cgi-prototype-users>
and enter your subscription information.
Via Gmane
You can join the newsgroup
gmane.comp.lang.perl.modules.cgi-prototype.user
If you are a Gnus user, here's the subscription string for you:
nntp+news.gmane.org:gmane.comp.lang.perl.modules.cgi-prototype.user
ARCHIVES
* <http://dir.gmane.org/gmane.comp.lang.perl.modules.cgi-prototype.user>
*
<http://sourceforge.net/mailarchive/forum.php?forum=cgi-prototype-users>
*
<http://www.mail-archive.com/cgi-prototype-users%40lists.sourceforge.net
/>
This last one should work. I am still waiting for my primer message
to show in the archive.
Tutorials / Overviews
Ourmedia's "Introduction to CGI::Prototype"
<http://sourceforge.net/project/showfiles.php?group_id=135173&package_id
=149434>
"Prototype Programming for Classless Classes"
<http://www.stonehenge.com/merlyn/LinuxMag/col56.html>
Perlmonks CGI::Protoytpe Posts
"Seeking enlightenment on CGI::Prototype"
<http://perlmonks.org/?node_id=442480>
"Mixins (problem with CGI::Prototype and Class::Protototyped with subtemplates)"
<http://perlmonks.org/?node_id=439974>
"Trying to understand how CGI::Prototype::Hidden, Template Toolkit and CGI.pm work together."
<http://perlmonks.org/?node_id=438026>
"CGI::Prototype - let me clarify the response phase for you"
<http://perlmonks.org/?node_id=428222>
"A CGI::Prototype respond() subroutine for Data::FormValidator users"
<http://perlmonks.org/?node_id=428151>
"CGI::Prototype and use base"
<http://perlmonks.org/?node_id=426381>
"CGI::Prototype: questions and feedback"
<http://perlmonks.org/?node_id=426162>
"Basic CGI::Prototype::Hidden"
<http://perlmonks.org/?node_id=423071>
"Try CGI::Prototype"
<http://perlmonks.org/?node_id=410803>
"Review: CGI::Prototype"
<http://perlmonks.org/?node_id=411760>
AUTHOR
Terrence Brannon, <terry@>
COPYRIGHT AND LICENSE
Copyright (C) 2005 by Terrence Brannon
This library is free software; you can redistribute it and/or modify it
under the same terms as Perl itself, either Perl version 5.8.4 or, at
your option, any later version of Perl 5 you may have available.
--
Carter's Compass: I know I'm on the right track when,
by deleting something, I'm adding functionality.
|
|
From: Terrence B. <ba...@me...> - 2005-04-08 09:22:01
|
"aw-...@eb..." <aw-...@eb...> writes: > <TABLE cellSpacing=0 cellPadding=0 width=600 border=0> I'm sorry, but sourceforge had "Restrict posting privilege to list members? (member_posting_only)" set to "No" by default. I have switched it so that only list-members can post. |
|
From: <me...@st...> - 2005-04-07 14:12:21
|
My $client wanted to upgrade CGIP, but because the new version of Mecha
requires a newer version of LWP, and $client didn't want to upgrade LWP,
I split Mecha out as a separate distro.
You need CGIP to use Mecha. You need Mecha to *fully test* CGIP, but
the tests are marked as optional. Thus, this should permit non-Mecha
users an installation path.
Frankly, I think Mecha rocks. I get to write tests that step through
the app like I would with Mechanize, and then talk directly to the
database in the same process to see what the results are.
Here's a snippet from a $client test:
ok $m->submit_form
(fields =>
{managers => "test1\ntest2",
members => "test3\ntest4\ntest5",
},
button => 'update alias',
), 'populate initial list';
ok $m->success, "fetched manage alias page" or $m->diag_response;
## verify database is in proper state
{
is my ($a) = Alias::DB::Alias->search(name => 'one-test'),
1, 'found one alias named one-test';
is my @managers = $a->managers, 2, '2 managers found';
is_deeply
[sort map { $_->ubit } @managers],
[sort qw(test1 test2)],
'managers ubits are OK';
is my @members = $a->memberships, 3, '3 members found';
is_deeply
[sort map { $_->email } @members],
[sort qw(test3 test4 test5)],
'members email are OK';
}
So, I'm poking at the application through the "web", then
immediately accessing the database through Class::DBI calls
to ensure that the web changes are reflected correctly.
Then I use these with Devel::Cover, and I can see if my web-based
use-cases are actually touching the amount of code I had hoped.
CGIP with CGIP-Mecha. Great combo.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@st...> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
|
|
From: Terrence B. <ba...@me...> - 2005-04-03 19:54:35
|
I want to create an information file for CGI::Prototype called
CGI::Prototype::Info and upload it to CPAN. I want to have the
following sections:
=head1 Perlmonks CGI::Protoytpe Posts
=head1 Other Links
Introduction to CGI::Prototype
http://www.ourmedia.org/node/1644
the Linux Journal Article
=head1 The Mailing List
So is it OK to upload such a file? The Perlmonks links are already
mined and listed below.
=head1 Perlmonks CGI::Protoytpe Posts
=over
=item * Seeking enlightenment on CGI::Prototype
L<http://perlmonks.org/?node_id=442480>
=item * Mixins (problem with CGI::Prototype and Class::Protototyped with subtemplates)
L<http://perlmonks.org/?node_id=439974>
=item * Trying to understand how CGI::Prototype::Hidden,
Template Toolkit and CGI.pm work together.
L<http://perlmonks.org/?node_id=438026>
=item * CGI::Prototype - let me clarify the response phase for you
L<http://perlmonks.org/?node_id=428222>
=item * A CGI::Prototype respond() subroutine for
Data::FormValidator users
L<http://perlmonks.org/?node_id=428151>
=item * CGI::Prototype and use base
L<http://perlmonks.org/?node_id=426381>
=item * CGI::Prototype: questions and feedback
L<http://perlmonks.org/?node_id=426162>
=item * basic CGI::Prototype::Hidden
L<http://perlmonks.org/?node_id=423071>
=item * Try CGI::Prototype
L<http://perlmonks.org/?node_id=410803>
=item * Review: CGI::Prototype
L<http://perlmonks.org/?node_id=411760>
=back
|
|
From: Randal L. S. <me...@st...> - 2005-04-03 15:02:46
|
Terrence Brannon <bauhaus <at> metaperl.com> writes: > > package Message::Primer; > > use CGI::Prototype; > > __PACKAGE__->reflect->activate; Ugh. That should be __PACKAGE__->activate. activate is protocol, not meta-protocol! |
|
From: Terrence B. <ba...@me...> - 2005-04-03 11:53:16
|
package Message::Primer; use CGI::Prototype; __PACKAGE__->reflect->activate; 1; # Welcome! |
1 message has been excluded from this view by a project administrator.
