"Richard Heintze" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Both Microsoft (with ASP.NET) and Apache (with stuts > and java custom tag library) have recognized the > perils of embedding UI code (browser code like HTML > and Javascript) inside backend/database code (SQL, > perl, Java, C# etc...)
There is a super slick module called Class::PhraseBook for getting the SQL out of your application logic. Also, I always put javascript in its own file and refrence it from the html document. > Is there anyway seperate the UI layer from the back > end layer when programming cgi perl? Here is what the MVC for one of my projects looks like: http://gozips.uakron.edu/~trw3/code/mvc.txt This is only a part of it, but so you can get the idea... First, I put this in my httpd.conf: <Files ~ "\.xml$"> SetHandler perl-script PerlInitHandler Enote::Debug::StartRequest PerlHeaderParserHandler Enote::HeaderSessionManager PerlHandler Enote::XMLHandler PerlCleanupHandler Enote::Debug::EndRequest </Files> As a mod_perl developer, you should understand what it means. Next, The controller is implemented as a SAX chain, placed in the handler() function in a package named Enote::XMLHandler, that looks like this: my($machine) = Pipeline( 'XML::Filter::BufferText' => 'Enote::SAXFilter::Language' => 'Enote::SAXFilter::ParameterInfo' => 'Enote::SAXFilter::AddStyleSheetURI' => Enote::SiteConfig::getSAXHandlers( $r ) => 'XML::Filter::SAX2toSAX1' => $yawriter ); Pipeline() is a function provided by XML::SAX::Machines to help facilitate building dynamic SAX streams. Notice the function call as the 5th element in the chain. Enote::SiteConfig::getSAXHandlers() looks like this: sub getSAXHandlers { my($r) = shift(); Enote::Debug::log( 1 ); my( @handlers ); my($pack) = 'Enote::SAXHandler::' . Enote::Format::chToPackage(); my($modPath) = 'Enote/SAXHandler' . Enote::Format::chReqFileExt($r->uri(), 'pm'); if ( defined( $INC{ $modPath } ) ) { Enote::Debug::log(2, "pushing $pack onto SAX handlers" ); push( @handlers, $pack ); } Enote::Debug::log(2, 'no sax handlers for: ' . $r->uri() ) unless ( @handlers ); Enote::Debug::log( 5 ); return( @handlers ); } What this does is see if there is a module that has been loaded that corresponds to the file requested. The xml documents and modules are related by file path and name (minus the extention). If the function finds a module that corresponds to the requested docuement, that means there is request specific code that needs to insert data into the resulting XML document. The code above is only for the UI logic. Kind of like the the "code behind" concept in ASP.NET To collect user input, all web forms/data are submitted a single URI. The code that is executed behind this URI dispatches the data to a SOAP web service, does its interaction with the database, and then the dispatcher does an internal redirect for the next view for the user and sends the markup to the client. Some of the clients do not use this dispatcher, interacting with the web service directly. For example, one interface uses IE as an application platform instead of a document viewer and accesses the MS SOAP toolkit with javascript in the browser. The objects in the toolkit use the DOM to extract information from the view (perhaps the text in a HTML text field). These objects then call methods or access properties of parallel objects living in the HTTP web service process. software like openwave's UP.Browser dosent have a SOAP api, do I had to make the dispatcher. Unfortunately, thats only a portion of how the whole thing works. But if you understand how XML::SAX::Machines is used above, you are half way to getting your content seperated from its display. HTH, Todd W. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
