Fill_In Max length attribute

[kevdev424]

Sen. Roy Blunt and Rep. Bob Dold have a maximum length limit on their message boxes, although you'd only know after the message gets rejected on their server. To accommodate this restriction in the YAML, I was thinking it could be as simple as adding a max_length attribute to fill_in. Our apps could then truncate as needed.

Thoughts?

[j-ro]

Sure, makes sense to me. We tend to just ignore these and in our UI encourage shorter messages. We only see a handful of failures. But truncation isn't a bad option.

[crdunwel]

Not to hijack this issue, but there are other related issues in the repo (such as #1294) that deal with the format of input. Another case of validation failure is with phone number formats (xxx-xxx-xxxx vs xxxxxxxxxx). These cases as well as input length can be captured by an regex. For instance, /^.{0,2000}$/ will match anything between 0 and 2000 characters.

The advantage of using regex is that they're concise and powerful and will only add one attribute. The disadvantages are that writing them may require more technical expertise for contributors and one may not always be able to easily deduce a regex from errors on a webform. For instance, Tom Udall was only accepting emails from original top level domains and a subset of newer ones as of a few days ago. Exhaustively including each domain in the regex in this case would require a lot of trial and error and a long regex.

So perhaps an attribute like regex_accept, regex_validate, or even just regex may be a more robust way to validate?

[j-ro]

I think the issue with having one attribute for many cases like this is on the display side for the user. It's hard to transform a regex into a, say, input label so the user knows what to type. But maybe I'm misunderstanding here how this might work.

On Apr 28, 2015, at 11:43 PM, Clayton Dunwell [email protected] wrote:

Not to hijack this issue, but there are other related issues in the repo (such as #1294) that deal with the format of input. Another case of validation failure is with phone number formats (xxx-xxx-xxxx vs xxxxxxxxxx). These cases as well as input length can be captured by an regex. For instance, /^.{0,2000}$/ will match anything between 0 and 2000 characters.

The advantage of using regex is that they're concise and powerful and will only add one attribute. The disadvantages are that writing them may require more technical expertise for contributors and one may not always be able to easily deduce a regex from errors on a webform. For instance, Tom Udall was only accepting emails from original top level domains and a subset of newer ones as of a few days ago. Exhaustively including each domain in the regex in this case would require a lot of trial and error and a long regex.

So perhaps an attribute like regex_accept, regex_validate, or even just regex may be a more robust way to validate?

—
Reply to this email directly or view it on GitHub.

[kevdev424]

@j-ro agreed

[crdunwel]

@j-ro ah yeah, good point. It would be easier for people to contribute too. To mirror the HTML attribute, we could make it maxlength.

[j-ro]

I guess there's a question here of what we're measuring exactly. I think the ones I've seen are measuring words, not characters? Which if true makes things all the harder -- the way I count words might not be how they count words.

Might want to be more specific anyway, just to leave room for other methods. So max_words or something?

[kevdev424]

Roy Blunt and Bob Dold are counting characters, so we might need both then. I'm fine with max_length for character limiting and max_words for word counting.

[j-ro]

Cool -- let's hope it's mostly characters really. Counting words can get dicey depending on how you define a word.

[Hainish]

@j-ro any reason not to put this in the options hash, rather than the hash directly under the action itself? This current schema change requires a db migration, which is fine I suppose but since we already have the options hash we might as well use that instead...

[j-ro]

Probably makes sense, can you give an example?

[Hainish]

Maybe something like this:

    - fill_in:
      - name: message
        selector: "form#thisForm textarea[name='MessageBody']"
        value: $MESSAGE
        required: Yes
        options:
          max_length: 1000

Currently select actions are using options as a list or hash of all the <option> tags.

When the action is fill_in and the value is $EMAIL, you can use options as a hash, with a key allow_plus specifying if a + sign is allowed in the email field when the remote form validates.

So we're currently using it in a pretty flexible (and nonstandardized) way.

[Hainish]

Anything under options in Phantom DC is serialized before being entered into the DB, so there's a flexible schema. This will also make it easier in the future if we decide to add regex_validate as per @crdunwel's suggestion.

[j-ro]

@kthayer424 thoughts? Works for me, if you agree and want to update your PR...

[Hainish]

Phantom DC has implemented the character limitation on for the proposed changes: EFForg/phantom-of-the-capitol@c38a69a

We have to get confirmation that the proposed change is how we want to move forward, but if the current proposal is changed it'll be easy enough to change on the Phantom DC side as well.

Note that even though we've simply truncated the field input where necessary, this should be a last-ditch effort to get the message through. Ideally, the front-end application should alert the end user of the character limit in some way.

[j-ro]

Nice -- so, @kthayer424, want to update your PR to this options method? Then we can close and merge all the things!