DataFormFieldVisibleIfNotEmpty < Development

You are here: Foswiki>Development Web>BrainStorming>DataFormFieldVisibleIfNotEmpty (20 Feb 2010, PaulHarvey) (raw view)
---+!! %TOPIC%

%TOC%

---++ 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!

-- Main.CrawfordCurrie - 22 Jun 2009

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

-- Main.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" :-) )

-- Main.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).

-- Main.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..... ;-)

-- Main.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=:

<pre>sub renderForDisplay {
    my ( $this, $meta ) = @_;
<p> </p>
<p>
    my $templates = $this-&gt;{session}-&gt;templates;
    $templates-&gt;readTemplate('formtables');
</p>
<p>
    my $text        = '';
    my $rowTemplate = $templates-&gt;expandTemplate('FORM:display:row');
    foreach my $fieldDef ( @{ $this-&gt;{fields} } ) {
        my $fm = $meta-&gt;get( 'FIELD', $fieldDef-&gt;{name} );
        next unless $fm;
        my $fa = $fm-&gt;{attributes} || '';

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

%BLACK%
            my $row = $rowTemplate;
</p>
<p>
            # Legacy; was %A_TITLE% before it was $title
            $row =~ s/%A_TITLE%/\$title/g;
            $row =~ s/%A_VALUE%/\$value/g;    # Legacy
            $text .= $fieldDef-&gt;renderForDisplay( $row, $fm-&gt;{value} );
        }
    }
</p>
<p> </p></pre>

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.

-- Main.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.

-- Main.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.

-- Main.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.

-- Main.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.

-- Main.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.

-- Main.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?

-- Main.AaronFuleki - 19 Feb 2010

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

%STARTSECTION{"wysiwygattributes"}%I hope an attributes column could look something like:

<verbatim class="tml">M, EDITOR=TinyMCEPlugin+styles+headings+lists, H</verbatim>

Over in the Type column, would be a policy for the HTML2TML part that did something like this:
<verbatim class="tml">textarea, tml=strict+notables</verbatim>%ENDSECTION{"wysiwygattributes"}%

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

-- Main.PaulHarvey - 19 Feb 2010

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

-- Main.PaulHarvey - 20 Feb 2010

Moved some brainstorming about coming up with a new way to do System.DataForm definition topics at BrainstormingDataFormDefinitions. The take-home point was written by Main.CrawfordCurrie:
<blockquote>%INCLUDE{"BrainstormingDataFormDefinitions" section="attributeproblems"}%</blockquote>

-- Main.PaulHarvey - 20 Feb 2010

After some adventurous BrainstormingDataFormDefinitions - which is really beyond 1.1 scope - I am wondering if we can't just create an attributes parser (well, it would just return an array split by comma) and extend the !FormFieldDefinition API.

We could create a special case for MH and HM forms (where the new syntax is supposed to be M,H or H,M).

What would it break? -&gt; plugins using the old API. What else?

-- Main.PaulHarvey - 20 Feb 2010
ChangeProposalForm edit

TopicSummary	Introduce new attribute for data field to allow hiding empty fields
CurrentState	UnderInvestigation
CommittedDeveloper	RaymondLutz
ReasonForDecision	None
DateOfCommitment
ConcernRaisedBy	MichaelDaum
BugTracking
RelatedTopics
PlannedFor
Topic revision: r19 - 20 Feb 2010, PaulHarvey
Development
Quick Links

Tools

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement.