Mark Torrance wrote: > > I agree with Alex here. There are 2 cases where I prefer to use a > component returning a value, rather than moving the subroutine to a > module. > > 1. When I want to have the flexibility to override the component > implementation for a particular cobrand. In our work, we have an > extensive component root for the "base" site, and then have an > additional component root that includes overrides which are "cobrand- > specific" for particular specializations/clients that are customers > of our customer. Components that return values let us make special- > case versions of functions for a particular cobrand, without > reinventing the whole inheritance / overrides thing in our .pm > hierarchy too. > > 2. When I want to be able to work on a function, and get it right, > without restarting the webserver every time. It may be just me, but > I have not been able to get mod_perl to force recompliation of > changed .pm modules reliably, even in our dev environment. That > means that when we change code in modules, we have to restart the > webserver, but when we change code in Mason components we don't. > Obviously, this gives a big incentive to leave code in Mason modules, > at least during debugging.
In my experience there are two more cases: 3. When you need to (mason) cache the results of a function call and/or automatically supply parameters to the function based on the logged in user. An actual example we have of this is a function that retrieves a user's library information from a remote (to us) database. The result of this function is used in a number of places at varying levels of detail, but they all call the same component to get the raw data. We can trust that the caching will prevent excessive hits to the remote database and that all places will use the same cached data. 4. When you have what should be a function except that it is operating directly on user input. In a couple of applications we have a validate_input.comp that uses $m->request_args() to get the user input and then validate and/or manipulate it. At the end it returns a hashref of the data and an arrayref of errors. We do it this was as we consider processing the raw user input to be the responsibility of the interface, and all of the interface code is in mason. It could be argued that there could be a validate_input() function that is given $m->request_args() by the interface... Thanks, Stephen -- Stephen Edmonds Senior Portal Developer / Integrator Flexible Learning and Teaching Program Information Technology Services, Monash University ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
