Re: [Openinteract-dev] SPOPS for Web App Development

[Chris W. <ch...@cw...>]

David C. Reed wrote:
> I have some questions that I hope are germaine to this list.  i am

They are -- SPOPS doesn't have its own mailing lists. I've thought 
about it but decided we don't get enough traffic to warrant 
separating OI and SPOPS. My mind could be changed...

> developing a web-based application for a client that does typical web db app
> stuff (track records, let people view/edit/create based on group priveleges,
> etc.).  They unfortunately require that it be run on one of their servers,
> meaning that I am limited somewhat in terms of what I can put on their
> machine, and I can't use OpenInteract or Template Toolkit.  I am using SPOPS
> and a rudimentary templating module.  Is there a "best pratice" for using
> SPOPS in such a way? Specifically, where should logic be implemented and how
> should action dispatch be handled?  I am thinking of the approach of adding
> a common handler 'code_class' to each class.  The handler will contain
> methods and also a dispatch mechanism to determine the appropriate method
> and template to employ based on user privilege, current class and requested
> action.  Is there a cleaner way to do this?

I'd split apart these responsibilities as much as possible. IMO 
SPOPS should focus on moving data between objects and the database 
and adding behavior to those objects. Something else should focus on 
showing those objects to the user and allowing the user to act on them.

OpenInteract takes care of the dispatching mechanism, but it's not 
the only possiblity. CGI::Application operates on much these same 
lines, and it's pretty easy to write your own. The basic idea is 
that you have some external configuration (Perl data structure, XML 
file, database records, etc.) that map incoming URLs to a subroutine 
  or class::method call. The dispatcher will read in this 
configuration, do some initial setup (instantiate the CGI request, 
parse parameters, do authentication/authorization, etc.) and then 
pass control over to some other process which is responsible for 
generating the response.

Andy Wardley (Template Toolkit creator) wrote a great email [1] to 
the TT mailing list about what the Model-View-Controller pattern (or 
metapattern) means for web development. The key point isn't adhering 
to an MVC doctrine (which is suspect in webapps). It's separating 
these different areas. Not just so you can substitute different 
implementations -- that's nice, but it doesn't happen as often as 
some people like to say.

What it gives you is the ability to focus a tool on what it does 
best -- we don't really *need* the Template Toolkit (or any other 
templating module) to output HTML to a browse, a series of 'print' 
statements will work as well. But it allows us to develop a very 
flexible system with very simple coupling points, so (for example) 
we might find that the request-process-response model works just as 
well handling SOAP request, or incoming emails, or Jabber requests, 
or something else we haven't even heard of yet. And we don't have to 
worry about tying our framework to HTML or even a tag-based markup 
language because TT can generate any sort of text, even Postscript.

Plus, if you separate things out and in the future you *are* allowed 
to use OpenInteract, you'll have a much easier time making the 
transition ;-)

Good luck,

Chris

[1]http://lists.ourshack.com/pipermail/templates/2002-November/003974.html

-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.