Oops, sorry about the previous message. I used a previous request as an email template for this one, and forgot to change the subject. The subject should have read "request namespace for HTML::Application. Hopefully you are not confused. --------------------------- I would like to register the namespace for a new module I am making: HTML::Application - cdpO - Framework for complex web applications DUNCAND This module is designed to make building scalable and reusable web applications easier by providing a framework for managing their states and components. The module provides a consistent context that application components can be written to, so that they can each act as if they are the "main program", whether or not they actually are. When any component is started, it sees that it must construct an HTML page of some kind as output, and that it is with provided a hierarchical set of "preferences" to customize its behaviour, and that it has a "virtual filesystem directory" that it can use to read or write persistant data, and that it has its own branch in the "virtual url hierarchy" to map its sub-functions (or "web pages") into, and that it is provided with any user input details (usually from the query) that it needs to know. An application designer can take any "subclassed" components that they wish and organize them into a calling hierarchy where some components can ask others to do a portion of their work. All components are called in exactly the same way, where the caller makes sure that the environment for the called is right, and taking the results of the called. So you can use exactly one of them or more in your application. My module takes care of many interaction details, so it is easy for a component to use its own context, and to set up contexts for others. Since "preferences" are themselves hierarchical, the programmer using some components has but to properly set the preferences for the top level component, and those preferences say which other components the first one calls, and say how to set up their environment. Part of the scalability is that "preferences" can be passed in either as a literal hash ref or as a scalar filename of a file that can be "do $filename" to return a hash ref, and this can be repeated to as many or few hierarchy levels as desired. My module takes care of interpreting these things so that the caller can pass either type without knowing what they passed, and the called always gets the hash it expects. Components would not use global variables except where necessary, and so as many instances of each kind can be made whose behaviour is determined mostly on preferences and user input passed to them. A virtual filesystem (resembling UNIX) is provided for components to use whose root is designated by the root application component and managed by my module. So components can just work with "relative paths"; that is, they say things like "I want to cd into a subdirectory of here" or "I want to open a file that is here". Methods in my module would take care of translating virtual filesystem requests into real ones, so when the component wants to open a file, it asks my module for the physical file path associated with the file they want, and issue the open system call themselves (I save on complexity by letting them do the actual system interactions). Calling components set the starting place for called components. The advantage here is that components won't break if their place in a hierarchy changes, and that they won't accidentally wander outside of the application's support file directory, assuming they stick to opening file paths that my module provides. Similarly, the virtual url hierarchy is provided for embedding in callback urls that make it easy to designate which program function (or site page) is called; each level in the hierarchy is used by nested components to figure out which component to call next to handle that branch of the tree. You have complete freedom to decide how many levels of one correspond to the other. Also similarly to above, you can designate "relative urls" for related pages, and my module takes care of translating them into absolute urls. My module allows easy construction of "output" HTML pages by storing their components internally, and any module can set or check its results with methods like [body_init(), body_append(), body_prepend(), title(), head_init(), etc]. For example, a "parent" component that makes a menu of "program options" (child web pages) can simply call body_prepend() to add that menu above whatever output the child page made. And it can either accept the page title that the child made or change it as appropriate. Parents have control over the children, as they set up their input and do whatever they want with output; children think they don't have any parents. My module also provides priortized search and replace functionality for the output. So, as preferences determine, some components could find and interpret different "tokens" in the output page and replace them with something else, such as formatting instructions or url fragments not previously known. This is particularly useful if some of the html you are using is read from a static html source and you have to insert self-referencing urls. My module saves on complexity by not actually doing any user input or output by itself, but rather lets the main program which calls and configures the top level component to do it. The caller simply has to: 1. provide a string saying the physical directory that is the root for the application's data; 2. provide a query string (not parsed or parsed) containing the user input; 3. take the completed web page as a string (or as parts) and output it to the user. This situation gives the main program writer a lot of flexability on how they want to obtain the user input (eg: using CGI.pm or some other method), and on how they wish to output the result (eg: within a mod_perl or CGI situation). That said, I will provide some sample code to demonstrate how to obtain user input and plug it into my module, as well as get its return result and give it to the user. My sample would take input from GET, POST, @ARGV, and STDIN for debugging, but it would not handle file uploads. To get a preview idea of what I am going to do, you can consider my "CGI-WebsiteGenerator" distribution as a loose prototype; several instances of web applications are running right now in a production environment, each one producing an entire web site dynamically (see http://www.DarrenDuncan.net, http://www.chronology.net). On that note, look in particular at the modules [CGI::WPM::Globals, CGI::WPM::Base, CGI::WPM::PageMaker, CGI::WPM::WebUserIO] as it is relevant functionality from them that is being replaced by my new HTML::Application module. The above are missing most of their POD (except PageMaker which is complete), so you may want to look at the code itself. Now, my request wouldn't be complete without quickly addressing other modules that may be considered "similar". So here are the ones I thought of: CGI:: ::Application RmpO Framework for building reusable web-apps JERLBAUM ::Screen adpO Create multi screen CGI-scripts ULPFR HTML:: ::Mason bdpO Build sites from modular Perl/HTML blocks JSWARTZ Given the range of features and complexity, I would say that my module would fit between the first two and the last one. That is, my module would provide a lot of functionality that CGI::Application and CGI::Screen do not, while it is an order of magnitude or three less complex than HTML::Mason. Significant differences between my module and HTML::Mason include: - Mason, as I understand, uses an ASP or PHP like approach that has otherwise complete HTML pages with embedded Perl code and/or "include" syntax. My approach does the opposite of having Perl files first, and the HTML is either embedded in them or in separate data files. - My version works on functionality over form and serves programmers first, making it more focused on actual "applications" that do something rather than "web sites" that display content (although my program can "be" a web site too"). Whereas, Mason is more focused on keeping visual designers with their graphical HTML editors in front, with code added for enhancement, as I understand it. - I don't do any explicit user input or output myself whereas Mason appears to do "the whole experience". - Lots of other differences. Differences between my module and CGI::Application include: - CGI::Application does not organize its "run modes" hierarchically whereas I do. - CGI::Application gathers user input using CGI.pm and it prints page results to the browser, whereas I don't automatically use a particular input method and I don't print things out. Differences from CGI::Screen include: - CGI::Screen subclasses from CGI.pm and is therefore strongly tied to it, and mine is not. - My module doesn't generate form html and such. - It is still a lot simpler than mine as far as added value goes. - Likewise, no hierarchy for organizing screens. If you have any questions then email me. So I look forward to you granting my namespace request. Thanks for all your hard work. Good days, // Darren Duncan