CMS Made Simple Forums

Using the "block" parameter to the "content" Smarty tag makes it possible to create templates that result in a relatively easy-to-use data entry form when editing associated pages.  However, there are a few enhancements that would make this feature more useful:

• Enable the user to specify a default value for a given content block.
• Omit the editor for the default content block if the template does not include any "content" Smarty tags that do not have a "block" parameter.
• List the text entry fields or text areas in the order in which they occur in the template.  While this already happens by and large, the "default" content block (i.e. the one without an explicit "block" parameter) is always listed first.  This breaks up the logical order of the page as given in the template and may be a real usage problem since the default content block is a text area that may require the user to scroll down to see any other data entry fields.  In that case, they will frequently fail to edit the additional fields.
• The last point suggests that an additional parameter may be useful to indicate "required" content blocks.
• It may also be worthwhile to be able to specify type validation for content blocks (e.g. integer, date, time, etc.) However, to be fully useful, it would probably be necessary to enable the template developer to write custom validators and then associate them with content blocks as needed.

Note: This has already been submitted as an enhancement request.  However, I am repeating it here for discussion in the forums.

To make this feature request a bit more concrete, I am proposing that a "default" parameter be added to the "content" Smarty tag so that it could be used something like the following:
For long default blocks, I would prefer the following:
However, it looks like Smarty tags with open and close tags must always have the pair.  From what I could see in a brief look at the documentation, it does not look like the implementation of a Smarty tag provides a good mechanism for distinguishing a complete tag from a tag with the same name that is only the opening tag of a matched pair.  If anyone else knows better, please chime in.

Therefore, it looks like long default values should be assigned to a variable and then that variable used with the proposed "default" parameter:
Once the form of the enhancement to the "content" tag has been settled, there is still the matter of when the default content is used.

It should only be displayed in the following circumstances:

• When a new page is first created.
• When a page is edited after an associated template has been edited to add a new content block with a default value specified.
• When a new template has been associated with an existing page and it contains a content block with a default value specified and that content block did not exist in the previously associated temple.

(In the second and third case, should existing pages be assigned content blocks populated with the default value for content blocks not previously associated with those pages?  What about deletions?  My understanding today is that content blocks for pages that are no longer referenced within an associated template remain in the database and that there is no current mechanism for removing orphaned content blocks.)

Now, most of those circumstances can probably be determined by detecting whether or not a content block already exists in the database for a particular page.  However, there may be more subtleties to the problem than that.  The one thing that is certain is that zero-length content (i.e. any empty string as distinct from a nil or null value or reference) is not sufficient.  "Blank" values must not be replaced by default values even if there were an implemented mechanism for specifying "required" content.

A nice-to-have feature may be to have a way in the page editing panel to click on a button or other control to revert a text area or text input field to the default value for the associated content block if one is specified.  At least that is probably easier to implement than the logic for when to automatically assign the default value on first use.

If anyone is sufficiently familiar with Smarty tags, implementing new tags, the current "content" tag, or any other relevant concern, please provide an opinion as to how much work something like this would be to implement.