Invenzzia... in English - Tag - OPF

A closer look at Open Power Forms

Zyx — Sun, 06 Sep 2009 09:20:00 +0200

After releasing the first stable version of Open Power Template, we gained an opportunity to focus on other Invenzzia projects as well. One of the new enterprises is a form processing library which has been given a name Open Power Forms. In the last days, I managed to implement the basic functionality and run the first test files and I would like to introduce you in the new project. From this entry, you are going to get to know, what OPF actually is, what are its benefits and main goals and what has been implemented so far.

Open Power Forms

Open Power Forms is a form processing library. It manages the logic behind the forms and allows the programmer to create them with a set of simpler rules. He simply defines what he would like to see there and waits for the input data. The complete task list of a form processor can be found below:

Providing a system to define the content of a form and its behaviour: validation rules, data filters, information messages etc.
Rendering the form in the HTML format.
Validating the input data and filtering them in order to prepare them to be processed by the application logic layer.
Validation error handling and informing the user about the problems.
Managing the form layout.

As you can see, form processors play an important role in a web application. Most of the communications between the user and the script passes through forms and having a good management system for this element should be necessary. We get the unified set of rules and behaviours which speeds up the development process and eases the mainternance.

The goal

The web frameworks usually introduce their own form processing system, but sometimes is too simplified to satisfy the requirements. An example of such framework is Kohana, where we have validators, view helpers and nothing more - it is our task to build and implement the whole logic, using these elementary blocks. The other ones provide a convenient API, but lack of the more advanced features, such as multi-page forms or offer a limited choice of widgets, validators and filters. In this group the best example is Zend_Form, a part of Zend Framework. The last important problem concerns the rendering system. It is very easy to display a form, but hard to customize it. Zend_Form forces us to use massive OOP and design patterns in order to customize the HTML code which can easily break the MVC pattern by moving the view tasks to the logic or controller layer. At the same time, sfForm from Symfony provides a concept of template templates, small files written in PHP that are compiled by the extra compiler to build the form layout. Anyway, if we want to customize the look, we have to be prepared to lots of coding in PHP. The main disadvantage is that the developers of freamework-based solutions usually have no time to provide a more generalized solution which leads to wheel reinvention and the problems with code refactoring.

And we want to create a general-purpose form processing library free of those disadvantages.

OPF features

The key features of Open Power Forms are the form management logical model and the rendering algorithm. We begin with focusing on the first issue. Most of the form processors treat the form as a list of atomic fields, sometimes grouped. It is very easy to implement such a form processor, but it cannot handle more advanced forms. Let's imagine the column insertion form in phpMyAdmin. It allows the administrator to add several columns at the same time by multiplying the same form several times in the table rows. Other web applications may use multi-step forms, where the user fills the form called "Step 1", then goes to "Step 2" and so on. The entire data are processed after filling in the final step. What is more, some steps may be activated only if the user made a certain choice in the previous ones. The better model to represent such situations is to unify the concepts of a form and a form field. Open Power Forms formally makes no difference between them. We are allowed to append one form as a field of the other form, guaranteed the library will recognize our intentions.

If we are talking about not-reinventing-the-wheel in the form rendering issue, we must throw away all the ideas that do not work in the other libraries. They rely on PHP and they fail, but we already have a great template language provided by Open Power Template. It offers us some brilliant features, very useful in the form rendering, that is components and snippets. The component system has been designed especially for forms - we work there with components, which are various form widgets, such as input fields, select lists, radio buttons etc. Components separate the field logic (managing the labels, IDs, attributes, errors etc.) from their presentation. The field logic is implemented in a PHP class, and the presentation with a component port in a template. A sample port looks like this:

<opt:inputComponent name="foo">
  <div>
    <label parse:for="$system.component.id">{$system.component.label}</label>
    <opt:display />
    <opt:onEvent name="error">
       <p class="error">{$system.component.error}</p>
    </opt:onEvent>
  </div>
</opt:inputComponent>

