Re^2: Perl6::Form Issues with Zero-Padding and Declarative Width (integer)

[AnaximanderThales]

Yes, having received an email back from Damian (creator/maintainer of Perl6::Form), it was completely usage issues.

For the zero-padding, you have everything mentioned. I was using it incorrectly based on your response. My issue with the float zero-padding was just the symantics. I had {0>>>.>>0} and the correcte usage is {0>>>.<<0} notice the change from > to < at the decimal point

Additionally, as AM said, there is no INT padding, so the lfill (or rfill) is the correct method.

I'm still a little confused by Damian's response on the Declarative Width ({<(5)<}), but I'm working on figuring it out.

ME:

The length give by perl shows that the field is actually 5 positions.

Damian:

No. The length of the *data* for the field is 5. :-) The *field* is the specification "{>(5)>}", which is definitely 7 characters in width (and hence invalid, since the "(5)" specifies that the surrounding field must be 5 characters wide. In other words, declarative field widths are not about validating the data to be interpolated; they are about checking that the field specification itself is consistent. In practice, declarative field widths are mostly only used for formats that have been autogenerated, as a way of checking that the field you somehow constructed is the correct width. They are not in any way about verifying the data to be formatted into a field. In fact, form() has no features for validating the data it formats. It just does its best to accommodate whatever data you through at it.

ME:

I'm curious as to why perl would say $tID is length 5 but form would say $tID is length 7.

Damian:

That's the misunderstanding in a nutshell. form() isn't saying the contents of $tID is of length 7; it's saying that the specifier for the "{>(5)>}" field into which $tID is being formatted is of length 7.

I'm mulling Damian's definition about how the declarative width field operates. It's kind of making my head swim at the moment. I'll bang away on it until that little 1/16" turn makes it slip into place in my mind.

I appreciate all the answers, and Damian's response. Thank you. @

[Loops]

Hey there,

Glad you got it mostly sorted out and working. I'm sorry that my quick attempt to help was off the mark. But it did relate to your outstanding question about declarative field widths. Maybe this will help:

Declarative field widths add no formatting information. The field you were talking to Damian about was this:

{>>>>>}

Clearly a field of 7 characters. There is no other information in order for this field to be used at this point. If in addition, you want an automatically validated "checksum" to ensure that the field is actually the width you intended, you can add it as a length inside parentheses:

{>(7)>}

The field is still 7 characters long, just as before. The form code will rip the "(7)" out, validate that the 7 matches the actual field length, and then logically replace it with ">>>" to restore the real format.

None of this is very useful for a field of 7 characters, it can be eyeballed as correct pretty easily. But for a field of say 50+ characters, it's nice to have a double check.

[AnaximanderThales]

No worries --

The issue that I'm having with the declarative width is how '7' is arrived (I use 7 now, but I'll clarify in a moment).

Since I'm wrapped up in trying to get my project in a state that I'm satisfied with right now so I haven't played with this more, so I can't say for certain this occurred.

We have {>>>>>} which is 7 characters. We have {>(5)>} which is also 7 characters? Okay -- I'll accept that the {} are included in the count. In my mind, while I was playing with things, I remember switching {>(5)>} to {>(3)>}. This should be 5 characters. When I have " 003," I should not get the validation error. My data has 5 characters, the field is 5 characters.

Like I said, I haven't gone back and tested it, it was one iteration out 20 or 30 tries. So, this is what I need to bang around with and figure out. I just need more experience with it, break what I'm doing, ask more questions and just get it set in my mind with my own words.

[Loops]

Ah, I see the source of confusion. I think you're mixing up Imperative field widths with what you're using, Declarative field widths.

Here's another field specification example to make things clear:

{>>>>>>>>>>>>>>>>>>}

That is a field of 20 characters. That's the actual specification, no "(20)" in there at all. Adding the "(20)" doesn't change the width at all.. if you put in a "(7)" it wouldn't change the width either. But when the form is validated, the first one would pass, and the second would generate an error. This has nothing to do with _setting_ the width of the field, only validating that you've typed it in correctly with no missing or added characters.

Now if you don't want to type all those characters you can use the Imperative field width syntax using curly brackets:

{>{20}>}

This forces the field width to be 20 characters wide, so it is another way that has duplicate functionality to the first example.

HTH.

[Anonymous Monk]

Yeah, his docs are always novels :) see https://metacpan.org/pod/Perl6::Form#Declarative-field-widths, its what hes talking about ... this example might be clearer

field of length ten  {<<<<<<<<<}

field of length ten with CHECKSUM  {<<(10)<<<} basically the number has to match the literal length of the field including every single character like {}, basically length of the string , if it isn't, it errors (programmer made typo fix it programmer fix it)

field of length ten with TELLSUM  {<{10}<}, the length of this string is 8 characters, but the { curly braces } mean don't count characters for length, just use the number, so the field width is 10

field of length ten with TELLSUM  {<<<<<<<{10}<<<<<<<}, the length of this string is 20 characters, but the { curly braces } mean don't count characters for length, just use the number, so the field width is 10