Embedding Perl in HTML with Mason Chapter 3: Special Components: Dhandlers and Autohandlers

Tham khảo tài liệu embedding perl in html with mason chapter 3: special components: dhandlers and autohandlers, công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Embedding Perl in HTML with Mason Chapter 3: Special Components: Dhandlers and AutohandlersChapter 3: Special Components: Dhandlers and AutohandlersIn previous chapters youve seen an overview of the basic structure andsyntax of Mason components, and youve seen how components cancooperate by invoking one another and passing arguments.In this chapter youll learn about dhandlers and autohandlers, two powerfulmechanisms that help lend reusable structure to your site and help youdesign creative solutions to unique problems. Masons dhandlers provide aflexible way to create virtual URLs that dont correspond directly tocomponents on disk, and autohandlers let you easily control many structuralaspects of your site with a powerful object-oriented metaphor.DhandlersThe term dhandler stands for default handler. The concept is simple: ifMason is asked to process a certain component but that component does notexist in the component tree, Mason will look for a component calleddhandler and serve that instead of the requested component. Mason looksfor dhandlers in the apparent requested directory and all parent directories.For instance, if your web server receives a request for/archives/2001/March/21 and passes that request to Mason, but no suchMason component exists, Mason will sequentially look for/archives/2001/March/dhandler, /archives/2001/dhandler, /archives/dhandler,and /dhandler. If any of these components exist, the search will terminateand Mason will serve the first dhandler it finds, making the remainder of therequested component path available to the dhandler via $m->dhandler_arg. For instance, if the first dhandler found is/archives/dhandler, then inside this component (and any components itcalls), $m->dhandler_arg will return 2001/March/21. The dhandler canuse this information to decide how to process the request.Dhandlers can be useful in many situations. Suppose you have a largenumber of documents that you want to serve to your users through your website. These documents might be PDF files stored on a central documentserver, JPEG files stored in a database, text messages from an electronicmailing list archive (as in the example from the previous paragraph), or evenPNG files that you create dynamically in response to user input. You maywant to use Masons features to create or process these documents, but itwouldnt be feasible to create a separate Mason component for eachdocument on your server.In many situations, the dhandler feature is simply a way to make URLs moreattractive to the end user of the site. Most people probably prefer URLs likehttp://www.yoursite.com/docs/corporate/decisions.pdf over URLs likehttp://www.yoursite.com/doc.cgi?domain=corporate&format=pdf&content=dec isions. It also lets you design an intuitive browsing interface, so thatpeople who chop off the tail end of the URL and requesthttp://www.yoursite.com/docs/corporate/ can see a listing of availablecorporate documents if your dhandler chooses to show one.The alert reader may have noticed that using dhandlers is remarkably similarto capturing the PATH_INFO environment variable in a CGI application. Infact, this is not exactly true: Apaches PATH_INFO mechanism is actuallyavailable to you if youre running Mason under mod_perl, but it getstriggered under different conditions than does Masons dhandler mechanism.If Apache receives a request with a certain path, say,/path/to/missing/component, then its actions depend on what the finalexisting part of that path is. If the /path/to/missing/ directory exists butdoesnt contain a component file, then Mason will be invoked, a dhandlerwill be searched for, and the remainder of the URL will be placed in $m->dhandler_arg. On the other hand, if /path/to/missing exists as a regularMason component instead of as a directory, this component will be invokedby Mason and the remainder of the path will be placed (by Apache) into$r->path_info. Note that the majority of this handling is done byApache; Mason steps into the picture after Apache has already decidedwhether the given URL points to a file, what that file is, and what theleftover bits are.What are the implications of this? The behavioral differences previouslydescribed may help you determine what strategy to use in differentsituations. For example, if youve got a bunch of content sitting in a databasebut you want to route requests through a single Mason component, you maywant to construct file-terminating URLs and use $r->path_info to getat the remaining bits. However, if youve got a directory tree under Masonscontrol and you want to provide intelligent behavior for requests that dontexist (perhaps involving customized 404 document generation, massaging ofcontent output, and so on) you may want to construct directory-terminating URLs and use $m->dhandler_arg to get at the rest.Finer Control over Dhandle ...