| |
- DVRWebBase
- DVRWebForm
- TestCmd
Wouldn't it be great if you could take a powerful application development language such as Visual FoxPro and slap together a dynamic website?
I mean visually, not by writing programs that call custom functions with parameters that build the HTML text.
I also don't want to be bothered with issues learning cookies, authentication, JavaScript, VBScript, ADO to access data, but to control access using standard VFP methodology you may already be familiar with.
If this sounds appealing, then welcome to DVRWeb for Visual FoxPro©. This product will allow you to do just that.
Create a fully dynamic website using standard forms and other objects to access data using methods direct from VFP.
You can even create your own visual classes that can be placed on multiple forms to prevent the need of redundant work.
Take advantage of what you already know by using forms, labels, textboxes, grids, images and other standard object classes. Where applicable, many controls, such as texboxes, labels and checkboxes, take advantage of existing object properties including:
FontName, FontSize, ForeColor, FontBold, FontItalic, FontUnderline. Many other objects support the When() method and ReadOnly and Visible properties to determine if they will be included in the final HTML page.
Finally, don't forget about the command button Click() event to submit your web request, almost as if you clicked the button on the form itself.
This product uses the FoxISAPI.DLL that is available from Microsoft (and also found via the
internet), and now its own DW.dll (similar, but more user-friendly for
connection and error response handling and FoxISAPI). Both have been included.
FoxISAPI.dll and DW.dllis used to connect a user request with an ISAPI compliant web server such as Microsoft's Internet Information Server or Personal Web Server.
Many items of information such as cookies, user authentication, server/remote addresses, etc will be provided by
the dll and read into respective properties in the framework (which will be covered later).
However, for those interested in using Active Server Pages, a direct method of access has been created to allow passing the Request, Response, Session, and 4th parameter for specific process handling.
The framework will read the information as needed and create a cookie if necessary. Again, many items will be stored in respective properties in the framework.
With DVRWeb you can create a powerful website almost as if you were building forms for a standard application.
Everything can be visual. Although not all objects are supported, here are the ones that ARE SUPPORTED: form, checkbox, combobox, commandbutton, editbox, grid (with
lines, line colors, DynamicCurrentControl and DynamicBackColor support), image, label, optiongroup, and textbox.
You can also take advantage of creating custom methods in your forms, and make use of standard tables (or data from other sources - views, ODBC, SQL-pass through to Oracle, SQL Server or other database engines that support ODBC.).
Also, you won't need to know how to get specific variables back from the HTML pages submitted. If a variable found by the same name as an object on the form, can be referenced as
Thisform.TextBox1.Value within the click event on a form button.
NOTE: If the control is not bound to a table column source, all values will be defaulted to character based results.
It is up to you as a developer to convert to necessary alternate data type such as numeric, integer, date, etc as necessary.
The entire framework has been incorporated within a couple class libraries.
The first class library is called "DataMgr". This class has been made up of one data manager to handle one table specifically. There are a variety of tables in use by this framework, each for its specific purpose within the framework. The convention is "DM_<table name>" where it becomes obvious which table the data manager is responsible for opening, accessing and updating as needed. Ex: DM_WebCookies works with the "WebCookies" table.
The next class library is "WebClass". Four of the five classes here are critical to the framework.
is the main class for ALL web requests. The framework controls the request formatted in such a way that all traffic goes through this class.
It is responsible for tracking cookies, authentication, creating forms to be returned back to the user, etc.
is main class that all your web-page development should be derived from.
It is suggested that when you create your web-site, you create your own class
library and create a base form derived directly from this class. Then all of your form pages should be built on your sub-classed version.
This can help with any future updates/enhancements to be implement as any custom components you add to YOUR base class will not be lost (or limited impact).
This class has methods that cycle through all controls on the form, and builds the corresponding HTML equivalent for final output.
This includes building out styles for each font used in the page. Also, depending on settings will generate DHTML absolute positioning of controls.
is a command button that is used for debugging to allow you to trace errors within VFP.
When an error occurs during the processing of a web request (either live or testing mode), a record is trapped in a table "TraceError" and maintains information on the most recent post including data in the .INI file, user cookie, and form requested. To test a page when a form is logged with such error, you can just put this control on the form, rebuild the exe and run the .exe with the specific page needing review. Ex:
DO DVRConfig with "InvoiceRanges"
Then, if you click on this button, and there is a corresponding error logged in the TraceError table, it will run, as if a live post was requested and allow you to stop at the given "Error".
Although there will be a segment for some development "gotchas", a primary note is that a form can not require ANY keyboard input such as messagebox or wait window (unless the wait window has a timeout clause).
The reason is that this will basically be running on an unattended server processing requests.
If there is a logic error, file not found error, syntax error, etc., this can ultimately hang the server.
This would happen for any web server process, therefore, debugging is a critical component to building any dynamic website.
One nice advantage to the DVRWeb project is the ability to run your form direct from VFP, and test building the HTML page with data, before going live against a web request.
This too will be covered with the rest of the classes. There are many sample forms included in the demo.
In order to use DVRWeb, there are some basic requirements as follows.
- Pentium PC using either of Windows 98/NT/Me/2000
- Installation of Web-Server software such as Microsoft
- Personal Web Server (PWS) or Internet Information Server (IIS), or other ISAPI compliant web server.
- Microsoft Visual FoxPro 6.0
- Web Browser such as Internet Explorer or Netscape Navigator
- Testing can be done either
- locally using http://localhost
- live using a registered domain such as http://yoursite.com
- across your network using your server's IP address http://999.999.999.999
|
