Yes there is: Table-driven programming.

For example, have several different sub-components that each do all of the input processing and HTML generation for a single page, then build a big lookup table (hash) that stores each sub-component name, then have the appropriate sub-component called using some query string parameter you embed in each form. In this example, I use the "op" parameter to tell us what operation (page) we're going to execute, then go look it up in the table, and if it exists, we execute it:

my %sub_components = (
    default_page     => 'defaultpage.comp'
    full_text_search => 'fulltextsearch.comp',
    filename_search  => 'filenamesearch.comp',
    view_alignment   => 'viewalignment.comp',
    add_folder       => 'addfolder.comp'
    ...
);

if ($op) {
    if (exists $sub_components{$op}) {
        # execute the appropriate sub-component:
        eval { $m->comp($sub_components{$op}, %ARGS) };

        if ($@) {
            # handle die() from the sub-component...
        }
    }
    else {
        # handle a request with "op" set to an invalid operation...
    }
}

...

<%args>
$op => 'default_page'
</%args>
[download]

Notice, you have to pass the query string arguments you received by hand to the sub-component you excute using %ARGS. (You have to do this *even* if the sub-components are all defined in the same file as the top-evel component.) Another option is caller_args(), but that's kind of hack-ish.

This is good plan.

Beyond that it reminds me a good bit of building a controller, from the classic Model-View-Controller Pattern. It doesn't look much like a mason controller though because it is bypassing all the normal name and handler based dispatching. Anyhow I was wonder if anyone had adapted the normal mason handling to be more MVC like, and through the glory of google I found that someone had.

Not that I'm suggesting anyone follow the example, merely marveling at it's existance.

How is "table-driven programming" any different than a simple dispatch table? How is your dispatch table any different than the framework that CGI::Application provides?

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

It's not my post, but I did recommend the strategy. I did so based on my belief that it basically is a dispatch table, and that you'd be rebuilding a bit of CGI::App.

CGI::App is a good module, but I wouldn't bringing it into a mason application, particularly for use on just one page. Sometimes rolling your own is the best solution, particularly when it's something as simple as a dispatch table.

On the general topic of refactoring (here's a good node: Refactoring) I like to start small. Find features that can be safely moved to their own components (or modules if they are all logic, no display). Move them. Test them. Repeat.

I find that things become easier when there is less code. This means the more code you move out, the more code you can move out. And at some point you are down to the point where you just need to clean up what you have left, and call it good.

Seems like you can think of components as methods. Not being familiar with Mason (I use template toolkit, which is an analogue), I suspect that just breaking things down into smaller components could vastly simplify things for you.

Factor out the 'logic' into components, and call the components. Sounds like a fairly straightforward task.

# all the args are accessed via %ARGS. so sometimes some of these values need initializing to a default value.

# some more messing around with args, and calling of sub components (you know, the ones that look like <% .download %>, or something like that. Its the weekend - i can't promise to have perfect syntax.)

# I have a .working_set component, (where the user saves data - this component updates, deletes, or empties these sets).

# Also I have a .download component that handles when the user wants to download, say, an Excel file. For some reason, I felt it necessary to keep those two within the scope of the page, rather than move them out into their own components.

# are they viewing Previous Search Results? - if so, use the mason cache.

# call a factory class that determines what action we are taking (search, alignment, etc.) and returns the appropriate object.

# prepare parameters to pass into this new object when we call the method prepare_results

#call the object method mentioned above.

# now, update the session with any altered values that happen as a result of calling the method.

# look at the results. call the appropriate component - check for error or warning message, and call that component if necessary.

#otherwise, call component assoc. with object.

# update session to have the last set of ARGS in case we have to go back.

# if the action was a search or genome search, save the search results in the mason cache.