What Is L7?
Last Updated: Nov 9, 2004
L7 is a nickname for Cycla Corporation's "Level 7" family of web development tools. The L7 family includes two products:
- The L7 Framework is a partial application development framework designed
to facilitate rapid application development of web-based applications using
Microsoft Visual FoxPro and West Wind Web Connection (WWWC).
- The L7 Toolkit is a set of class libraries for creating input forms,
output reports and handling various parsing needs.
Status: not publicly available -- we are considering open-source availability in the future.
L7 Framework: Requirements and Inclusions
- Requirement: Requires Visual FoxPro Version 8 or later. Will not operate with Version 7 or earlier.
- Requirement: Requires West Wind Web Connection Version 4 or later. (Not included.)
- Includes the L7Toolkit product as part of the framework.
L7 Framework: Summary Description
- A single server object provides the interface for the Web Connection ISAPI application, in much the same manner as a stock Web Connection application. (This server object is currently implemented as a very-heavily subclassed version of wwServer.)
- An application manager object manages a collection of application objects, thus allowing more than one entire web application to be contained within a single server (VFP project). The application manager is responsible for persisting each application object, and for routing requests to the appropriate application.
- Web hits (requests) are routed through application objects, which are persistent objects operating in their own private datasessions. Beyond providing a persistence layer, the primary function of the application object is to marshal requests to the proper page-handling class. The application object uses an extensible class factory for this purpose.
- Individual web pages are processed by objects instantiated from page classes, which can be arranged in a class hierarchy of any depth suited to the complexity of the application. Inheritance proves very valuable in areas such as security and application look-and-feel across pages.
- Each response is returned using one of several response assembly
strategy objects, each of which encapsulates a "typical" spproach that developers
use for returning responses. Built-in strategies include:
- Standard. This strategy generally relies on code to create the elements that comprise a response. (See discussion of "page elements" further below.)
- Template. Under this strategy, an entire HTML template is evaluated allowing VFP expressions to be substituted. Limited structural tags are also supported, allowing some basic usage of SCAN, FOR EACH, and IF blocks within a standard HTML page, without requiring either compilation or CodeBlock.
- File. This strategy is used for returning alternative content types, generally from files on disk. Examples are PDF or Excel files. HTTP header assembly is handled automatically.
- Co-opted HTML. This strategy allows static HTML pages to be intermixed with an active L7 application without losing user state, even when cookie-less (license plate) session management is utilized. (Feature currently being developed.)
- Errors. This strategy handles the automatic generation of error responses. The framework automatically switches to this strategy when an error occurs, thus simplifying a developer's tasks.
- Standard HTML responses (see first strategy above) are rendered by a composition of page element objects, whose output is concatenated by a master "body" object to form the visible response. The output of that is further combined with a HTTP header and an object that encapsulates the <head> section to create the overall response. Each page element is autonomous, and can either be written to asynchronously or rendered from a source document. Source documents can be pure HTML, or can include embedded VFP expressions or even code blocks. These elements can be completely mixed-and-matched within an application or even a single page. (For example, a left-margin menu could be rendered from a collection of menu items, while the page "content" was expanded from an HTML "template".)
- Framework processing is wired to be optionally monitored by developer-created visitor objects named process monitors, with pre-defined hooks at all major framework events. Potential uses of process monitors includes performance analysis, customized logging/accounting, or specialized security requirements.
- Slow-running processes can be easily run asynchronously without writing any special code. A single call to Page.OffloadRequest() will cause the request to be placed in a queue, with an intermediate response sent to the user together with automatic polling for completion. Response and polling behavior can be customized if needed.
L7 Toolkit: Highlights
The L7 Toolkit is a package of controls that can be used in standard Web Connection development. These controls are also included as part of the L7 Framework (described further below). There are currently three (3) major components of the L7 Toolkit, although more may be added later. The highlights of the major components are itemized below.
- Comprises a set of control classes designed to encapsulate the process of rendering HTML forms and processing submissions of those forms.
- Cross-browser compatible with strong emphasis on use of Cascading Style Sheets (CSS).
- Capable of rendering forms that meet accessibility guidelines.
- Dependency: Currently, there is some limited dependencies on Web Connection, in that the form-processing features utilize the interface of the L7Request class, which is a subclass of the wwRequest class.
- Limitation: No visual design tool. All forms are designed in code. We are exploring the potential of using DreamWeaver and/or FrontPage as a visual layout tool, but even if successful, we anticipate that, except for the physical placement of controls, forms will always be designed in code (PRG files). Other developers may want to explore the possibility of writing wizards or builders to convert visual layouts to L7 classes, but there are no plans for L7 to include such technology.
- Basic controls include textboxes, textareas, labels, hidden form vars, buttons, checkboxes, radio buttons and popups. (Support for morphing a control between a popup and a radio button.)
- Multiselect control, including the ability to morph between a multiselect popup and enumerated multiselect checkboxes.
- Grid control (implemented via L7Grid and L7Iterator classes).
- Limitation: Currently no support for page frames and/or multi-step (wizard) forms.
L7 Reports [just announced -- will replace similar functionality in L7 Table]
- A flexible set of classes for producing tabular HTML output.
- Uses latest VFP 8 technology, including heavy use of collections and event binding.
- Collections include Bands, Columns, Fields, and Groups.
- Object model allows full intuitive control. [Example: Report.Fields("Customer").Color = "red"]
- Supports using VFP expressions for most properties, thus providing per-record formatting.
- Produces HTML, but can be extended to other formats.
- Provides a society of parsing classes for handling input- and output-parsing needs.
- Included sample subclasses support several common needs in web applications, such as rendering URLs as hyperlinks.
NOTE: All components of the L7 Toolkit can operate standalone or as part of the L7 Framework.
RAD and Enterprise Features
- Liberal usage of hooks, template methods, and factory patterns allows much flexibility for further extension and customization.
- Standards-based focus, particularly in emphasis on meeting accessibility guidelines, and in support of using cascading style sheets (CSS).
- Input forms and output tables can be constructed using RAD techniques, and then fine-tuned later after basic design has been accepted.
- Built-in, automatic support for user identification and session management strategies, including both cookies and "license plates" (which can even be used in combination). Support for an authentication model is also provided, but the approach is not recommended.
- Easy deployment of asynchronous processing for long-running requests.
- Hosting and scheduled services...
- Voodoo Web Controls: In general, Voodoo controls can be hosted in L7 pages, in the same manner you would host them from a stock Web Connection process method. The Voodoo 1.2 design required one minor change to how a form tag's "action" attribute is created, in order to be compatible with L7's URL-management scheme. EPS has publicly indicated that this change has been made and will appear in the next Voodoo release. [Update this page when next release is made to Voodoo!]
- Visual Fox Express (VFE): A major goal of L7 is to be compatible with any developer's selection of data and business tier tools.
- Active FoxPro Pages (AFP): The current position is that the L7 Framework is not compatible with AFP. The standalone L7 Controls have not been tested with AFP, but could likely be made to work in that environment with either an adapter or a different Request object. Assuming L7 proceeds to a beta test stage, we may offer selected AFP developers an opportunity to investigate this area.
- User Agents (Browsers): L7 is designed to operate best with browsers that support CSS Level 1 or better. L7 does not utilize absolute positioning in DHTML, or rely on a specific browser object model. We test regularly with recent builds of MSIE and Mozilla. Our approach is to "fail gracefully" on older browsers.
FAQ (and other Questions and Answers)
When will Cycla make a commercial decision on whether or not to market L7?
Cycla has decided not to market L7 commercially. Cycla may release the framework and toolkit as open source at some future point.
How do L7 and Web Connection fit together?
The L7 Framework is designed to be used in conjunction with Web Connection. L7 relies on attaining request information in the format provided by WC.DLL. Further, L7 does not provide any equivalents for some Web Connection classes (wwXML and wwIpStuff), and subclasses some of the others (wwRequest, wwServer). On the other hand, many Web Connection classes are not used in a pure L7 application, including wwResponse and wwProcess.
Does L7 include data access or business object layers?
The L7 Framework focuses on processing dynamic web requests. It does not include any pre-defined approach to data handling whatsoever. It is expected that Visual FoxPro developers would continue to use the same 3rd-party tools and frameworks that they use for desktop applications. In future revisions, L7 may include classes that implement these layers, but usage of any such classes will always be optional, in deference to maintaining compatibility with enterprise investments in other development tools and approaches.
Does L7 use the techniques published in the Hentzenwerke WebRAD book?
Short answer: No.
Although some of the techniques and tools presented in WebRAD have parallel implementation in L7, WebRAD was written to be accessible and useful to all Web Connection developers. The L7 Framework is strictly for serious developers that spend a significant fraction of their time developing web applications with Visual FoxPro.
How can I learn more about L7?
You can send email to L7@cycla.com. You can also ask to be put on an email list to receive future announcements.
© 2003 by Cycla Corporation