Discussion:
[cgi-prototype-users] Using multiple base classes for an app
Andrew Gianni
2005-06-28 20:11:38 UTC
Permalink
I'm starting to run into situations where I have (or will soon have)
multiple applications that need to occasionally share pages, or at least
some functionality. I was thinking that a good way of doing this would be to
allow the config_class_prefix method (CGI::Prototype::Hidden) return an
array rather than just a scalar. That way, if I was working on project one,
instead of just:

sub config_class_prefix{
return 'Project1::App';
}

I'd like to be able to do something like this:

sub config_class_prefix{
return qw( Project1::App Project2::App );
}

Then I could call name_to_page or shortname on pages from either project.
Does this sound like a good idea, or can you suggest a better way to share
pages and functionality between applications?

Andrew
--
Andrew Gianni
Administrative Computing Services
State University of New York at Buffalo
215 Millard Fillmore Academic Complex
Amherst, NY 14261
(716) 645-3587x7124
Terrence Brannon
2005-07-01 17:24:54 UTC
Permalink
Post by Andrew Gianni
can you suggest a better way to share
pages and functionality between applications?
This is not a sarcastic response, but it is really what I think about
this situation. Sharing *functionality* should be the province of
vanilla Perl. Perl has a wealth of re-use/sharing mechanisms within
itself, with require and use being the most obvious ones...

It does not matter what one is doing in Perl - functionality re-use
occurs via subroutines and modules. I don't think that CGI/mod_perl
should be any different and for me, it is not. Neither Mason nor tt2
nor CGI::Prototype nor anything else can do a better job than vanilla
Perl at re-using *functionality*.

Now by re-using part of the display output (what you refer to as
"pages") depends critically on what you are doing to render HTML. For
me, as an HTML::Seamstress proponent, it would be a simple matter of
having the HTML somewhere it can be opened and processed and popped
inline in a larger document. But all the dynamic HTML toolkits have
means of re-using page data - tt2 has INCLUDE, WRAPPER (I think those
are right, I dont use tt2), and mason has components.

Cheers,
Terrence Brannon
Andrew Gianni
2005-07-01 20:44:11 UTC
Permalink
Shortly after posting this, I thought of another, simpler solution (perhaps
along the lines of what you are suggesting), which is a little more explicit
and maybe a little easier to understand and support. But I wanted to see if
I received any feedback before muddying the waters by answering my own
question.

It should be (theoretically) simple enough to create a page module for the
page that borrows functionality and simply add the module of the class I
need the functionality from to the use base statement, a la:

use base qw( Project2::App::borrowed_page Project1::App );

Then as long as I put hooks into my primary methods of
Project2::App::borrowed_page I can easily reuse and modify the
functionality.

That said, and I don't purport to be an OO expert, my understanding of
CGI::Prototype is that it is intended to be an OO framework, which means
that it inherently makes sharing functionality easier. In OO perl, this is
still just through the use of use base statements, and my proposal was to
augment the framework by having the module perform that use base for me
automagically.

Andrew
Post by Terrence Brannon
Post by Andrew Gianni
can you suggest a better way to share
pages and functionality between applications?
This is not a sarcastic response, but it is really what I think about
this situation. Sharing *functionality* should be the province of
vanilla Perl. Perl has a wealth of re-use/sharing mechanisms within
itself, with require and use being the most obvious ones...
It does not matter what one is doing in Perl - functionality re-use
occurs via subroutines and modules. I don't think that CGI/mod_perl
should be any different and for me, it is not. Neither Mason nor tt2
nor CGI::Prototype nor anything else can do a better job than vanilla
Perl at re-using *functionality*.
Now by re-using part of the display output (what you refer to as
"pages") depends critically on what you are doing to render HTML. For
me, as an HTML::Seamstress proponent, it would be a simple matter of
having the HTML somewhere it can be opened and processed and popped
inline in a larger document. But all the dynamic HTML toolkits have
means of re-using page data - tt2 has INCLUDE, WRAPPER (I think those
are right, I dont use tt2), and mason has components.
Cheers,
Terrence Brannon
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
cgi-prototype-users mailing list
https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
--
Andrew Gianni
Administrative Computing Services
State University of New York at Buffalo
215 Millard Fillmore Academic Complex
Amherst, NY 14261
(716) 645-3587x7124
Randal L. Schwartz
2005-08-15 16:31:25 UTC
Permalink
Andrew> I'd like to be able to do something like this:

Andrew> sub config_class_prefix{
Andrew> return qw( Project1::App Project2::App );
Andrew> }

Andrew> Then I could call name_to_page or shortname on pages from
Andrew> either project. Does this sound like a good idea, or can you
Andrew> suggest a better way to share pages and functionality between
Andrew> applications?

This would be handled with a local-policy ::Mapper::*, as I just described
in my previous message.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<***@stonehenge.com> <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!
Loading...