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: <me...@st...> - 2009-08-30 23:16:14
|
>>>>> "Terrence" == Terrence Brannon <met...@gm...> writes: Terrence> I dont want to fork and start a separate distro, just add Terrence> CGI::Prototype::Moose to the CGIP distro. And I'm saying that's the wrong name for that, if it's not about replacing all of what CGIP already does, including prototype inheritance. Feel free to release it as CGI::Moose or something. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
|
From: Terrence B. <met...@gm...> - 2009-08-30 23:02:22
|
Randal L. Schwartz wrote: > The heir apparent to the CGI::Prototype namespace should support > Class::Prototype-styled objects. Right. I'm not suggesting an heir apparent. I'm suggesting an additional module in the distribution, along with associated test suite. This module would extend on the other concept of "CGI Prototype" - prototyping the CGI process. Not using CGI with prototyped objects. Also, people tend to look down on modules whose release date is more than 6 months old. It starts to look unmaintained. I dont want to fork and start a separate distro, just add CGI::Prototype::Moose to the CGIP distro. > I have customers that are making use of the > Class::Prototyped features that are not classical class-instance structures, > so any "replacement" of CGIP with something new must be carefully considered. > > right and a toy example exemplifying the need for non classical class-instance structures in the standard docs or a magazine article would help greatly. I did talk to Jason Purdy above his negative CPAN ratings review of CGIP <http://cpanratings.perl.org/dist/CGI-Prototype>. He wrote his 'review' after skimming the docs. Now, I dont think that what he did was fair or thoroughly researched, but I think a section in the docs like "Why Another Framework" or "How is CGIP Different" would go a long way towards stamping out superficial inspection of the module. |
|
From: <me...@st...> - 2009-08-30 22:46:50
|
The heir apparent to the CGI::Prototype namespace should support Class::Prototype-styled objects. Under the licensing terms of CGIP, you're free to derive whatever you want and call it whatever you want, but please reserve CGI::Prototype (or names close to it) for something that supports prototype-inheritance objects. I have customers that are making use of the Class::Prototyped features that are not classical class-instance structures, so any "replacement" of CGIP with something new must be carefully considered. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
|
From: Terrence B. <sch...@gm...> - 2009-08-30 22:41:29
|
Randal L. Schwartz wrote:
> Not really. The prototype stuff of Moose is where you want to start, and it
> has a different interface. If you just pulled in Class::Prototyped, you'd
> have a lot of potential conflicts, especially around anonymous classes.
>
>
I see. I'm not trying to anger you, but I would like to re-join our IRC
conversation. If you read the CGIP docs, it speaks of 'the prototypical
cgi application' -
* Analyze the incoming parameters, cookies, and URLs to determine
the state of the application (let's call this "dispatch").
* Based on the current state, analyze the incoming parameters to
respond to any form submitted ("respond").
* From there, decide what response page should be generated, and
produce it ("render").
And while this core exists in all Perl CGI modules, my experience is
that the controller of CGIP has captured it best. It prototypes the CGI
response cycle quite well.
On the other hand, I've never had a need for prototyped objects when
using CGIP - all my usage has basically been class-based and standard OO
and I've been pleased with the results.
.
I'd like to petition for a distinct module in the CGIP distro which uses
plain moose
<http://github.com/metaperl/perl-module-cgi-prototype/tree/master>.
If someone wants to implement something like that protomoose.t, then
that could be another module.
Further, I think CGIP would have been better received by the community
if the articles had pointed out exactly what prototype objects offer the
CGI application development process. Nothing I've seen in the standard
CGIP docs or Linux Magazine article
<http://www.stonehenge.com/merlyn/LinuxMag/col56.html> points to
something I could not do easily and cleanly with standard Moose (or
plain Perl) classes.
For instance my recent perlmonks praise of CGIP
<http://www.perlmonks.org/?node_id=786745> showed an example. But that
example benefitted from the controller cycle and standard OO dispatch.
|
|
From: <me...@st...> - 2009-08-23 19:18:58
|
>>>>> "Terrence" == Terrence Brannon <met...@gm...> writes: Terrence> Randal wants to maintain prototype-based OOP for a Moose-based version Terrence> of CGI::Prototype. I'm wondering if such a Moose class could be as Terrence> simple as: Terrence> package CGI::Prototype::Moose; Terrence> use Moose; Terrence> extends 'Class::Prototyped'; Not really. The prototype stuff of Moose is where you want to start, and it has a different interface. If you just pulled in Class::Prototyped, you'd have a lot of potential conflicts, especially around anonymous classes. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
|
From: Terrence B. <met...@gm...> - 2009-08-23 19:03:38
|
Randal wants to maintain prototype-based OOP for a Moose-based version of CGI::Prototype. I'm wondering if such a Moose class could be as simple as: package CGI::Prototype::Moose; use Moose; extends 'Class::Prototyped'; ... 1; Links: ------ * There is a sample prototype OO moose in this test example: http://github.com/nothingmuch/moose/blob/0bb2cc8a6a2e4b967b5d8efbcf1ab27f5d95e990/t/200_examples/006_example_Protomoose.t but I dont fancy breaking with the Class::Prototyped API. * My current fork of CGI::Prototype which uses Moose: http://github.com/metaperl/perl-module-cgi-prototype/blob/f3c71299cd98de7b4c4d2b291d95623a761db548/lib/CGI/Prototype/Moose.pm |
|
From: <me...@st...> - 2009-08-07 15:55:56
|
>>>>> "Terrence" == Terrence Brannon <sch...@gm...> writes: Terrence> I'm a github fan and would like to put up a repo for CGIP ASAP. You can just fork mine. CGIP is already on github. http://github.com/RandalSchwartz/perl-module-cgi-prototype/tree/master -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion |
|
From: Terrence B. <sch...@gm...> - 2009-08-07 15:13:18
|
Merlyn is pretty much following other paths in CGI development <http://perlmonks.org/?node_id=786745> I personally am interested in a Moose upgrade of CGI::Prototype. There are a lot of articles out on CGI::Prototype so I think we should simply augment the current distro. I'm a github fan and would like to put up a repo for CGIP ASAP. |
|
From: <me...@st...> - 2007-10-25 14:55:27
|
>>>>> "Harald" == Harald Joerg <har...@fu...> writes: Harald> That's what I like with CGIPH: The code is so slim that it is pretty Harald> easy to understand, hence rather riskless to overload, and TIMTOWTDI! Thanks! That was the point. Do just the basics. Don't go nutty. Add things as you see fit when they are common to *all* apps. -- 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: Andrew G. <ag...@bu...> - 2007-10-25 14:49:49
|
On 10/25/07 10:32 AM, "Harald Joerg" <har...@fu...>
wrote:
> Writing an extra mantra $self->name_to_page() dozens of times (in
> every respond, every module) is sightly annoying and gives me the
> impression of a decentralized workaround.
Actually, I just look at it as useful refactoring. We actually have
situations in some of our applications where we cross over application
classes between respond and render; i.e. The response of App1::page_x may
want to return App2::page_y at times. So simply passing the name of the page
isn't enough, we really need to return a page object with an explicit full
class name. It definitely makes sense to localize the functionality you
need, but rolling that up into CGI::Prototype would make it less flexible.
> If I write another application, which may be not before next year, I
> am sure to stubmle over that again. It is not in the Linux Mag
> examples, not easily collected from the PODs, and not in my own
> mod_perl apps.
Better documentation would make this easier to understand. I reckon Randal
has written enough of the basic stuff and its up to us as a community to put
together some more in-depth tutorials. That said, I'm not exactly swimming
with spare time :) Maybe come late December early January (winter break)
I'll have some time to work on something collaboratively. Perhaps a CGIP
wiki would be a good option.
Andrew
--
Andrew Gianni - Lead Programmer Analyst
Administrative Computing Services / Computing and Information Technology
University at Buffalo, State University of New York
215 Millard Fillmore Academic Complex, Buffalo, NY 14261-0026
716.645.5332 - AIM: andrewsgianni - http://www.newkenmore.com/agianni
|
|
From: Harald J. <har...@fu...> - 2007-10-25 14:33:01
|
Andrew Gianni <ag...@bu...> writes:
> On 10/25/07 5:31 AM, "Harald Joerg" <har...@fu...>
> wrote:
>
>> sub respond {
>> # ...du whatever needs to be done in response to the user's request
>> return 'NextPage';
>> }
>
> Try:
>
> sub respond {
> my $self = shift;
> return $self->name_to_page('NextPage');
> }
>
> Or is there some specific reason that you want to just return a string
> instead of an object?
Yes, of course I could do that, and there is no specific reason other
than DWIM.
Writing an extra mantra $self->name_to_page() dozens of times (in
every respond, every module) is sightly annoying and gives me the
impression of a decentralized workaround.
If I write another application, which may be not before next year, I
am sure to stubmle over that again. It is not in the Linux Mag
examples, not easily collected from the PODs, and not in my own
mod_perl apps.
Currently I've flipped to overriding activate in My::App.pm., and
inserted the autoloading code immediately before the call to
$next_page->control_enter. For the moment, I like it that way :-)
That's what I like with CGIPH: The code is so slim that it is pretty
easy to understand, hence rather riskless to overload, and TIMTOWTDI!
--
Cheers,
haj
|
|
From: Andrew G. <ag...@bu...> - 2007-10-25 13:51:48
|
On 10/25/07 5:31 AM, "Harald Joerg" <har...@fu...>
wrote:
> sub respond {
> # ...du whatever needs to be done in response to the user's request
> return 'NextPage';
> }
Try:
sub respond {
my $self = shift;
return $self->name_to_page('NextPage');
}
Or is there some specific reason that you want to just return a string
instead of an object?
Andrew
--
Andrew Gianni - Lead Programmer Analyst
Administrative Computing Services / Computing and Information Technology
University at Buffalo, State University of New York
215 Millard Fillmore Academic Complex, Buffalo, NY 14261-0026
716.645.5332 - AIM: andrewsgianni - http://www.newkenmore.com/agianni
|
|
From: Harald J. <har...@fu...> - 2007-10-25 09:31:39
|
Yesterday I've encountered a case where CGIPH isn't as DWIM as it
could be. It had never hit me before, because usually I use mod_perl
and compile all stuff in the startup routine.
The docs of CGIPH state:
... The package for the class is autoloaded if needed.
This is true as long as the class is passed to dispatch via the _state
parameter, but doesn't hold between the steps. I believe that my use
case is quite typical: In my respond routines, I want to return a
"next page". But not as a page object, as the docs, if carefully
read, require. I'd rather follow the Linux Mag article and simply
return the *name* of the class:
sub respond {
# ...whatever needs to be done in response to the user's request
return 'My::App::NextPage';
}
or even DWIMmer, but different from what's implemented in CGIP and
documented in Linux Mag:
sub respond {
# ...du whatever needs to be done in response to the user's request
return 'NextPage';
}
However, this fails if My::App::NextPage hasn't already been compiled.
It dies when trying to execute My::App::NextPage::control_enter.
Both control_enter and its caller activate are inherited from CGIP,
which doesn't support autoloading, so it isn't just a one-liner in
CGIPH. Currently I'm using the following workaround in My::App:
sub respond {
my $self = shift;
my $package = $self->respond_per_app ||
$self->respond_per_page;
eval "require $package" unless (ref $package ||
eval "defined %${package}::");
die if $@;
return $package;
}
I am not completely happy with it since it prevents simple
applications to override respond (as in the Linux Mag example, which
admittedly refers to CGIP). I need to stick to respond_per_page
instead. Maybe it would be better to override activate in CGIPH and
do the autoloading immediately before $next_page->control_enter?
--
Cheers,
haj
|
|
From: Dotan D. <do...@co...> - 2007-08-19 17:09:29
|
Andrew Gianni wrote: > Dotan, are your mixins simply providing additional non-CGI::Prototype > functionality, i.e. not overriding core CGI::P methods? > > Yep. That's why my mixins are "Utils" rather than pages. If you could build an ordered chain of render_enter methods or whatever, the activate() method would probably be much simpler. When I want to hook some different functionality into a chain of execution, I have to override a different hook; this isn't particularly scalable, but for my simplistic app it works. |
|
From: Andrew G. <ag...@bu...> - 2007-08-16 18:53:38
|
On 8/16/07 1:32 PM, "Randal L. Schwartz" <me...@st...> wrote: >>>>>> "Andrew" == Andrew Gianni <ag...@bu...> writes: > > Andrew> Dotan, that looks like what I'm looking for and it's roughly what I > Andrew> had in mind although I didn't realize that a Class::Prototyped class > Andrew> could have multiple parents, which resolves the question of multiple > Andrew> mixins. How are they evaluated for execution? For example, if you > Andrew> override render_enter in Miner::Utils::Links and Miner::Utils::Text, > Andrew> will it just execute both of their render_enter methods in sequence in > Andrew> the order you added their parent slot in the foreach loop of > Andrew> install_mixins? > > No, it picks "first found", which actually makes mixins a bit of pain. That's > why there's that particularly tricky code in that one project I did for you, > to essentially insert the "mixed-in" version in the middle of your inheritance > ladder, rather than hanging out on a second parent. Right, and that's actually what I'm looking for. In some cases, I need to insert an abstract page class between my app class and a concrete page class implementation. Sometimes, I need to insert an abstract class between my app class and CGI::P::H. After staring at your code for a while it makes sense, I just need to pick it up and move it somewhere more generally useful. Dotan, are your mixins simply providing additional non-CGI::Prototype functionality, i.e. not overriding core CGI::P methods? > It's one of the weakest parts of the Class::Prototyped design, unfortunately, > and having chosen that for CGIP, I'm sorta stuck with it. So the upshot is that the developer needs to be aware of what the mixins are doing and where there could be potential conflicts. As long as mixins call reflect->super we should be in relatively good shape, right? But there may be places where we don't always want to call super at all depending on the functionality, which may cause unexpected results. Does this mean that mixins probably won't be a good option for general CPAN modules, but only for local classes that the developer understands the internals of? Or should mixins only be restricted to core methods that *always* call super? Andrew -- Andrew Gianni - Lead Programmer Analyst University at Buffalo, State University of New York Computing and Information Technology / Administrative Computing Services 215 MFAC, Ellicott Complex, Buffalo, NY 14261-0026 716.645.5332 - AIM: andrewsgianni - http://www.newkenmore.com/agianni |
|
From: <me...@st...> - 2007-08-16 17:32:45
|
>>>>> "Andrew" == Andrew Gianni <ag...@bu...> writes: Andrew> Dotan, that looks like what I'm looking for and it's roughly what I Andrew> had in mind although I didn't realize that a Class::Prototyped class Andrew> could have multiple parents, which resolves the question of multiple Andrew> mixins. How are they evaluated for execution? For example, if you Andrew> override render_enter in Miner::Utils::Links and Miner::Utils::Text, Andrew> will it just execute both of their render_enter methods in sequence in Andrew> the order you added their parent slot in the foreach loop of Andrew> install_mixins? No, it picks "first found", which actually makes mixins a bit of pain. That's why there's that particularly tricky code in that one project I did for you, to essentially insert the "mixed-in" version in the middle of your inheritance ladder, rather than hanging out on a second parent. It's one of the weakest parts of the Class::Prototyped design, unfortunately, and having chosen that for CGIP, I'm sorta stuck with 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: Andrew G. <ag...@bu...> - 2007-08-16 17:28:33
|
Dotan, that looks like what I'm looking for and it's roughly what I had in
mind although I didn't realize that a Class::Prototyped class could have
multiple parents, which resolves the question of multiple mixins. How are
they evaluated for execution? For example, if you override render_enter in
Miner::Utils::Links and Miner::Utils::Text, will it just execute both of
their render_enter methods in sequence in the order you added their parent
slot in the foreach loop of install_mixins?
Andrew
On 8/16/07 12:44 PM, "Dotan Dimet" <do...@co...> wrote:
> Hi Andrew,
>
> CGI::Prototype as a framework is something of a bit of string lashed
> around a set of power tools.
>
> These tools can do anything you need, but the "framework" provides no
> guidance about how to do it, beyond the "with this" inherent in
> Randall's choice of tools.
>
> Instead of 'use base', I use the Class::Prototyped ability to install
> other classes into your object.
>
>
> In my base class (CGI::Prototype::Hidden subclass), I've got a method
> that installs my plugins:
>
>
> sub install_mixins {
>
> my ($self, @mixins) = @_;
> my $prefix = $self->mixins_prefix . '::';
> foreach my $pkg (@mixins) {
> $self->reflect->addSlot ( [ "$pkg*", 'PARENT' ] => $prefix . $pkg );
> my $plugin = $self->reflect->getSlot("$pkg*"); # the mixin we
> just installed
> }
> }
>
>
> The mixins_prefix is "configurable":
>
> sub mixins_prefix { return "Miner::Utils" }
>
>
> And I install my mixins in app_enter in the base class:
>
>
> sub app_enter {
> my ($self) = @_;
> # connect to the database:
> Foo::DBI::init($Config::Site::database_connect_string,
> $Config::Site::schema, $Config::Site::schema);
> # load all the Miner::Utils::* packages:
> $self->install_mixins(qw(Links Text Cookie Exec Log Order TimeField
> LOB ));
> }
>
>
> If I want to use a particular mixin only in one or more specific pages,
> I call install_mixins in their control_enter or respond_enter methods.
>
>
> My plugin/mixin classes (like Miner::Utils::Cookie, for example) are
> CGI::Prototype::Hidden subclasses, although I could probably make them
> Class::Prototyped subclasses, or independent modules.
>
>
> The advantage of calling install_mixins in the app_enter is that things
> like the CGI object and the database connection are already set up, so I
> can install classes that mess about with things like the database
> session, like Class::DBI::Plugin::DateFormat::Oracle for example.
>
>
> Hope this helps,
>
>
> - Dotan.
>
>
>
>
> Andrew Gianni wrote:
>
>> I'd like to figure out how to get mixins up and running under
>> CGI::Prototype. I think I understand the technical aspects of
>> Class::Prototyped well enough to pull it off, but I have design questions
>> that I'd like feedback on. Assuming all goes well, I'd be happy to
>> contribute a CGI::Prototype::Mixin module to CPAN if I can get it that
>> generalized. Let me start with three scenarios I'd like to be able to
>> address and the issues I see:
>>
>> 1. We have at least two applications that have pages that allow users to
>> upload files. The page is pretty similar in both applications with only a
>> few application specific things, like the table it's using and an extra
>> field. What I'd like to do is create an abstract page class for the file
>> upload page and then implement it with concrete page classes within the
>> applications themselves, overriding necessary methods to customize. I have
>> actually done this in the past by not giving the abstract class a base class
>> and using multiple inheritance in the concrete class like so:
>>
>> use base qw( Abstract::Page::Class My::App );
>>
>> And that mostly works, but I'm knew that it could cause problems down the
>> line and after only a few months I found a scenario where it breaks: under
>> mod_perl, if I use the mixin page for more than one concrete page class in
>> my application and use Apache::Reload to reload the concrete page classes, I
>> get errors with whichever concrete page class is reloaded second. I don't
>> remember exactly what the error is, but I can look into it if anyone is
>> interested. Cracking plugability for this example is most important for me
>> because we actually have two more page types that we need to be able to do
>> this with and right now they're just duplicated in multiple projects.
>>
>> 2. I would like to create a pluggable diagnostics module that I could stick
>> in front of my app module to override core CGI::P methods at strategic
>> locations to capture performance data.
>>
>> 3. We currently have two different validation methodologies and I'm not sure
>> how soon we'll be picking one or the other to standardize on. I'd like to
>> create two separate mixin classes so I can choose the validation
>> functionality to use. I know I could make this work with something like a
>> Strategy pattern, defining two different validation classes with the same
>> interface and telling the app which one to use, but if I can get the first
>> two examples working, this could easily come along for the ride.
>>
>> The basics of this from a technical perspective should be pretty straight
>> forward, right? I just need to take the mixin class and manipulate it's
>> parent and the parent of the class that I want to inherit from it, right?
>>
>> The complicated part, and perhaps this doesn't have an easy answer, is what
>> it I want to insert more than one mixin? What if, for example,
>> CGI::Prototype::Hidden became a mixin, as Randal proposed some time ago (did
>> I understand that correctly?) and I also have an authentication mixin I'd
>> like to use. The problem is that, as a developer, I know the interfaces of
>> the two mixins and what they do, but I don't want to have to look at the
>> internals of each one to know if I need to put CGI::Prototype::Hidden
>> infront of CGI::Prototype::Mixin::Auth or vice versa. Is this actually a
>> connundrum or am I overanalyzing this? Any feedback or ideas would be
>> appreciated.
>>
>> Andrew
>>
>>
>
--
Andrew Gianni - Lead Programmer Analyst
University at Buffalo, State University of New York
Computing and Information Technology / Administrative Computing Services
215 MFAC, Ellicott Complex, Buffalo, NY 14261-0026
716.645.5332 - AIM: andrewsgianni - http://www.newkenmore.com/agianni
|
|
From: Dotan D. <do...@co...> - 2007-08-16 16:45:59
|
Hi Andrew,
CGI::Prototype as a framework is something of a bit of string lashed
around a set of power tools.
These tools can do anything you need, but the "framework" provides no
guidance about how to do it, beyond the "with this" inherent in
Randall's choice of tools.
Instead of 'use base', I use the Class::Prototyped ability to install
other classes into your object.
In my base class (CGI::Prototype::Hidden subclass), I've got a method
that installs my plugins:
sub install_mixins {
my ($self, @mixins) = @_;
my $prefix = $self->mixins_prefix . '::';
foreach my $pkg (@mixins) {
$self->reflect->addSlot ( [ "$pkg*", 'PARENT' ] => $prefix . $pkg );
my $plugin = $self->reflect->getSlot("$pkg*"); # the mixin we
just installed
}
}
The mixins_prefix is "configurable":
sub mixins_prefix { return "Miner::Utils" }
And I install my mixins in app_enter in the base class:
sub app_enter {
my ($self) = @_;
# connect to the database:
Foo::DBI::init($Config::Site::database_connect_string,
$Config::Site::schema, $Config::Site::schema);
# load all the Miner::Utils::* packages:
$self->install_mixins(qw(Links Text Cookie Exec Log Order TimeField
LOB ));
}
If I want to use a particular mixin only in one or more specific pages,
I call install_mixins in their control_enter or respond_enter methods.
My plugin/mixin classes (like Miner::Utils::Cookie, for example) are
CGI::Prototype::Hidden subclasses, although I could probably make them
Class::Prototyped subclasses, or independent modules.
The advantage of calling install_mixins in the app_enter is that things
like the CGI object and the database connection are already set up, so I
can install classes that mess about with things like the database
session, like Class::DBI::Plugin::DateFormat::Oracle for example.
Hope this helps,
- Dotan.
Andrew Gianni wrote:
> I'd like to figure out how to get mixins up and running under
> CGI::Prototype. I think I understand the technical aspects of
> Class::Prototyped well enough to pull it off, but I have design questions
> that I'd like feedback on. Assuming all goes well, I'd be happy to
> contribute a CGI::Prototype::Mixin module to CPAN if I can get it that
> generalized. Let me start with three scenarios I'd like to be able to
> address and the issues I see:
>
> 1. We have at least two applications that have pages that allow users to
> upload files. The page is pretty similar in both applications with only a
> few application specific things, like the table it's using and an extra
> field. What I'd like to do is create an abstract page class for the file
> upload page and then implement it with concrete page classes within the
> applications themselves, overriding necessary methods to customize. I have
> actually done this in the past by not giving the abstract class a base class
> and using multiple inheritance in the concrete class like so:
>
> use base qw( Abstract::Page::Class My::App );
>
> And that mostly works, but I'm knew that it could cause problems down the
> line and after only a few months I found a scenario where it breaks: under
> mod_perl, if I use the mixin page for more than one concrete page class in
> my application and use Apache::Reload to reload the concrete page classes, I
> get errors with whichever concrete page class is reloaded second. I don't
> remember exactly what the error is, but I can look into it if anyone is
> interested. Cracking plugability for this example is most important for me
> because we actually have two more page types that we need to be able to do
> this with and right now they're just duplicated in multiple projects.
>
> 2. I would like to create a pluggable diagnostics module that I could stick
> in front of my app module to override core CGI::P methods at strategic
> locations to capture performance data.
>
> 3. We currently have two different validation methodologies and I'm not sure
> how soon we'll be picking one or the other to standardize on. I'd like to
> create two separate mixin classes so I can choose the validation
> functionality to use. I know I could make this work with something like a
> Strategy pattern, defining two different validation classes with the same
> interface and telling the app which one to use, but if I can get the first
> two examples working, this could easily come along for the ride.
>
> The basics of this from a technical perspective should be pretty straight
> forward, right? I just need to take the mixin class and manipulate it's
> parent and the parent of the class that I want to inherit from it, right?
>
> The complicated part, and perhaps this doesn't have an easy answer, is what
> it I want to insert more than one mixin? What if, for example,
> CGI::Prototype::Hidden became a mixin, as Randal proposed some time ago (did
> I understand that correctly?) and I also have an authentication mixin I'd
> like to use. The problem is that, as a developer, I know the interfaces of
> the two mixins and what they do, but I don't want to have to look at the
> internals of each one to know if I need to put CGI::Prototype::Hidden
> infront of CGI::Prototype::Mixin::Auth or vice versa. Is this actually a
> connundrum or am I overanalyzing this? Any feedback or ideas would be
> appreciated.
>
> Andrew
>
>
|
|
From: Andrew G. <ag...@bu...> - 2007-08-16 14:34:44
|
I'd like to figure out how to get mixins up and running under CGI::Prototype. I think I understand the technical aspects of Class::Prototyped well enough to pull it off, but I have design questions that I'd like feedback on. Assuming all goes well, I'd be happy to contribute a CGI::Prototype::Mixin module to CPAN if I can get it that generalized. Let me start with three scenarios I'd like to be able to address and the issues I see: 1. We have at least two applications that have pages that allow users to upload files. The page is pretty similar in both applications with only a few application specific things, like the table it's using and an extra field. What I'd like to do is create an abstract page class for the file upload page and then implement it with concrete page classes within the applications themselves, overriding necessary methods to customize. I have actually done this in the past by not giving the abstract class a base class and using multiple inheritance in the concrete class like so: use base qw( Abstract::Page::Class My::App ); And that mostly works, but I'm knew that it could cause problems down the line and after only a few months I found a scenario where it breaks: under mod_perl, if I use the mixin page for more than one concrete page class in my application and use Apache::Reload to reload the concrete page classes, I get errors with whichever concrete page class is reloaded second. I don't remember exactly what the error is, but I can look into it if anyone is interested. Cracking plugability for this example is most important for me because we actually have two more page types that we need to be able to do this with and right now they're just duplicated in multiple projects. 2. I would like to create a pluggable diagnostics module that I could stick in front of my app module to override core CGI::P methods at strategic locations to capture performance data. 3. We currently have two different validation methodologies and I'm not sure how soon we'll be picking one or the other to standardize on. I'd like to create two separate mixin classes so I can choose the validation functionality to use. I know I could make this work with something like a Strategy pattern, defining two different validation classes with the same interface and telling the app which one to use, but if I can get the first two examples working, this could easily come along for the ride. The basics of this from a technical perspective should be pretty straight forward, right? I just need to take the mixin class and manipulate it's parent and the parent of the class that I want to inherit from it, right? The complicated part, and perhaps this doesn't have an easy answer, is what it I want to insert more than one mixin? What if, for example, CGI::Prototype::Hidden became a mixin, as Randal proposed some time ago (did I understand that correctly?) and I also have an authentication mixin I'd like to use. The problem is that, as a developer, I know the interfaces of the two mixins and what they do, but I don't want to have to look at the internals of each one to know if I need to put CGI::Prototype::Hidden infront of CGI::Prototype::Mixin::Auth or vice versa. Is this actually a connundrum or am I overanalyzing this? Any feedback or ideas would be appreciated. Andrew -- Andrew Gianni - Lead Programmer Analyst University at Buffalo, State University of New York Computing and Information Technology / Administrative Computing Services 215 MFAC, Ellicott Complex, Buffalo, NY 14261-0026 716.645.5332 - AIM: andrewsgianni - http://www.newkenmore.com/agianni |
|
From: <me...@st...> - 2006-09-07 14:23:26
|
>>>>> "Tom" == Tom Adamo <ta...@bu...> writes: Tom> One idea I had was that the interstitial method could check the result of Tom> the given action, and if there is a result, return it. That way my action Tom> could return a page object and I could send the user to any page I want. That's a great idea. Might be enough for me to incorporate and get a new release out as well (I've got a couple of minor buggy things that I'm saving up too). -- 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: Tom A. <ta...@bu...> - 2006-09-05 14:27:44
|
I've been playing around with the interstitial method a bit and it's working
well for me. But, I've run into an issue where I need to bust out of the
steps. Has any thought been given on how to do this?
For example:
my $p = $self->interstitial(
{ message => "Doing 1st thing...",
action => sub {
$self->do_first_thing();
},
},
{ message => "Doing 2nd thing...",
action => sub {
### Something goes wrong here ....
$self->do_second_thing();
},
},
{ message => "Doing 3rd thing...",
action => sub {
$self->do_third_thing();
},
},
);
return $p if $p;
If something goes on it step 2 and I don't want to proceed to step 3, how do
I do that?
One idea I had was that the interstitial method could check the result of
the given action, and if there is a result, return it. That way my action
could return a page object and I could send the user to any page I want.
For example:
change:
if ($step >= 1 and $step <= @steps) { # we got work to do
if (defined (my $code = $steps[$step - 1]{action})) {
$code->(); # run the action
}
}
to:
if ( $step >= 1 and $step <= @steps ) { # we got work to do
if ( defined( my $code = $steps[ $step - 1 ]{action} ) ) {
my $action_result = $code->(); # run the action
if ($action_result) {
$self->CGI->delete($cip);
return $action_result;
}
}
}
Any thoughts on this?
Thanks for the help!
--
Tom Adamo
|
|
From: <me...@st...> - 2006-08-09 16:36:11
|
>>>>> "Robert" == Robert Hicks <si...@gm...> writes: Robert> What is your definition of "soon". :-) Within 6 months of Christmas! In reality, I've been swamped since the first of the year, between a $major_client requiring me to be onsite in Burbank CA, and all the conferences I regularly attend. I hope to get back to CGIP sometime soon with some updates that I've realized as I adapt the code for my clients. -- 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: Robert H. <si...@gm...> - 2006-07-24 20:24:30
|
Randal L. Schwartz wrote: > Just to bring the listeners up to date... > > The two big projects my clients are requesting with regard to > CGI::Prototype are: > > 1) refactoring CGIP to be more of a plugin architecture, with complete > backward compatibility > 2) Adding AJAX > > Yeah, that's right... I'm in the midst of a project that will plug > prototype.js (and probably scriptaliscious) into a CGIP framework. > Once I have this in place, the oft-rumored "CGIP cookbook" will show > how to make web 2.0 apps easily with CGIP. Wheee. > > More soon. > What is your definition of "soon". :-) Robert |
|
From: <me...@st...> - 2006-05-12 01:47:05
|
>>>>> "A" == A Pagaltzis <pag...@gm...> writes: A> Hi all, A> a while ago, Sourceforge began offering Subversion for version A> control, in addition to CVS. They offer an option for older A> projects to migrate their repositories from CVS to Subversion A> in-place. A> Should we do this for the CGIP repository? Absolutely. If you have a commit bit, go ahead. Otherwise, when I get to it (hopefully this weekend), I'll do it myself. -- 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: A. P. <pag...@gm...> - 2006-05-12 01:30:19
|
Hi all, a while ago, Sourceforge began offering Subversion for version control, in addition to CVS. They offer an option for older projects to migrate their repositories from CVS to Subversion in-place. Should we do this for the CGIP repository? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> |
1 message has been excluded from this view by a project administrator.
