The goal of the project is to provide Delphi programmers with high quality object oriented solutions that are not available in standard Delphi VCL. Things like Document/View architecture (Observer pattern), HTML/XML parsing and generation are very easy to implement at rudimentary level, but are very difficult to maintain in long term without solid object oriented background library supporting the code.
Initial goal of the project was to simplify creation of HTML/XML application. If you need to generate a highly dynamic web page, that contains many pieces dependent on your data in database or on your configuration, you have two options. First is to use TPageProducer and the second is to use string manipulations to generate content directly. Both these solutions make you use raw HTML in form of template or string constants and literals. It works well for the initial development or prototyping. HTML string literals become a nightmare when you need to debug your code. You need to look for missing tags, tags that breake containership relations, etc. Situation only gets worse if you happen to open a tag in one function and close it in another.
Windows user interface components in Delphi provide a great object oriented framework for building applications. You create a form by creating different objects and connecting them together to achieve required behavior. Then you can use methods to manipulate content of edit boxes, combo boxes, etc. A side effect of this great object oriented architecture is that you get all the bells and whistles of design time support for form editing.
XVCL was started with an idea of building a set of components that would be just like windows components in Delphi, only for HTML. So that you could create a new HTML page and drop various HTML components on it, like HTML edit box, HTML table, HTML button. To generate actual content, you would connect your HTML page as a content provider to Web action item in you web module. HTML components would be very similar to DOM (Document Object Model).
After initial design and prototyping, we found out that set of core document classes, representing HTML elements and attributes can be used for much more than simply generating HTML. The whole unexplored area in Delphi is Document/View architecture. If you are not familiar with this term, you could find term Observer pattern more meaningful. It's a term from Design Patterns book written by Erich Gamma et al. You could say that Document/View architecture is already implemented in Delphi with TDataSet/TDataSource/Database aware controls. That is correct, but it only works for database specific code.
A tipycal use for Document/View architecture would be a multipage dialog box. Let's say that you have a dialog box with 5 pages on it. What if one of the pages depends on the other? It can be like, if page 1 modifies some item A, page 3 needs to update items B and C. Without Document/View you have to make page 1 aware of page 3, so that it can let it know whenever item A was updated. It's not a bad thing if you have only 5 simple pages to worry about. What if as your product grows, and you need to add another 10 pages to your dialog, and a couple of them depends on item A from the first page. You will have to go back to page 1 and make it aware of pages 7, 10 and 13. Now you've got a maintenance problem. In ideal world you would like to be able to add a new page to the dialog without modifying any existing pages. Is that possible? Yes, with Document/View architecture.
With Document/View approach you divide your dialog box into two parts. First part is a Document object that contains all data that needs to be edited. Document object knows about internal dependancies between items A, B and C. It's the Document object that is responsible for updating items B and C whenever item A changes. Second part is View(s). Pages of dialog box are "Views" of the data stored in the Document. Whenever a piece of data is changed Document notifies it's views so that they can update the information displayed on screen. So if user changes text in edit box representing item A, dialog page will send this information to the Document object. It will recalculate items B and C and send notification to other pages of the dialog box. Does it sound like much more work to do that before? Yes, it does. You have to have a separate class and object for Document. You have to make Document and Views interact with each other. But doing this you gain benefits of being able to change individual pages and document without breaking other pieces of dialog box. You don't have to make page 1 aware of pages 5, 7, 10 and 13. But it's still a lot of work to do. That's why Delphi programmers don't use Document/View as often as it is needed.
With XVCL you will be able to create document object using design time editor similar to Data Module editor in Delphi 5. Document object can have tree-like structure consisting of nodes (elements and their attributes). You will be able to assign event handlers to handle data changes made to any node to recalculate dependant items. For Views, you will be able to use "document" aware controls, like edit and combo boxes to hook them to nodes in document. You will not have to worry about refreshing page 5 after page 1 was changed. "Document" aware controls will be notified by document object and refresh their content without you writing a single line of code. Doing Document/View programming this way will be much easier than from scratch.
Copyright © 2000 XVCL