DataFormFieldVisibleIfNotEmpty

Add additional Data Form field attribute

I would like to suggest adding new Data Form field attibute (letter is for consideration, let's say F for "filled"), that will cause the field to be visible in view mode only when something is entered into the value.

I'm preparing servers documentation project, and in my case this would be very useful for adding multiple network cards possibility for one server, but to see only those that are "active" (filled).

---

Interesting idea. But why don't you just use a multi-select?

BTW this is a feature proposal, so I changed the form. Please complete it!

-- CrawfordCurrie - 22 Jun 2009

---

I don't use multi-select, because field should be just text.

-- DanielKownacki - 23 Jun 2009

OK, just to turn your description on its head a bit, this is really to "hide" a field that has an empty value (or no value, or is undefined in the topic) - in this respect it is related to recent discussions on defaults for %FORMFIELD. I like the idea (though I think you can do better than "F" )

-- CrawfordCurrie - 23 Jun 2009

---

OK. Let's start alphabetically - "A" for AutoHide

I've made crude implementation locally (3 lines of code), and it seems to work OK (I'm sure I forgot something, but main functionality is there).

-- DanielKownacki - 23 Jun 2009

"B" for "Background field"

Ah, that's depressing. Can you turn that into "I've made a complete, documented, unit-tested implementation and attached a patch"? That would cheer me up.....

-- CrawfordCurrie - 23 Jun 2009

I've been using this enhancement for a while, since I have some forms with hundreds of fields and they are only sparsely filled. I use the tag "S" for "suppress" the field if there is no value. Also, "H" hides the field unless you are in edit mode. In Form.pm:

sub renderForDisplay {
    my ( $this, $meta ) = @_;
 

    my $templates = $this->{session}->templates;
    $templates->readTemplate('formtables');


    my $text        = '';
    my $rowTemplate = $templates->expandTemplate('FORM:display:row');
    foreach my $fieldDef ( @{ $this->{fields} } ) {
        my $fm = $meta->get( 'FIELD', $fieldDef->{name} );
        next unless $fm;
        my $fa = $fm->{attributes} || '';


        if ($fa =~ /S/) {
            next unless ( $fm->{value} ); # suppress if no value. RCL 2009-03-25
        }
        unless ( $fa =~ /H/ ) {


            my $row = $rowTemplate;


            # Legacy; was %A_TITLE% before it was $title
            $row =~ s/%A_TITLE%/\$title/g;
            $row =~ s/%A_VALUE%/\$value/g;    # Legacy
            $text .= $fieldDef->renderForDisplay( $row, $fm->{value} );
        }
    }

 

I've been using these changes for nearly a year. I would probably just next if ($fa =~ /H/) for the H attribute instead of starting a block, but it is about the same.

-- RaymondLutz - 17 Feb 2010

Parsing the formfield attributes has always been underused. So making more use of it is a good thing. However, I'd prefer to parse the attrs somewhat more safer, more rationalized. For now checking for a specific char in it is quite ad hoc. Let's make it a proper comma-separated list, then split it and check for any flags in it. Without, I have to add myself to ConcernRaisedBy unfortunately.

The proposal is missing a DateOfCommitment.

-- MichaelDaum - 17 Feb 2010

We have two attributed today. hidden and mandatory. H and M. And the syntax is HM or H or M or none.

Bad yes, but reality. We must not break compatibility for this.

Then I will raise the concern.

-- KennethLavrsen - 17 Feb 2010

Lets move on with a comma seperated list and mark no-delimitter-concatenation as deprecated. Since we have 23 letters left, there is no need to hurry the deprecation.

-- OliverKrueger - 17 Feb 2010

Note, that we've got a lower case h attribute: not documented but there for ages. We better get these things out of the morgue.

-- MichaelDaum - 17 Feb 2010

I absolutely need the attributes field to be properly split by commas for a future WYSIWYG formfields implementation to work in a flexible, maintainable way...

In fact I can see now that my intended use of attributes column will probably introduce much breakage, if people are scanning for an individual char.

I need to be able to count on the attributes column being used/abused much the same as we do in the type column.

-- PaulHarvey - 18 Feb 2010

I've been wrapping IFs around form fields in my templates for ages - this would be a great feature! That is, assuming compatibility isn't hosed.

Paul - are you suggesting that the code be re-factored to accept single chars for backwards compatibility, but switch to comma-separated lists moving forward?

-- AaronFuleki - 19 Feb 2010

I have no problem with the additional attribute. I have a problem with the implementation.

I hope an attributes column could look something like:

M, EDITOR=TinyMCEPlugin+styles+headings+lists, H

Over in the Type column, would be a policy for the HTML2TML part that did something like this:

textarea, tml=strict+notables

So my concern is that the proposed code will not be compatible with my planned usage of the attributes field.

-- PaulHarvey - 19 Feb 2010

Currently the attribute column consists of a number of non-space characters, and is scanned using m/M/ and m/H/. Thus the syntax of the base attributes column can be defined as a set of single-character boolean attributes separated by \W*. If we take that as the "compatibility baseline" then we have absolutely no scope for more sophisticated syntax in that column (I have seen "Mandatory Hidden" in that column before now). So, I can't see any alternative to adding a new column, to support the extended attribute syntax Paul is proposing. Proposal:

The extended attributes field is a comma-separated set of strings, using decimal URL-style encoding of dodgy chars (to allow for inclusion of TML, newlines etc). Extended attributes override "old style" attributes. For consistency, %META:FILEATTACHMENT should be extended (documented) the same way, even if we don't implement it immediately.

I just went and read the code for the form schema "parser", and am struck how shite it is. When I think of the problems I've had in the past with ludicrously wide form table rows and nasty characters, it makes me think it may be better to deprecate the whole form schema style, and replace it with something more structured (and memorable). For example, leveraging TML (as I did in Config.spec):

Question

• Type: select+new
• Help: Ask questions to try and determine what I'm thinking about
• Size: 3
• Value: Animal,Vegetable,Mineral
• Attrs: Mandatory

Answer

• Type: textarea
• Help: Write your answer here using words of one syllable or less
• Size: 10x30
• Attrs: Editor=TinyMCEPlugin+styles+headings+lists

or even JSON, which would help with client-side:

[
 { name: 'Question',
  type: 'select+new',
  help: 'Ask questions to try and determine what I\'m thinking about',
  size: 3,
  value: [ 'Animal', 'Vegetable', 'Mineral' ],
  attrs: { 'Mandatory' => 1 }
 },
 { name: 'Answer',
   type: 'textarea',
   help: 'Write your answer here using words of one syllable or less',
   size: '10x30',
   attrs: { 'Editor' => 'TinyMCEPlugin+styles+headings+lists' }
 }
]

Though I suppose that could be generated on demand.

-- CrawfordCurrie - 20 Feb 2010

I've removed my concern. As usual it was out of scope for the proposal in question.

-- PaulHarvey - 20 Feb 2010