One of the most useful custom WFFM fields we use is a custom hidden token field. I’ve used this on several projects for various reasons.
Hopefully a very simple one, however unfortunately it is not possible to add snippets of text in the forms, only to the header/footer or section titles. We often have to provide additional details which may also include HTML links/content.
We solved this problem by creating a custom Label field. There is not suitable existing field to inherit and extend, but it’s such a simple field we can inherit from the
CssClassControl field as a base.
A common field requirement seems to be a checkbox which also allows some HTML text, such as when including a checkbox that the user agrees to some Terms & Conditions, Privacy or Legal policy. It’s usually a requirement that links to the policies are provided within the text.
There’s nothing out-of-the-box with WFFM but it’s simple enough to create a custom field.
This is a re-post of an answer I provided on Sitecore StackExchange.
Just before the Christmas break I got into a conversation with Robbert Hock on Slackchat about Sitecore fields and specifying a queryable source for the Treelist field in Sitecore 8.1. As you may be aware, several of the Sitecore fields support specifying an XPath query in the field source and others support an enhanced syntax using parameters.
From Sitecore 7.2 Update-2 the Treelist and TreelistEx fields also started to support specifying a query in the Source field.
Released Sitecore CMS and DMS 7.2 rev. 140526 (7.2 Update-2)
The Treelist and TreelistEx classes now support Sitecore query in the source for these field types. (319249)
In a previous post about extending Glass Mapper to handle custom data types I shared some code which I felt was overly verbose and I did not like the amount of code that had been copy/pasted. The example I used was a fairly trivial one, but it’s always good practice to try avoid copy/paste in case some point in the future the base implementation is changed. It might not always be clear to future developers how that piece of code had come about.
In that original post, Mike Reynolds (a.k.a sitecorejunkie) suggested use of the Decorator Pattern to wrap an instance of the base mapper and delegate some of the methods. Well it got me feeling uneasy and I finally found a little time to come back and clean that code up, I went a slightly different route and decided to use constructor overloading.
On a recent project I needed to add a couple of fields to Media Items templates in order store some additional data. We are using the Glass Mapper ORM in our project and out of the box there are two fields which we can map to: Image and File. I also needed to retrieve the file size, which neither of these fields returned either.
It turned out to be relatively simple to extend Glass Mapper and add our own custom data handler to map the additional fields.
On a recent question about storing custom field attributes for a field in Sitecore on Stackoverflow just over a week ago I suggested looking at the
Name Value List and
Name Lookup List field types. I have to admit that I have never used this field before, but knew of their existence and the general premise of the field.
If you are unaware of this field, it allows you to store Key/Value pairs of data. The underlying raw value of the field is then stored as url type parameters:
tl;dr Custom Field which hides other fields in the Content Editor depending on the selected value