In the example above, we create a statically deployed port, where the template automatically creates a component object for it, using the tag name (opt:inputComponent). But we have also standalone ports, where we load the component from a template variable, and the component itself may be created with a script. In both cases, the content of the XML tag remains the same. What is more, we can use snippets to save the form layout in one place and simply insert it in all the ports of all the forms we have:

<opt:snippet name="fieldLayout">
  <div>
    <label parse:for="$system.component.id">{$system.component.label}</label>
    <opt:display />
    <opt:onEvent name="error">
       <p class="error">{$system.component.error}</p>
    </opt:onEvent>
  </div>
</opt:snippet>

<opt:component from="$variable" template="fieldLayout">
  <!-- we can set some attributes here -->
</opt:component>

At any time, we may decide, whether to implement a field-specific layout for particular components or use the default ones. Moreover, we operate on simple HTML with some extra tags without the need to create hundreds of files and deal with the implementation details, as OPT hides the unncecessary logic from us.

Open Power Forms is going to provide a set of OPT-compatible components integrated with the form processing system, plus some extra tags, data formats and functions for designing forms and managing their layouts. Below, we can see a working template that uses the new features:

<?xml version="1.0" ?>
<opt:extend file="base.tpl">
  <opt:snippet name="title">Situation 1</opt:snippet>
  
  <opt:snippet name="content">
	<!-- configure CSS styles for the elements -->
	{$design.form.valid is 'form'}
	{$design.field.valid is 'row'}
	{$design.field.invalid is 'row row-error'}
	{$design.input is 'inputText'}
	
	<!-- display a form -->
	<opf:form name="form1">
		<div class="errors" opt:if="not $system.form.valid"><p>The form is invalid.</p></div>
	 
	 	<!-- load the components assigned to the "default" placeholders -->
		<opt:section name="default">
 			<opt:component from="$default.component" template="widget">
			</opt:component>
		</opt:section
		
		<!-- some final stuff -->
		<input type="submit" value="Submit" />
	</opf:form>
  </opt:snippet>
</opt:extend>

And here is the PHP part of the form:

class My_Form extends Opf_Form
{
	// An event
	public function onInit()
	{
		$item = $this->itemFactory('title');
		$item->setRequired(true);
		$item->addValidator(new Opf_Validator_Length(5), 'The length is invalid');
		$item->setWidget(new Opf_Widget_Input)
			->setLabel('Title');

		$item = $this->itemFactory('countries');
		$item->setRequired(true);
		$item->addValidator(new Opf_Validator_Type(Opf_Validator_Type::INTEGER), 'The field type is invalid.');
		$item->setWidget(new Opf_Widget_Select)
			->setLabel('Countries');
	} // end onInit();

	// An event
	public function onRender()
	{
		$view = $this->getView();
		
		$item = $this->itemFactory('countries');
		$item->getWidget()->setOptions(array(0 =>
			'China',
			'France',
			'Germany',
			'Great Britain',
			'Poland',
			'Russia',
			'Spain',
			'United States'
		));
	} // end onRender();

	// An event
	public function onAccept()
	{
		$view = $this->getView();
		$view->setTemplate('results.tpl');
		$results = array();
		foreach($this->getValue() as $name => $value)
		{
			$results[] = array('name' => $name, 'value' => $value);
		}
		$view->results = $results;
	} // end onAccept();
} // end MyForm;

The list of core features:

Flexible design - the forms can be constructed either by extending the base form class or by configuring the bare form object and responding on the events.
Event listeners - they can be used to implement the logic of common form parts by extending the initialization or rendering events. The concept is similar to event listeners and behaviours in Doctrine ORM.
AJAX support - the AJAX requests could be implemented as ordinary form events and the library will set up the entire communication process.
Huge (and useful) set of widgets, validators and filters.
Web Forms 2.0 support.
CSRF attack protection.
Support for complex forms: multi-step forms or forms built of smaller forms.
Doctrine ORM support out-of-the-box.
Full integration with Open Power Template library.
Internationalization support.
Integration with Zend Framework thanks to the already available OPL port for Zend Framework.

