Reflex — Templates, Part 2

In my previous entry about Reflex templates, I talked about how database queries are built to fit the template needs. From a web application framework developer standpoint, this means less code is needed to control page display. It also gives more flexibility to the template designer who is no longer limited by what the application developer makes available to him. But this template-does-the-query principle can be pushed even further. Now let’s build a form!

Creating a form is dead easy in HTML. Creating a form that works however require some programming skills on the server side. Well, not so with Reflex templates. Write your form just as you’d write an static template and it’ll work:

<rx:form>

<p>
<label>
  Entry Title:
  <rx:input type="text" source="entry/title"/>
</label><br />

<label>
  Entry Content:
  <rx:textarea cols="80" rows="20" source="entry/content"/>
</label>
</p>

<p>
  <rx:input type="submit" perform="update"/>
  <rx:input type="submit" perform="delete"/>
</p>

</rx:form>

Notice the <rx:input> and <rx:textarea> tags. They take the same attributes as HTML’s <input> and <textarea> tags, and will sent rendered as such to the browser with small transformations. Each of them will automatically get a name attribute. First <input>’s value attribute and <textarea>’s content will be filled with the data found where the source attribute points to.

The <rx:form> element will be changed to a standard <form> with an added action attribute current location and a method="post" attribute. The two last <rx:input> have a type="submit" attribute and will be rendered as buttons by the browser. Because they have no display name, Reflex fills the value attribute of the two submit buttons.

Finally, when you submit the form, Reflex takes all the inputs and calls the action associated with the perform attribute of the clicked button. And you’ve updated, or deleted, your entry.

But wait a minute, isn’t that totally insecure? What if I don’t want people to delete my entries? The obvious answer would be “remove the delete button” which, of course, does nothing to prevent a malicious user from sending faked input that will perform the action anyway. Or is it? If you remove the delete button, Reflex will no longer accept to perform a delete action from this form. This is totally WYSITFIAYCDWTF — What You See In The Form Is All You Can Do With The Form.

There is more.

What if you want to edit all your entries at the same time… how’d you do that? Well, it’s as simple as if you wanted to display all your entries on the same page; wrap your inputs in a list:

<rx:form>

<ul>
  <rx:list source="weblog/entry" as="entry">
    <li><rx:input type="text" source="entry/title"/></li>
  </rx:list>
</ul>

<p><rx:input type="submit" perform="update"/></p>

</rx:form>

Isn’t it nice? Note that instead of <rx:list> with some attributes, I could have used the shortcut <rx:entry-list> as I did in part 1.

So you can make pretty much any kind of form with this template system. The best part is that they are handled automatically for you. It’s powerful enough to make the entire Reflex administration interface work with this.

You may have noticed that all these examples are about weblog entries. That does not reflect any limitation: Reflex will be capable of handling all kind of data this way. How the data is stored and how different actions are performed is defined by modules. That will be the subject of my next Reflex entry.