Constructor for creating content-based applications in the style of Web 2.0

It will be a question about recently opened Open Source project SAPID CMF. In itself, the name SAPID may seem to someone vaguely familiar. Yes, there was such a simple CMS SAPID that allowed administering inline websites, required only 1MB of disk space and managed to do without DBMS. However, few people remember that this system was created to demonstrate the capabilities of the XML Sapiens paradigm. CMS SAPID safely and pompously met its first anniversary, and then for 2 years, no significant new releases of it were observed, sadly enough. However, the last year on the SAPID community site from time to time slipped information about the work on the new branch of the SAPID project CMF. Voila! Here it is - a branch, available for download ( http://sapidcmf.sourceforge.net ) and for the “nodding” dating ( http://cmfdemo.xmlsapiens.org ).

SAPID CMF is something like a two-in-one set, where SAPID is a content management system with a basic administrative interface and CMF is the designer for turning this interface into its own customized system.

Any CMS is, on the one hand, an engine for web applications, on the other - an interface for administering these applications. It would be logical to assume that the delivery area applications (those that are available to users of the site) and the CMS administrative panel applications operate on the basis of a single engine, obey the same logic, use the same template principle. Thus, a CMS that allows the creation of external web applications should easily provide the creation of internal administrative interfaces. The heart of SAPID is the XML Sapiens processor. XML Sapiens is a declarative language for describing patterns of data structures, styling, and functionality. Using the language, you can create components for all three levels (data, design, functionality) and use them repeatedly (reusing), like construction blocks, to get the most different solutions. The XML processor Sapiens compiles these components into a ready-to-use user interface.
')
For web applications, unlike desktop programs, there is no predefined set of GTK controls. This is both a virtue and a disadvantage. When creating each new application or group of applications, developers are forced to create a new GTK. In order to make life easier for developers, the GTK administrative panel SAPID CMF is designed in the manner of Windows. Each of its applications has a workspace, menus, modal windows, message boxes, dialogs, processes. Components are available - tree view and list view. Thus, we have a kind of “gentleman's set” for quickly creating applications of the administrative panel in the same style.

Willingness to develop

You say, “Great! I will add my own applications to the admin panel. A month later, a new release of the framework will appear. I will complete the update and lose all my work. ” In fact, the SAPID CMF is organized in such a way that the update replaces only the basic components, while the additional components added by the developer will remain intact. The question arises: "How to modify the basic components and protect the modification code from being overwritten during the update?". SAPID CMF uses an event model in the aspect-oriented programming style. The system defines various events. You can add your own handlers for various events that modify the environment properly. The modification code will be placed in the plugins folder, which is skipped when the framework is updated. In terms of AOP to modify the base components (API libraries, controllers, etc.) you define some aspect of the modification.

$ ModalWindowCustomization = new Aspect ();

Give him a listening area, say all classes and all methods.

$ pc = $ ModalWindowCustomization-> pointcut ("call * :: *");

and assign a modification code to a specific event

$ pc -> _ event ("ModalWindowSchemasDefined", "customizateModalWindow (\ $ obj);");

As mentioned above, the SAPID CMF super-task is to ensure the effective multiple use of data structure, layout and functionality in the creation of web applications. The framework contains the root folder VIEWS. It contains the DEFAULT folder for the default administrative panel design theme templates and the DELIVERY folder for application templates created on the basis of the framework. If you add additional themes, the corresponding folders will appear here. Each of them contains functionality templates (DDC folder), field sets (FIELDSETs folder), content request templates (QCs folder), and design templates (TEMPLATES folder).

Once written, we use it many times

When creating a web application in a thumbnail of a logical page, dynamic areas are defined. For example, we cut out menu blocks, list blocks, etc. and transfer their clearance code to the appropriate DDC. In addition to the design code, the DDC also sets the logic of the dynamic block . Here conditions, enumerations of data from the requested CMS applications, inclusion, XML Sapiens expressions, as well as unlimited nesting of these structures can be used. XML is used to describe this logic. XML Sapiens allows you to use the same DDC to form different dynamic blocks. When calling DDC, parameters that can be considered under DDC conditions can be passed.

<sapi: apply name = "ddc. # submenu.value">
<sapi: param name = "root"> structure </ sapi: param>
</ sapi: apply>

If the form of data entry is assumed in the code of a dynamic block or in the code of a logical page template, we turn to QC. QC determines how the data reported to it will be displayed or requested. For example, if we use a call like <sapi: apply name = "qc.contentblock.value" type = "article" title = "Enter content" />, in the administration state of the logical page we will see a request with a WYSIWYG editor (corresponds to the type article) and with the title "Enter content". In the state of content delivery (browsing) of the page, we will be shown the content of the contentblock container, entered by this request during administration.



If the field set of the data request form varies dynamically (depending on the state of the environment), we can use the field set call. For example,

<sapi: include href = "fieldset1.xml" parse = "fieldset" state = "admin" />

This construction will return a set of fields for requesting content corresponding to the admin state in the file fieldset1.xml.

What is the theory in practice?

It is quite possible, having read this far, you thought: “All these conglomerations look somehow scary. Interestingly, can anything at all on this framework really make money? ” In the distribution package with the framework comes a ready demo site. In addition to typical things, the site contains an example of an authorization / registration form using AJAX. The form also includes the possibility of authorization by OpenID. The site contains an example of advertising space for banners of mixed types (GIF / Flash / DHTML / RichMedia). There is also an example of using IntelliTXT technology. The terms entered into the thesaurus of the system are automatically converted in the texts of the site pages into tooltip links (double underlined links). When you hover the mouse cursor over a link, a window pops up with a hint. The system keeps statistics of hits related to the windows, so that this mechanism can be used for contextual advertising.
The demo site contains an example of a multi-level gallery with the ability to comment on photos. Voting is allowed for both photos and comments. An example of a catalog on the site demonstrates the possibility of grouping products by tags (similar products, tag cloud). In general, there is something to work with and, moreover, there is a certain basic set of solutions that can be safely used in your projects.