Thread

It’s no secret that the release of ExpressionEngine 2 revealed some limitations in our current Stand Alone Entry Form (SAEF). In large part, this is due to our new approach to custom fields and the resulting variety and potential complexity of new field types. Believe me, we are as frustrated with it as you are.

The current approach just isn’t cutting it and putting band-aids on the code isn’t a ‘fix’ we find acceptable. We also have to acknowledge that Add-ons have been needed in the past to get the most out of even the 1.x version. So we’ve decided to step back, take a deep breath, and look at the SAEF with fresh eyes.

Here’s where we need your help, and where you can help us shape the next incarnation of the SAEF. 

Our short list of goals:

Read More

Redirect with appended entry ID in URL please (AKA http://www.solspace.com/software/detail/saef_redirect/)

I would like to see the ability to submit form data from visitors who don’t have an account / aren’t logged in. 

Several of my clients want to be able to have form submissions readable / analyzable directly from the database and not via their email inbox.

At present, I have to purchase Safecracker to get that functionality.  And Safecracker’s a great bit of code, but it’s silly to have to purchase it for that one reason.

The SAEF’s should be done similar to how the User module works. As you mentioned, editing an entry needs to be easier, preferably the same template can create and edit an entry. Fieldframe gave us usable custom fields in SAEFs, and since the Fieldtype framework was basically inspired by Fieldframe, then it’s only proper that it works in SAEF too. I honestly didn’t see much wrong with the SAEF’s in EE 1. Editing was just a pain, and that {custom_fields} loop was silly, but other than that it worked how I expected it to… it included JS when needed, and stayed out of the way. I would prefer not t have a {custom_fields} loop, and just be able to create the entire form by hand, and include only the fields I want.

{exp:saef:publish channel="foo" not_required="body|somethingelse"} // Can override what is set as required in the field creation page
<ul>
<li>
<input type="text" name="title" value="{title:value}" />
</li>
<li>
{exp:saef:field name="body" fieldtype="wymeditor"} // All necessary JS, images, css etc is loaded
</li>
</ul>
{/exp:saef:publish}

{exp:saef:edit channel="foo" entry_id="{segment_2}"}
<ul>
<li>
// Or for default fields?
{exp:saef:field name="title"}
</li>
<li>
{exp:saef:field name="body" fieldtype="wymeditor"} // All necessary JS, images, css etc is loaded
</li>
</ul>
{/exp:saef:edit}

I also agree that it would be great not to require a logged in member.

And, personally, I prefer *less* predefined markup and more template tags. To me that follows in the spirit of EE more closely.

Thanks for asking our advice!

Less predefined markup, to give the flexibility for device-specific forms depending on the client: desktop, different mobile, etc.
Having said that, it does not necessarily has be more tags OR more markups. Sensible defaults that can overriden through tags go a long way.

Also… not sure if it related to the SAEF code but your post suggest you want to implement a complete solution that lessens the reliance on plugins and hacks: when someone edits through the CP, the edit are immediately live on the site. Fine, pressumably (s)he is someone with enough ranking.
However if editing through the SAEF then his/her edit should be stored as an hidden version to be validated by a more senior editor. Until it is validated, the last approved version remains live.

Personally I like to code my forms from scratch. I like having complete control over them. This goes for the register member form and SAEF as well. Having complete control over the markup means I have complete control to style it as I see fit. This also means I can use the javascript I want to without silly limitations.

Naturally we all want custom fields in there and I prefer adding them myself without the need of a control panel or predefined templates. I repeat.. 100% control is where it’s at 😊. I recently created a custom registration form at teoriaunderground.com and determined that the basic form has way too many fields. In all the form has at least 6 fields and that’s just not the best way to get users to register quickly. Luckily we can code our own forms and with the help of some quick jQuery code I was able to hide 3 fields and replicate them once submitted. Now I have a 3 field registration form and users are piling up.

I agree with all posts up to this point.

- less defined code, I wanna write my own as much as possible
- none logged in users
- custom fields

After going through the usage docs of SafeCracker, I would say that the guys at Barrett Newton pretty nailed it.
- much control over the return URL
- non-logged in users
- CI Form validation
- add and edit entries

The only thing that’s not there is some funky onblur live validation and a generator that, depending on the channel you choose, spits out a base SAEF template based on the custom fields of the selected channel.

Adopting SafeCracker, helping it out of beta, might save quite a lot of development time that can be used for other much needed stuff like the file manager.

Related fields please, why build relationships if you can not work (edit) on them…and file attachments, really freeform (as great as it is) should be handled by the SAEF and entries.
I don’t mind extra tags and doing it by hand as long as I *can* get it done without monumental decisions such as ‘to use weblogs or some other table structure and loose weblog tags’.
Forms module? 😊
Thanks.

I’ve been bugging you guy’s about SAEF through BETA and ever since; including emails to Leslie who indicated to me 2 months ago that it was a top priority. So I’m shocked to hear it’s back to the drawing board on this one. Why don’t you try and License SafeCracker for $10000 and be done with it - gota be fair to the guy’s over there 😊

The more I think about this the more I’m dismayed; you’ve had development, private beta, beta and the best part of 4 months since to get this sorted.

Template tags are preferable to predefined code… within reason
I agree about preferring more template tags instead of predefined code, but I think it has to be with the condition that it’s reasonable; for example, I certainly don’t ever want to have to re-create Pixel & Tonic’s Matrix or Playa fields just because we clamored for no predefined code. :p Allow us to have maximum manual control over the basic, standard form controls (text, textarea, dropdowns, multi-selects, radio buttons, checkboxes, etc), but don’t hinder 3rd party fieldtypes from easily providing whatever pre-generated code they need in order to function (encouraging them to code things in an easily CSS style-able manner would be nice… 😉 ).

Enforce non-destructive partial content update support
IIRC, when using SAEditFs in EE1 (can I coin that partial acronym?), if existing categories were not re-specified in the code, they would be deleted from the entry upon submission. I think a better solution would be one where the deletion of already existing field values requires specifically assigning “NULL” or something like that, and that merely omitting a field from a SAEditF would not empty out that field’s existing value upon submission. In other words, have SAEditF’s update existing content instead of resubmitting it from scratch.

Allow maximum access via tags to custom field properties
While having {field_name} be replaced with that field’s contents is great (and obviously core to EE), how about expanding that general idea (not just in the context of SAEF’s, either). Give us {field_name:label}, {field_name:instructions}, {field_name:maxlength}, {field_name:text_formatting}, {field_name:text_direction}, {field_name:required}, {field_name:searchable}, etc. Allow 3rd-party fieldtypes to build on top of that with their own specific properties (such as Wygwam’s Upload Directory or Matrix’s Maximum Rows).

Form Validation should be easy to base upon pre-defined custom field properties
Continuing from the previous point, a {field_name:required} tag (or equivalent) would be crucial for form validation, and I imagine a {field_name:maxlength} would also be helpful. Check out the “Forward Thinking Form Validation” article on A List Apart with an eye for making things future-ready as well.

Thanks for asking for our input (pun intended :D)!

Agree strongly about licensing/purchasing SAEFcracker; at least making a generous, good-faith offer for same. So very much else to do for EE with limited resources; *please* don’t reinvent a wheel already crafted, purchase it and work on the transmission, steering or the interior-exterior design 😉

I hope it’s an assumption that when you (EllisLab) is referring to SAEF, that it means both Standalone Entry Form and Standalone Edit Form. In 1.6 this was a pain to try an handle separately.

In regards to the coding of forms, I like the ability to code them myself to specify which fields are displayed and which are not (or at least hidden based on context of previous input). That also allows me to do JS/jQuery validation myself and specify other ajax type fields which will only display when particular selections from other inputs in the fields are specified.

I’m using SAEF’s for input of data from Guest users, so this functionality is a big requirement (e.g. warranty registrations, competition entries, promotions). The problem at the moment on this front is getting {captcha} to work (my main experience has been with EE 1.6.x).

Email notifications, ala Freeform, would be a brilliant addition to the SAEF module. Being able to setup email templates that sends a response to the admin, as well as the user would be fantastic (and using the EE templating engine as well). At the moment I’m using Solspace Entry Notifications, tweeked to allow for notifications to a specified email address when users are ‘Guests’.

Right now I can’t recall if it was possible within SAEF to change the status on an item, if it is, great, if not, then that would make a nice addition too.

Cheers

Many thanks for asking - this is what we want!

My 10p’s worth…

1. I want to control the markup as far as possible, so template tags is the way to go
2. Option to use existing field names and descriptions if desired
3. Need to be able to upload files, but not necessarily allow authors to access the file manager which should be optional. Perhaps the ability to restrict a file field to one upload destination?
4. Inline editing would be totally awesome!
5. Ability to only allow editing of certain fields (if a field doesn’t appear in the form leave as is)
6. Adding a version for editing member profiles would also be very useful