+1-888-365-2779
Try Now
More in this section
Categories
Bloggers
Blogs RSS feed

Under the hood: Why Sitefinity 4.0’s new Form Builder is awesome

by Gabe Sumner

The recently released Sitefinity 4.0 BETA includes a new Form Builder.  This form builder enables anyone to create web-based forms without writing a single line of code.  This is done using user-friendly drag & drop form elements and layouts. 

--

This is great, but there is a lot more to this story. Once these forms are created, Sitefinity is doing some incredible things under the hood.  To illustrate this, I’m going to create a new form:

Creating a new web form in the Sitefinity 4.0 BETA

Then create a basic Contact Us form (name, email, priority, message):

New form in Sitefinity 4.0 BETA

And publish.  We now have a new form.  Piece of cake!

Great!  But what just happened?

Behind the scenes, Sitefinity created a brand new database table specifically for this form. 

New table created by Sitefinity 4.0 BETA form builder

All new responses to this form will be persisted in this custom table.

By the way, if you’re wondering where those column names came from, check the Advanced Properties for the form element that was dropped onto the form.

Properties for a Sitefinity 4.0 form element

Why is this good?

Creating new tables for new forms is interesting, but why is this good?  Alternately, what is the alternative to creating new tables for new forms.  To address this, I’m going to use an analogy.

Imagine that you have 1,000 marbles, 1,000 rocks & 1,000 legos. 

A stupid analogy - Marbles, Rocks, Legos

The marbles, rocks and legos all vary in color and size.

All 3,000 of these items are then thrown into a big container.  Then comes a question:

How many blue marbles are in the container?

Answering this question requires you to separate the marbles from the items that aren’t marbles.  Once separated, you need to count the blue marbles.  If I turn around and ask you to count yellow legos, once again you need to first eliminate everything that isn’t a lego.  Valuable time is being wasted filtering items that aren’t related to the question.

This entire task would be easier if the marbles, rocks & legos were simply put into separate containers.  By creating a new table for new forms, Sitefinity is creating this new container.  This makes it easier (and FASTER!) for Sitefinity to retrieve this information.

Um, aren’t databases extremely good at filtering?

My analogy is going to look dumb to any DBA.  However, I’m simplifying to illustrate the concept.

In reality, a well defined database schema can easily deal with the example I above.  Databases are very good at eliminating data from a result set.  Consequently, although the task above would be hard for humans, it’s easy for a database to quickly filter well defined items. 

However, Sitefinity has another challenge.  In the example above, each item had 2 attributes (size & color).  Sitefinity needs to deal with an unlimited number of types and attributes.  The attributes used to describe a person, would be very different than the attributes used to describe a car.  We have no way of knowing (at design-time) what attributes you will invent for your web site.  The form you’re building in Sitefinity could represent anything. 

Consequently, a static database schema would need to be ultra generic (XML or objects that map to an arbitrary list of key/value pairs) to describe this unknown object.  This type of generic schema requires the database to do a lot of work to query the data.  This results in very poor performance.  To compensate for this challenge many CMS’s require heavily on caching.

Sitefinity is circumventing these limitations by created dedicated tables for new objects.

How is this being done?

To make this happen, Sitefinity is utilizing a powerful set of features found in Telerik’s OpenAccess ORM

  1. Artificial Fields
  2. Schema Change API

These new features allow Sitefinity to make database schema changes at runtime. Within Sitefinity, we’re calling this functionality Dynamic Data.  Furthermore, there is a whole set of Fluent API’s that can be used to interact with these dynamic data objects in very rich ways.

But what about…?

This is just the tip of the iceberg.  For example, what happens when form elements get removed and the database schema needs to change?  What happens when a form is removed?  Is data lost?  How can these objects be accessed using the API?  How can the database column names be modified?

We’ll explore these questions in future blog posts. 

12 comments

Leave a comment
  1. Patrick Julicher Aug 23, 2010
    Hi Gabe,

    Can the Table names for the forms be easily identified? Add Form_ as a prefix?

    GR, Patrick
  2. Neil Aug 23, 2010
    Excellent feature validation and spam protection will be the icing on the cake.
  3. Jay Buys Aug 24, 2010
    I agree with Patrick.  It'd be great if the tables had a prefix (sf_form_ maybe?) so that they could easily be found manually inside the database.  Altogether not a huge deal though.

    Very exciting feature.  Really looking forward to Sitefinity 4.
  4. Gabe Sumner Aug 24, 2010
    Hey Neil, I know validation features and spam protection is coming.

    Regarding prefixing table names, this seems like a reasonable suggestion to me.  I'll send this to the team and get their feedback.
  5. Lino Tadros Aug 24, 2010
    I would like to see the "Advanced: For Developer" section hidden on the edit pages unless you go to settings and turn on a Global setting called For Developers = true or something.  I don't think an admin working on editing these controls should see a section like this and not understand what it is for.
    Cheers
    Lino
  6. Ivan Osmak Aug 24, 2010
    Hello everyone,

    let me just clarify the thing about the table prefixing. Yes, we've forgot to implement this and the issue was discovered shortly before the beta release, so we've decided to leave it like it was. What we are actually doing at the moment is adding all these things to our dynamic data fluent API (table names,column names, indexes etc. - in short very fine control of the data structure). Once we implement that, we'll surely add these to the user interface.

    As a matter of fact, one of the product scrums is currently working on the dynamic data designer (control that will be used on several places in sitefinity) and that will let users define dynamic data (usages include: fine tuning of the forms, defining of the publishing points, definifing modules data structure - metadata from 3.x, etc.). We've had the internal discussions and settled on the simple/advanced mode as Lino suggested. The simple mode will have types such as "short text", while in advanced mode you will be able to specify for example "nvarchar(255)". 

    I hope this sheds some light on this issue.
  7. DigitalMan Oct 26, 2010
    Would love to see support for LinkButtons on forms as well. We don't use regular buttons on our forms because of styling issues with the rendered <input> tag.
  8. John Jan 16, 2011

    Hi

    Is it possible to add additional fields to the table created by the form designer? We are collecting job applications online and want to add additional flags and processing dates fields to the table for internal use.

    Thanks

    Regards

  9. John Jan 17, 2011

    Hi

    Is it possible to add additional fields to the table created by the form designer? We are collecting job applications online and want to add additional flags and processing dates fields to the table for internal use.

    Thanks

    Regards

  10. Ace Aug 09, 2011
    Hi,

    How do you activate the Advanced: For Developer option on editing the control name? mine cannot be edited.

    Thanks,
  11. Ace Aug 09, 2011
    Hi,

    How do you activate the Advanced: For Developer option on editing the control name? mine cannot be edited.

    Thanks,
  12. Ace Aug 09, 2011
    Hi,

    How do you activate the Advanced: For Developer option on editing the control name? mine cannot be edited.

    Thanks,

    Leave a comment