CGI::App - creating your own overloaded functions

[Brad Van Sickle-2]

I find myself duplicating a lot of postrun code, so I'd like to move
that entire function up to a superclass file to centralize it.
My problem with doing that is that at I still have some logical
constructs that I need to set somewhere in each modules that are
module/runmode dependent.
For example:  Javascript includes.  I have several JS include files that
differ from between modules, and even between runmodes within the same
module.  So I need some place to build these include strings in each
module that has access get_current_runnmode.
As I understand it, I can't reliably ell what runmode I'm in until
pre-run, so using setup is out.   So I'm attempting to take a concept
I've read  about for doing something similar in init in the Order of
Operations document (http://cgi-app.org/index.cgi?OrderOfOperations -
Solution #2) and apply it to postrun. /

/"In your Super Class module create a function that looks like:

sub app_module_init
{
my $self = shift;/
/# Nothing to init, yet/
}/ /

Then from the cgiapp_init() method in your Super Class module, make a
call to this new app_module_init() function. Since it's currently empty
it won't do anything, however, if you create an app_module_init()
function within your Application module it will overload the one from
your Super Class. It will now get called whenever cgiapp_init is called
in the Super Class. If a particular Application module doesn't have an
app_module_init() method in it, no harm done, the default empty one is
called in its place."/

So what I've done is created a module in my superclass:*
*sub app_module_define_JS*
*    {*
*    my $self = shift;*
*    return;*
   }*
I then call that module at the start of post run*
my $JSIncludes=&app_module_define_JS;*

As I understand it, if I put an app_module_define_JS sub in a module,
that function will be overloaded and the code in the module will execute
instead of the code in superclass.  This doesn't happen.  The code in
superclass always executes.

Can someone explain why?


#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################

[Rhesa Rozendaal-2]

Brad Van Sickle wrote:
> I find myself duplicating a lot of postrun code, so I'd like to move
> that entire function up to a superclass file to centralize it.
> My problem with doing that is that at I still have some logical
> constructs that I need to set somewhere in each modules that are
> module/runmode dependent.

[snip]

> So what I've done is created a module in my superclass:*
> *sub app_module_define_JS*
> *    {*
> *    my $self = shift;*
> *    return;*
>    }*
> I then call that module at the start of post run*
> my $JSIncludes=&app_module_define_JS;*

That should be:

   my $js = $self->app_module_define_JS;

otherwise it isn't OO. &foo is the sub defined in the current package, so
you're disabling method dispatch.

HTH,
rhesa

#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################

[Brad Van Sickle-2]

That did it.  One of those things that's obvious once it's pointed out.

 Thanks!

Rhesa Rozendaal wrote:

> Brad Van Sickle wrote:
>> I find myself duplicating a lot of postrun code, so I'd like to move
>> that entire function up to a superclass file to centralize it.
>> My problem with doing that is that at I still have some logical
>> constructs that I need to set somewhere in each modules that are
>> module/runmode dependent.
>
> [snip]
>
>> So what I've done is created a module in my superclass:*
>> *sub app_module_define_JS*
>> *    {*
>> *    my $self = shift;*
>> *    return;*
>>    }*
>> I then call that module at the start of post run*
>> my $JSIncludes=&app_module_define_JS;*
>
> That should be:
>
>   my $js = $self->app_module_define_JS;
>
> otherwise it isn't OO. &foo is the sub defined in the current package,
> so you're disabling method dispatch.
>
> HTH,
> rhesa
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>

#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################

[Ron Savage]

Hi Brad

On Tue, 2009-08-25 at 12:17 -0400, Brad Van Sickle wrote:
[snip]
> For example:  Javascript includes.  I have several JS include files that
> differ from between modules, and even between runmodes within the same
> module.  So I need some place to build these include strings in each
> module that has access get_current_runnmode.

I looked at run-mode specific JS, and decided: Just Don't Do It!

I adopted a JS library (YUI), and now send all required JS down to the
client in the very first response. Thereafter I use Ajax.

The consequences are that the first page load seems a bit slow for the
user (maybe 300Kb), but that's not really all that much these days.

The big gain of course is that /all/ subsequent responses are lightning
fast, since only data is sent.

The other factor is that any JS feature can be used on any 'page', since
the code has already been sent to the client. And if it hasn't, then the
first page has to be re-done. But that's a tiny issue, and hence the
ongoing maintenance problem of matching JS file to page is thereby
eliminated.

[1] http://developer.yahoo.com/yui/


--
Ron Savage
ron@...
http://savage.net.au/index.html



#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################

[CosmicPerl]

Ron Savage wrote:
> I adopted a JS library (YUI), and now send all required JS down to the
> client in the very first response. Thereafter I use Ajax.
>
> The consequences are that the first page load seems a bit slow for the
> user (maybe 300Kb), but that's not really all that much these days.
>  

Sounds like some form of compression would be worth while.

With a quick google this looks interesting:-
http://demo.java2script.org/lz77js/

Lyle


#####  CGI::Application community mailing list  ################
##                                                            ##
##  To unsubscribe, or change your message delivery options,  ##
##  visit:  http://www.erlbaum.net/mailman/listinfo/cgiapp    ##
##                                                            ##
##  Web archive:   http://www.erlbaum.net/pipermail/cgiapp/   ##
##  Wiki:          http://cgiapp.erlbaum.net/                 ##
##                                                            ##
################################################################