Matt,
I think you might want to look at CGI::FormBuilder, a library that builds
the same sort of construct you describe. It doesn't use Mason, but there is
no reason you cannot use the library from within Mason components. It might
make your life easier.
Personally, I never put complex data validation or any significant business
logic into a Mason component anymore. Over the years, as my code has become
more test-driven, I have found myself much more productive implementing
business logic, validation, and "actions" in a separate, testable library
which can be called from the Mason component. Automated unit tests handle
all the back-end stuff, so when I'm loading pages in the browser I don't
have to wonder whether I'm getting the right row from the database or
anything like that. It makes debugging easier for both the business logic
and the display logic in the Mason components.
Of course, sometimes it's just easier hack out the code. :)
Good luck!
----
Vince Veselosky
http://www.webquills.net
On Thu, Mar 20, 2008 at 3:58 PM, Matt Warnock <
[EMAIL PROTECTED]> wrote:
> Mason newbie, so please be kind.
>
> I like having a web form and its associated error-checking in the same
> file. Makes it easier if I have to make a design change later. So I
> thought I'd have the form component call itself as its form action.
>
> If in the <%init> section, the $ARGS{submit} value is present, then a
> form has been submitted, and we then check for errors. If not, we
> either fetch the needed data to populate the form (for editing an
> existing record), or just display the empty form (for inserting a
> record). A separate delete button could be used to delete the record
> (after confirmation). All the functions related to that record type in
> one file. Is this a bad idea? How do Mason experts do this?
>
> 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?
>
> 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.
> Outside components defeats the purpose of centralizing the data
> references, and inside or sub-components need/get their own %ARGS hash,
> I understand.
>
> 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?
>
> -
> Matt Warnock
> RidgeCrest Herbals, Inc.
>
>
>
> -------------------------------------------------------------------------
> 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
> Mason-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mason-users
>
--
-Vince Veselosky
http://www.webquills.net
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Mason-users mailing list
Mason-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mason-users
