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

On 7/1/05 1:24 PM, "Terrence Brannon" <[EMAIL PROTECTED]> wrote:

> Andrew Gianni <[EMAIL PROTECTED]> writes:
> 
>>  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
> cgi-prototype-users@lists.sourceforge.net
> 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



-------------------------------------------------------
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
cgi-prototype-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users

Reply via email to