Current status

The library currently implements the most important core features, such as data validation, error reporting and form rendering and is able to process simple forms. We are currently working on extending the logical model in order to support more complex forms and their proper rendering. In the very near future, the first development version will be released. We would appreciate any suggestions and ideas.

Conclusion

The goal of Open Power Libs project is to develop innovative PHP libraries. The success of Open Power Template has shown us that there exists a demand for solutions that break the stereotypes and give the programmers a fresh point of view of the well-known issues. Open Power Forms is a next step towards satisfying them and developing a complete presentation layer for web applications.

Invenzzia Summary #5

Zyx — Wed, 08 Jul 2009 13:28:00 +0200

Welcome back after a short break. Although there were no summaries in the last month, Invenzzia projects are still active and maintained. We have released two new versions in June, and now we are reaching the moment of releasing... the first stable version of Open Power Template 2! Stay with us and read more about the progress and the current status of the projects.

Open Power Template 2

The project is actually finished and we are expecting to deal with all the formalities in the next few days. There is only one chapter missing in the user documentation and if you would like to check the code right now, you can find it on our Subversion repository. So, what would take so long? The answer is simple: the tutorials. Since April, I have been working on a huge article entitled "A photogallery with Doctrine and Open Power Template 2.0" showing the process of writing a web gallery using the libraries mentioned in the title. Furthermore, it is going to be available in two language versions: Polish and English. We have to finish the translation and rewrite it into Markdown, so that it could be published on Invenzzia. Anyway, the development process is over and now we can focus on implementing the new features and the new libraries.

TypeFriendly 0.1.2

A couple of weeks ago, we released TypeFriendly 0.1.2 with many new features, such as appendix support and tag manager. Since then, there were new commits and new works-in-progress. eXtreme improves the layout of the chapter headers, there are expected new tags and fixed some minor bugs.

What's next?

I plan to finish the caching system for OPT that will be distributed with Open Power Classes, and start developing the source code of long-awaited Open Power Forms. We have an idea, what we want to get and how to achieve the goals.

Invenzzia Summary #1

Zyx — Fri, 10 Apr 2009 22:02:00 +0200

This is the first episode of the Invenzzia Summaries, a way to inform about various events and activities of Invenzzia Group and the development of the open-source projects. We will try to publish them regularly, but the exact period depends on the amount of issues worth concerning. In the first episode, we will talk about the last beta version of Open Power Template and the new projects that are going to use it.

Open Power Template 2,0-beta3

This is a pretty fresh news, because the packages have been published about an hour ago. The new and the last beta release contains lots of various bugfixes and improvements, such as new, more stable section implementation or data formats. Finally, the entity issue has been also solved once and for all. We have decided to use the XSLT model, where the entities are parsed on the server-side, and only the special XML characters appear as entities in the output. The end user will see no difference, especially if he/she uses Unicode. For those ones who need to display a particular entity in the output, there is a new function: entity(). Please note that it must be used with the escaping turned off, for example:

<p>The entity: {u:entity('Acute')}</p>

The new version can be downloaded from here.

The remaining issues in OPT.

One could ask, what needs to be checked in OPT before the first stable release will appear. Well, the library is already pretty stable now, after some recent bugfix parties and significant effort taken by the users in finding them. The only feature that has not been tested yet is the cache interface port. Furthermore, there are some unit tests still to write and the documentation to finish. Currently, the test suite consists of about 400 unit tests, but there are some areas that are poorly covered with them:

Template functions.
The standard data formats.
XML node manipulation API.

Now, just to finish the remaining jobs and release the first stable version.

Who uses OPT?

