Jørn Wildt

I am in the process of creating two publication types: a Guestbook and a blog-like Journal. As I have been designing them, there have been some features that would be useful to me that seem to be missing. I'd like to know if these would be useful to others as well.

1) Template-generated Publication Input Forms. For entering data into a new publication instance, allow the use of Smarty templates.

Reasoning: Neither the guestbook reply field nor the Publish and Author information should be available to the guest as they are creating a guestbook entry. This gets back to how to allow untrusted users to enter data into our sites.

2) Template Fields for the input forms in #1: All publication fields should be available to the template designer including PubType fields, Publish information, Location information, and Author information.

Example: If we want the user to select the Topic for this publication via a drop-down box, there should be a way to easily insert a Smarty placeholder to do that.

3) Default Values: The ability to set default values for all fields. This should be true of those fields that we create as well as the standard pagesetter fields.

Examples: Approval state = Preview. Online = true. Publish date = create date. Expire date = Publish Date + 2 weeks. Maybe use PHP expressions for this. (Is it possible that we can already do this in Smarty?)

Question: Should defaults be at the field level, the template level, or both with template defaults overriding field defaults?

4) Input Validation: We should be able to attach input validation rules to each field. Even though this is listed last, it is my highest priority.

Examples: Mandatory fields. Valid dates. Date must be within range. Date must be before a week from Tuesday. Numeric ranges or lists. Valid email address if filled in. Valid URL. Possibly allow PHP expressions here also for flexibility.

What do others think?

I would like to vote for "1.Template-generated Publication Input Forms." because I really miss such feature.
BTW with such feature (predefined input form) we can define both default values and hidden values for field which is not visiable to users!

I do absolutely agree that Pagesetter should have a separate submission form with permission requirements that do not overlap the rest of Pagesetter.

But I am a bit reluctant to use Smarty for generating input forms. This may be fine for forms with no backend handling, but as soon as you want some serious form validation, as Tony mentions, you need some more.

This "more" is what I have spent a lot of effort putting into the Guppy forms API used for (almost) all Pagesetter input today. The Guppy system adds all the validation features (except regex matching and date ranges, but that should be relatively easy to add) with a simple XML form description ... at the cost of design control. At the sime time you also get the date picker and image selector etc. - all that the pagesetter input can do.

For some ideas of what Guppy can do at this level, then check "pagesetter/forms/*Layout.xml". The Guppy field Specs and Handlers will be auto-generated from the pub. type setup.

So I vote all the features, but without Smarty.

Having said that I think Smarty should be supported too - for all those that have spent time learning Smarty templating. But I am not going to reimplement all the validation again.

I just visited the forms directory for the first time and am very impressed with how versatile guppy seems to be. Between the layout, spec, and handler files, it seems really flexible. I'd love to learn more about things like the $event array and what properties are available for <field> tags.

J?rn, if you wouldn't mind getting me started understanding the design of guppy, I will help with documenting it from a programmer/designer perspective. I have a vested interest in understanding it since I want to begin using it to design input forms :cool: </field>