Thread

I like the idea of inline errors and I think eoghanobrien’s example of having them in some sort of conditional would be the way to go to assist with correct styling and also thinking about accessibility.

{exp:saef parameter="something"}

{some_field_tag}
  {if error}<span class="error">That name is not allowed</span>{/if}
  <label for="name">Name</label>
  <input type="text" id="name" name="{some_field}" value="{some_field}" />
{/some_field_tag}

{/exp:saef}

Let me echo some of the requests, for a: me too…
- On-page error-reporting (div with message) instead of clunky back button enabled specialty template.
- (possibly: inline error-reporting (e.g. marking fields red with css id’s and/or classes))
- Guest enabled forms, entries without login (with good file upload restrictions)
- Edit functionality (SAEditForm vs SAEntryForm)
- Set and override defaults for various fields like status, author, date, url_title or url_title-base
  and other required fields (secure as in parameter/tag, instead of hidden form fields)

Guest and general member upload brings up a general issue with the file-manager.
It needs sub-dir abilty for better file-management and definately better access-restrictions per channel.
(better as in: UI / inuitive / more user-friendly) but i guess that’s for another thread.

1. Custom field validation would be a plus. Validating a custom field titled “email” for example. With the help of the SafeCracker team (BNI), they helped me out in writing an extension that accomplishes this. BNI mentioned that they are rolling out server side validation options.

2. Also when you open guest users to submitting entries through a SAEF, it would be awesome of there was enforcement on duplicate entries by ip address in X number of minutes. Similar to how EE handles a user searching too many times in X number of minutes.

As other’s have mentioned, inline validation. The “let’s-go-to-an-ugly-error-page-out-of-context”, is just plain silly.
The other big thing would be to get rid of “field_id_75”. It’s bad enough that the database is set up in a retarded way, but that’s no excuse for leaking that abstraction on to us!!!

Why would EllisLab be responsible for inline validation?  Please, please don’t build this into SAEF and let developers roll their own.

Just give us your list and we will be good: 1)Editing ability 2)Third party field types 3) More customization

I don’t mean they should necessarily provide the inline validation, but they should make it possible. Right now, it’s not very easy to do that (although it can be done with some work, just too much work).

It’s just not that difficult in my experience.  No different than any other form. 

One thing I thought of, is with editing- that it could handle a subset of the fields, without overwriting existing field data.  So if I pulled just a few of the fields for my SAEF, the ones that wern’t pulled would remain intact.

It’s just not that difficult in my experience.  No different than any other form. 

One thing I thought of, is with editing- that it could handle a subset of the fields, without overwriting existing field data.  So if I pulled just a few of the fields for my SAEF, the ones that wern’t pulled would remain intact.

This is definitely a well needed request. This would then make it possible to have multi page edit forms which would be great.

Best wishes,

Mark

I never found it so easy. Out of the box, if something goes wrong with a saef, you will see the ugly out of context error page. There is no built in way to redisplay the form, on the same template, with the errors inline, and with the existing information still filled out.
To do this, you would have to use an extension hook, use the template class to redisplay the template, and then figure out how to get the errors on there.
To do it truly inline, you would either have to mangle with regexes, or put some kinds of placeholder on the page for the errors.
It would be great if there was a way to take advantage of a form building framework to handle all of this. I’ve never used CI’s form framework, but something like Zend_Form or Quick_Form.

If you do this is in a simpler way, please share!

I see what you are saying Avi.  I have had great luck with javascript, and it meets my needs, but you are right, something more complex would not hold up.  Thanks for the clarification.

more to the point - using JS as validation is not great if the user does not have JS enabled (or if they turn it off to avoid your validation attempts!). Server side validation in my eyes is stricter and safer.

For editing, it would definitely be nice to be able to have forms where users can update some of the custom fields while leaving others un-editable.

So you might have a channel that is used for some sort of business records. You might have a member group that is tasked with adding additional information to that record. So there might be a custom field that they are updating with their findings. The other fields might be read only fields (leaving the original data in tact) or there might even be fields that they can’t see at all.

So I would hope that the edit capabilities of the SAEF would be able to handle not displaying fields or having read only fields.

Incorporate JQuery Tools Forms?

Regarding validation, coding the form submission process at EE’s end so that server-side validation is possible is definitely crucial. Us devs can do our own javascript-based validation before the form page is submitted, so there’s no real need to integrate anything like that. However, making server-side validation possible seems to me to be simply a matter of POSTing the submission to a intermediary validation page, which processes things in the background and displays a “Processing form” message of some sort, and then either forwards the user on to the specified “Thank you” page if it validates, or re-POSTs back to the form along with an error message if it doesn’t validate.

Also, the server-side field validation requirements should be made accessible via tags to javascript, so that js-based validation can easily make use of the same parameters (max-length, etc).

1. SAEntry should use custom field names
2. SAEdit ditto, and should present existing content.
3. Both SAEntry and SAEdit should provide complete control over which fields are viewable and which are enterable/editable. The form designer should determine this.
4. SAEntry should provide methodology for pre-populating fields - pre-populated fields to be subject to 3 above. Pre-population can be “static” within the form design or “dynamic” via passed parameters. Two options for the latter, via url-segment or via embed variables. This is current functionality - just don’t lose it.
5. On-page validation
6. Tags to display field instructions
7. Control of redirect upon submit, with entry_id appended to URL
8. All field types covered, meaning that third party field type programmers need an API to easily conform
9. A graphical forms design interface would be nice - meaning an ability to lay out a form visually
10. There is an ever looming issue for redevelopment of existing sites with content that has to be imported. Using a kind of meta SAEF as a template for mapping csv and/or xml files to the new site’s entry structure would be awesome!