Al Pacifico
pacifico at drizzle.com
Wed Jun 8 00:38:25 EDT 2005
I'm looking for suggestions re: solutions to the following problem. I'm expanding templates using psp.PSP within a publisher handler because I wish to separate application logic and presentation as much as possible. I would like to have an HTML template that a HTML person can understand and modify, as I don't have the artistic eye to create compelling HTML. My preference is to code the business logic in classes, especially for unit-testing outside the web browser. My application is not complex enough to needs lots of sub-templates (or the object-orientation of the perl HTML::Embperl framework, for example) and is therefore well-suited to a simple HTML template model. It's 98% application and 2% content. Now, to give a specific example: In a representative part of the envisioned site, my browser visits a "client list" page and clicks a client's name to link to a "client detail" page. >From there, there are links to "edit billing address," "add/remove client representatives," "change client's name," etc... you get the idea. After filling in the appropriate form fields, I'd like clicking submit to land the browser either back to the client list or to the client detail page (haven't decided which, maybe give the user the option either). What is the best way to validate and store the form data? (Also, let's assume I'm allergic to javascript) I can think of: 1) submit goes to a new page that performs the processing, redirects 2) submit goes to a new page that performs the processing, then generates the ultimate target page using PSP and the same template file (which brings up the question, is PSP "directory savvy"). The name of the PSP template file could be passed in the Session to the next page. 3) submit goes to either the "client list" or "client detail" page and both are smart enough to know how to do the processing My gut tells me that the latter is best and is best addressed with a Transaction base class and a TransactionQueue class to minimize code duplication and maximize maintainability. The logic of the publisher function calling the PSP page containing the form would instantiate a TransactionQueue, register a new Transaction class in it, and save it in Session. Then whatever page receives the form data first registers itself (or a redirect to the ultimate target) as the final element (in case the form data is invalid and the browser needs to revisit the form page) and then begins sequential execution of the operations registered in the TransactionQueue instance. My questions are: 1) What is the prevailing opinion re: best method given my description of the problem (application rather than content)? 2) What are the pros and cons of various methods? 3) If my initial thought is correct, has someone implemented this, would they share it with me, and how do others feel about it? I've looked briefly at Myghty, PyWork, Vampire, JOTWeb, and Zope. None is compelling, but maybe I need to look at one (or more) harder. I won't comment on my first impressions of each, as they are only first impressions. I'm often leery of "frameworks" from my previous experiences with mod_perl (I'm new to mod_python) and HTML::Mason, which worked great for me at first, but then gravitated in a less useful direction, eventually pushing me to prefer HTML::Embperl and ultimately mod_perl without a framework instead. Input is appreciated. If this question has already been thoroughly addressed, please point me to the correct portion of the archive. Thanks. -al Al Pacifico Seattle, WA
|