Recently, the development team of Extreme-Fusion CMS announced that Open Power Template 2 will be the primary template engine in the new version of their project, EF V. Extreme-Fusion is a quite popular Polish CMS, a fork of PHP-Fusion. The new version is going to be rewritten from scratch on the Kohana framework and OPT 2. Those who know Polish, may read the announcement on their development blog (unfortunately, they do not provide English-language version, like Invenzzia :( ).

Another application that uses OPTv2 is the project with the codename "Arbiter". It is a system for AGH University of Science and Technology in Krakow that allows to organize programming competitions and automated program testing for computer science students. Because I'm involved in its creation, I'll try to write more about it in the next few days, as the first version is going to be run soon. The application is built on Zend Framework, Doctrine and OPTv2. It has been used as the prototype for the OPL4ZF port and the experimental field for OPTv2.

What about Open Power Classes?

The "Opc" directory remains empty on SVN, however this should change in the near future. The problems were caused with the huge amount of work with OPT debugging and I couldn't find more time to push this project, too. Moreover, I'm preparing the UML design for Open Power Forms, a form management tool based on OPT. I'll try to publish the results in the next two weeks.

Polish support improvements?

A few days ago, two users contacted Invenzzia asking for the possibility of establishing a better Polish-language support. The support concerns translating the original English materials into Polish on a secondary wiki. Currently, we are thinking, how to set up a bilingual infrastructure. We are pleased that the Invenzzia community grows constantly and becomes more and more active, however it would be nice to see more non-Polish users here. As you can easily notice, the main language is English and receiving support in this language is as easy, as in Polish. The Czech and Slovak users may also attempt to contact in their native languages, as one of the team members knows Slovak and may understand them :).

Conclusion

This is the end of the first Invenzzia Summary. I hope you have enjoyed this form of providing the recent news and issues.

Deeper processing

Zyx — Thu, 31 Jan 2008 13:42:00 +0100

The last project I've created using Open Power Forms, shown some weaknesses of the current form implementation. There were some forms allowing a mass addition of many records in the following way: a table, in the columns the following fields: Name, Surname, PESEL number, etc. The numer of rows was 30, so the user is able to add 30 people to the database with one form. The adaptation of the map() method to my problem was not too hard; in fact it seemed that opfArrayContainer solved everything. But then the form renderer connected with Open Power Template went off.

My code looked like that:

php
$this -> map('names', new opfArrayContainer(
	new opfConstraint(MAP_TYPE, TYPE_STRING),
	new opfConstraint(MAP_LEN_GT, 2)
), OPF_OPTIONAL);
$this -> map('surnames', new opfArrayContainer(
	new opfConstraint(MAP_TYPE, TYPE_STRING),
	new opfConstraint(MAP_LEN_GT, 2)
), OPF_OPTIONAL);
$this -> map('pesels', new opfArrayContainer(
	new sConstraint(MAP_PESEL)
), OPF_OPTIONAL);

In other words, the script must have received for example the "names" field, which was an array of 30 elements with the names. If the user made a mistake while filling in the form, the form renderer did not have a clue, which component to display as invalid (in this case it should be colored red instead of green). Finally, I added a support for the IGNORE_OPF_ERRORS constant so that shut it up and just display everything without all this color rotation stuff.

Of course, it is not possible to keep this problem unsolved in the "public" releases and I decided to look for solution. It would be nice, if the improvement easily matched to the code, as well as was intuitive. It's not a problem to add something in 20 minut and a month later self-wishing a rapid death. The best solutions are simple and effective, so I started to think, how to describe a form with some definitions and transformations, so that it would be possible to construct every form and process it with OPF. My idea is to go somewhere deeper and remove distinguishing between forms and form elements. The reasons:

Both have a value (in the form case we define it as a set of subelement values).
Both have a state.
Both can be processed.

Now we can easily treat a form as an element which is capable of storing other fields. If we try to build our form described above, it will look like this: we create a form for a single person: name, surname, PESEL, etc. Next, we put it into a bigger form and order to loop up to 30 times. We can also achieve an effect of looping a single field, like it was possible with opfArrayContainer() so far. We just put in such loop not a form, but a single element.

Well, now the problem is, how to render it :). However, I don't think it will be complicated, especially if I look at the new Open Power Template.