in reply to CGI::Application, have I made a big mistake.

Here goes :)(hopefully you'll see what i'm trying to say)
"nah, you gotta control the users path. Lead them by the nose or they will get it all wrong!". This would mean a rewrite to allow each run_mode to pass the user directly to one and only one run mode for the next phase.
I personally don't know what your friend is talking about (control the path?). As for rewriting each run_more to apss the user ... how are you storing the session (form) data? If it's a single form submit/validation cycle, one run mode is fine (present form, if validate, do whatever, redirect to success page, else re-present form with some error messages).

You could have a separate run mode just for validation 

present_form ->
  validate_form -> success
                -> present_form

[download]
but having a single run mode (present_validate) instaed of two would be just fine. If it gets more complext than present_validate (2 in 1), then you need to split it up.

If it's a set of forms (multiple pages to submit, you have to store the session on the server), then a group of run modes is reccomended (each successfull submit leading to the next form/run_mode).

One of my questions is this: should run-modes be kept should and simple perhaps handling only a part of a sungle site function? For example, for an administrator to select and view user profiles, should the saearch, select, view and edit each be a separate run_mode or is it, in your opinion, okay to combine them into one run_mode?
I would say that's not ok. You're basically going against the design methodology behind CGI::Applicaton (read the "USAGE EXAMPLE" in the docs). Stick to one operation per run mode (it easier to think about it if you use templates. You basically have 1 template for every run mode. If you ever find yourself using more than 1 template, and keep in mind i'm not talking about includes, but two distinct templates for one run mode, you need to split that run mode into two).

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
** The third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: CGI::Application, have I made a big mistake.
by jdtoronto (Prior) on Nov 25, 2003 at 00:40 UTC
    PodMaster

    What my friend is saying is that the user should be taken along a siungle path through each major functional area of the site - that they should not be allowed the flexibility of registering at, say a tour level, but they need to provide more data into their user profile before they can use the full functionality (my scheme!) Thats one issue out of the way.

    My reason for grouping actions together is this: Each of my current run modes uses a single template (well, really a page template for the overall look, a navigation template that gives the relevant navigation for the current action and a form template that actually contains the form). I am using CGI::FormBuilder to render the forms - becuase it gives me an easy way of loading defaults, requiring a field and validating field values. The same form is used for 'new entry', 'display record' and 'update record' functions purely by changing the buttons below the form (part of what FormBuilder does very easily). So by the PodMaster rule of ONE TEMPLATE ONE RUN-MODE I am still on the correct path.

    I have been thinking about this for a coupole of hours over dinner now. One of the things I like about some websites is they give me the option of being able to browse without logging in. Just like PM does! So I want to be able to pop up my login form, the user can log in, and then they can go on from where they left off.

    Session management is important as has been stated in another reply, I am using CGI::Session and storing the users entire state in the session. So I start a session before there is even a log-in attempt. My reasoning for this is that I can have a 'BACK' button that works within the application. I can read the session, find out where 'BACK' would take them, and then even query the database if necessary to fill out a form with valid values rather than using the browser back button and the difficulties attendant upon that. It also means I can be much more logical, if a 'BACK' move would take an already registered client to the form where he built his registration profile - well, he doesn't want to register again does he! We could take him to an 'edit profile' version of the same form.

    jdtoronto

[reply]

In Section Seekers of Perl Wisdom