> All the functions related to that record type in
> one file. Is this a bad idea? How do Mason experts do this?
It doesn't sound like a bad idea. I used to do it that way. (Now I
use a lot of AJAX calls).
>
>
> However, it would be nice to be able to bail out of the <%init>
> section
> early if there is no $ARGS{submit} value, like an early return from a
> subroutine, while still executing the rest of the component. Is
> there a
> way to do that? Or am I asking the wrong question because I am
> assuming
> too much?
Why not:
<%init>
if ($ARGS{submit} {
#take care of the submitted data
}
#rest of component
</%init>
% if ($ARGS{submit} {
<!-- More of component if submitted -->
% }
<!-- Rest of component if submitted -->
>
> Code gets deeply nested if you try to do too much testing this way,
> and
> breaking it into subroutines causes errors every time I try to access
> the %ARGS (variable won't stay shared errors) from a perl subroutine.
instead of:
sub Routine { do something }
do:
$Routine = sub { do something }
> On a larger scale, how do others manage this stuff where the DBMS is
> under active development and you don't want SQL inserts, deletes,
> updates, and selects to the same table, with their associated forms
> and
> business logic processes, in many different files all over the place?
> What organizing conventions do you find helpful?
You could put some of your common functions into a module. I'm
unclear about your concerns with the SQL. What's the problem with
"inserts, deletes, updates, and selects to the same table"?
Ryan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
