IP.Content 2.3 development is progressing nicely. We are sticking to the four core points we wanted to address with the release of 2.3, namely: usability, consistency, SEO, and strengthening the existing feature set. All of these points tie in together and compliment each other nicely, and addressing these points together will allow for an easier to use and understand yet even more powerful product in the end. One of the existing features we have taken some time to improve with the release of IP.Content 2.3 is the relational database field capability available in any database (and in the articles system).
If you are not familiar with relational database fields, they allow you to easily "link" two databases together. A common example I like to give involves having a database of actors and a database of movies. Rather than typing out the actor names every time you add a movie, it makes more sense to add all of the actors to an actors database, and then simply select the actors when you add a new movie. Doing this allows us to link the database records behind the scenes, maintaining an association between the movie and the actors in the movie, in this example. While this association has not been capitalized upon to date, IP.Content 2.3 now provides some new functionality to make the relational fields much easier to use and much more useful.
Linked field is not the displayed field
One common complaint with relational fields is that no matter which field you select to link to, the title field is always what is displayed on the front end. Keeping with our actor database example, you might have the title field set to the actor name, but allow a separate field for stage name (which would often be the same as the actor's real name of course). When configuring your relational field, you choose to link to the stage name, as this is what users are going to know and look for, yet the dropdown/multiselect option on the submission forms and the displayed value when viewing the record after submission always show the actor name (because it is set as the title field in this database). This is not what our clients are expecting when they link to the specific field in the relational database, and we've heard you loud and clear. Beginning with IP.Content 2.3, the field you link to (in this example, the stage name) is what will be accepted on the submission form, and is what will be displayed when viewing the record upon submission.
Dropdowns and multiselects not always ideal
Naturally when you have specific allowed inputs, you have to implement a way to enforce the values sent are values that are allowed. If a user is adding a movie and you use a relational field to accept the actors for this movie, you want to ensure that they only supply names that are in your actors database. Dropdown fields are ideal for this purpose (or when accepting more than one value, multiselect fields), however what happens as the actor database grows? Eventually, you may have thousands of actors stored, at which point a dropdown or multiselect field will become virtually unusable.
Enter the type-ahead field. Relational fields will now have a third option for "Type of field" called "Type-ahead". When choosing this option, instead of a dropdown field or a multiselect field, you will see a regular text field. As you begin typing in an actor name, suggestions that match the characters typed will be displayed and will be selectable for the user. The new type-ahead field accepts more than one value, so after you select your first value and it is inserted into the text field, you can start typing the next value you wish to insert and select it as well.
Upon submission the values will be verified (to ensure that the names are valid for the relational field configuration), so you don't have to worry about random values that are not found in the remote database being stored.
Linking
Some users have expressed interest in linking the displayed relational field values to their associated records in the remote database. To continue with our actor and movie database examples, if you associate 3 actors with a movie, when viewing that movie it would be nice if the actor names linked back to the actor bio page automatically. Some users have attempted clever workarounds to generate the links themselves in the templates, only to find out that natural sorting is performed and thus ids and displayed values do not necessarily line up.
We have added a new option on relational fields (when configuring the field in the ACP) to automatically link the selected values back to their records in the related database. You should only enable this option if your related database is actually accessible on a page via the front end (remember that you can create databases that are ACP-only), however in this configuration (which is most common), this new option will make it much easier to cross link the values, giving much more value to linking to related databases.
As you can see in this screenshot, the values I submitted from my last screenshot are automatically resorted to be in alphabetical order, and they are linked to their related records in the actors database.
And reverse linking
So far the improvements described are all about fleshing out the relational fields to make them more useful and easier to understand. The last thing I want to talk about, however, will really enhance the usefulness of relational fields. You can now have records in the related database automatically reverse cross-link back to records pointing to them. As with the descriptions of the above changes, let's use a move and actor example to clarify what we mean by this.
You have a movies database and an actors database. When adding movies, you use a related field to point back to the actors in the movie. When viewing the movie record, it can now even link to the actor pages. Reverse linking takes the next logical step - it will automatically show all movies that the actor is associated with when viewing the actor page. This is a per-relational-field setting, so you do not need to make use of this feature if you don't want to, however it now gives relational fields much stronger value beyond their current implementation.
The future
Relational fields are a very powerful yet under-utilized feature of databases in IP.Content. We have been evaluating much feedback related to this feature, and as you can see above we have implemented many of the most commonly requested changes for this specific field type. We hope you find value in these updates, and look forward to your feedback and further suggestions on how to make this field even more powerful and useful.
Please feel free to share your suggestions for further improvements to relational fields or other areas of IP.Content in our feedback forum. Otherwise, if you have feedback about the changes described in this blog entry, we look forward to your comments below!