Tags:
create new tag
view all tags
I think it would be very nice to be able to use the data from a TWikiForm within the topic that the form is on. I've tried to figure out a way to do this and couldn't find one, so if I've missed something obvious and there's already an easy way to do this please let me know. But I'd just like to be able to use things like this in my topics:

%FORMFIELD{"FieldName"}% 

and have that represent whatever value is in the field "FieldName" on my form. I know that this is not the best syntax for something like this, but you get the idea. How many people would use or need to use something like this?

-- DavidSachitano - 11 Jul 2002

That sounds like a sensible enhancement. Use a FormattedSearch as a workaround for now, for example:

%SEARCH{ "^%TOPIC%[^a-zA-Z0-9]" scope="topic" limit="1" regex="on" nosearch="on" nototal="on" format="$formfield(AnyFormFieldName)" }%

-- PeterThoeny - 12 Jul 2002

Peter: Thanks for that example -- it finally clears up for me how to do one of the things I wanted to do -- present the data from a form field in bulleted form. (And this is an rhkmarker to help me find this again when I'm ready -- or maybe I'll remember -- the part that I was missing is to restrict the search to the current topic with scope="topic" ( and a single instance with limit="1"), IIUC.

-- RandyKramer - 12 Jul 2002

I've written some code that will do this. I don't know how well this fits in with the coding standards that the core team uses, so if I've done bad things here, let me know. It's just a subroutine added to TWiki.pm, but then you can add a sub to TWiki/Func.pm that calls the function, and you can call that function from plugins. For my plugin I used a format like this:

%FORMFIELD{"NameOfFormField"}%

Here is the code I added to TWiki.pm:

sub getFormField
{

    my( $web, $topic, $meta, $whichField ) = @_;

   my $metaText = "";

   my %form = $meta->TWiki::Meta::findOne( "FORM" );
   if( %form ){
      my $name = $form{"name"};
      my @fields = $meta->find( "FIELD" );
      foreach my $field ( @fields ) {
          my $title = $field->{"title"};
          if( $title eq $_[4] ){
             my $value = $field->{"value"};
             $metaText .= "$value";
          }
      }
   
   $metaText = getRenderedVersion( $metaText, $web );
        }

    return $metaText;
}

Please let me know if I have done bad things here, or what needs to be done. I'd really like to start using this feature on our real TWiki at my company, but they won't let me until it gets into the official TWiki code.

-- DavidSachitano - 17 Jul 2002

Thanks for the contribution. The %FORMFIELD{"FieldName"}% syntax is fine, we should take this into the core code of TWiki.

You propose to add a new TWiki::Func:: call. Ideally this should be handled all internally by TWiki, e.g. TWiki::handleCommonTags() should call getFormField(). But there is currently a complication, see SimplifyInternalMetaDataHandling.

-- PeterThoeny - 18 Jul 2002

Related to this is EditControlsBasedOnFormDefinition. The idea is to build HTML forms with input fields based on TWiki Form fields, with variables like %EDITFORMFIELD{ web="..." topic="..." formfield="AnyFormField" }%.

-- PeterThoeny - 25 Jul 2002

I have been interested in this feature for my company TWiki web and tried the FormattedSearch proposed by DavidSachitano as a workaround. I found that it it worked well for Topics with a small number of fields (two or three) but the search process put to much load on the server when the number of field was increased past that.

So, I "bit the bullet" and put in place the %FORMFIELD% feature by modifying the TWiki.pm script directly. For those who are interested to try it out, here are the modifications.

This provides an initial "implementation" without resulting to PlugIns until the SimplifyInternalMetaDataHandling problem is resolved. This workaround is still not the best approach because it reads and parses the Topic for MetaData with every call to handleCommonTags() increasing the load on the server.

We have been using this implementation over the last two months and find it very usefull and stable.

-- ChristianBaribeau - 6 Dec 2002


I was trying to implement a form with fields for my page's title and subtitle, so I needed to get these values onto the page (at the top, not in the form table, obviously).
Above feature/code is interesting, but it lacks:

  1. The feature to format the field values. A title needs tags around it, that explains my immediate need, but I can think of other situations, like displaying keywords in a table, or in a specific color.
  2. More important, formatting makes sure I don't have wasted space in case there is no field value, for instance an empty <H1> </H1> pair.

For formatting I have looked at the code used for - it uses "prefix" and "suffix". I added "alttext" for situations that you want to display a default text in case there is no field value. See also my patch in HowToShowParentTopics.

Usage example
<H3>No title</H3>

-- ArthurClemens - 02 Feb 2003

Pretty cool patch. I implemented it on my web site. It's working great!

-- JasonTromm - 25 Jun 2003

I've implemented this patch on my TWiki, and it struck me as far more useful than the patch I created (MetaDataRendering) which has been included in TWiki. I'm using this patch in preference to the functionality I wrote... (Even though this approach is "less elegant" in implementation terms, and probably has security issues)

I've extended the syntax to make it more useful:

  • %FORMFIELD{"field" prefix="prefix" alttext="alt text" suffix="suffix" topic="SomeTopic"}%
    • The addition is the topic=SomeTopic field. Logically there should also be web=...
    • default topic is the topic containing this decl.

One key benefit of this approach over mine was that this one works in published/precompiled systems in a way people would expect.

-- MichaelSparks - 18 Aug 2003

I have updated my previous patch (now against TWiki20040119beta). I have included MS's idea of adding topic and web variables.

%FORMFIELD{"fieldname"}% Returns the value of a field of a WebForm. Supported parameters:
Parameter: Description: Default:
"fieldname" The name of a WebForm field required
topic Topic where form is located (when empty) current topic
web Web where above topic is located (when empty) current web
prefix String to put before return value none
suffix String to put after return value none
alttext String to put when field is not found none
Example: %FORMFIELD{"ProjectName" topic="CurrentProject" web="Projects" prefix="---+++" suffix=" (in progress)" alttext="Currently there is no project."}%

(above table is formatted to be included in TWikiVariables).

Usage in a search is also possible:

%SEARCH{search="Project" scope="topic" regex="on" noresult="on" nosummary="on" nosearch="on" format=" $percntFORMFIELD{\"ProjectTitle\" topic=\"$topic\" prefix=\"   * [[$topic][\" suffix=\"]]\" }$nop%" nototal="on" header="*Projects:*"}%

I guess that "prefix" and "suffix" could be improved by using "format", but this is beyond my Perl capabilities. It can always be added later.

-- ArthurClemens - 18 Feb 2004

I have updated the patch with a better check for empty results.

-- ArthurClemens - 20 Feb 2004

I like this. I originally thought it was pretty redundant with UsingFormsForSettings, but with the formatting niceties (prefix/suffix/alttext) it looks to become quite convenient. However...

I'd like to suggest integrating this stuff into the preferences system. This would allow some simpler syntax in easy cases. How about %FORM_FieldName% for a simple field access to the current topic? Then the more complex accesses would use an extended %VAR%, like this: %VAR{"FORM_FullName" topic="Main.MyTopic" prefix="My name is" alttext="I have no name."}%.

I'd think the "FORM_" prefix could be dispensed with, but that would make all form fields settings in their respective topics automatically, and certain people seem less than enthusiastic about that change. However, like my implementation for topic-level preferences it could be made optional.

On another note, maybe a different approach for formatting would be good. Something like format="---+ $field (in progress)", where $field gets the form field value. alttext would stick around -- a very useful idea, that.

BTW, I've got the %FORM_Field% syntax working already - it was a two-line change. I think that's useful regardless because %FORMFIELD{"blah"}% is more combersome than %FORM_blah%. I'm putting the formatting stuff into now.

Generally, I dislike introducing new syntax when existing syntax can be expanded to do the job in a logical way. So here is the question: does it make sense to allow a topic to be specified in %VAR% and have form fields accessed that way? Or would it be easier for people to remember a syntax?

Either way, I plan on rewriting this functionality inside of PrefsDotPm, where I believe it ought to reside for the moment. A side benefit of this will be a reduction in topic reads...the Prefs package will already be reading these topics anyway.

A few problems emerge with this solution:

  • Topic-level preferences have to be enabled for the FORM_* variables to become avaiable.
    • It could be set up to make a special check for FORM_* variables and use those from the topic all the time.
  • FORM_* fields will cascade out of site and web preference topics into local accesses.
    • I really don't think this will be much of an issue, since any form fields you care about will be in the topic's form, and therefore will override any identically-named fields in forms attached to higher-level preferences topics.
      • indeed, rather than a problem, this sounds like a useful mechanism to composite/inherit data -- WillNorris - 21 Feb 2004

-- WalterMundt - 21 Feb 2004

we need a dom

-- WillNorris - 21 Feb 2004

One problem I see with the FORM_ syntax is that you can't use spaces in the field name.

-- ArthurClemens - 21 Feb 2004

I made another change to the patch (attached as new file), so that %FORMFIELD% can act as a conditional. I changed the position of BOOL found, and the position of the altext. So if there is no content found in the form field, it renders the alt text.

Take this example:

   * %FORMFIELD{"Page name" topic="%TOPIC%Contact" prefix="" suffix="" alttext="<form class=\"newprojectform\" name=\"newcontactpage\" action=\"%SCRIPTURL%/edit/%WEB%\"><input type=\"hidden\" name=\"topicparent\" value=\"%TOPIC%\"><input type=\"hidden\" name=\"templatetopic\" value=\"TWiki.NewProjectContactpageTemplate\">Create <b><span class=\"apart\">Contact page</span></b> with this project: <input type=\"hidden\" name=\"topic\" value=\"%TOPIC%Contact\" />&nbsp;<input type=\"submit\" value=\" &nbsp;Create&nbsp; \" /><br /><input type=\"hidden\" value=\"Contact page\" name=\"Page name\" /></form>" }%

If the field "Page name" of topic %TOPIC%Contact is found, you will see the name of the page, otherwise you will be presented a Create button to make this page.

-- ArthurClemens - 21 Feb 2004

Why would the FORM_ syntax be incompatible with spaces? %FORM_Page name% worked fine with my sample implementation. Just because regular preferences have to be defined without spaces doesn't mean the preferences system isn't capable of handling preference names with them. The no-spaces rule is purely an artifact of the "Set FOO = bar" syntax.

Just a note: as both a CoreTeam member and especially as our resident UsabilityExpert, you should have at least as much a say over the syntax as I do. Feel free to commit your changes to CVS yourself if you like; alternatively, I can do it when I find the time. My ideas on usability are decidedly odd, and when I remember that I tend to rethink my decisions about things like this. Sometime I'll integrate the FORMFIELD into prefs -- it can still act just the same, but it'll be more efficient that way. But that's not necessary before putting this into TWiki.

I really would like to see prefix and suffix replaced by a very basic format argument that implies both before this enters the 'canon', so to speak. Otherwise we'll be stuck with supporting all three indefinitely when we switch. You've said you're not comfortable with implementing a format option, so I can do that for you, and much faster than I can finish my reimplementation under the Prefs system. Is it okay with you to take out prefix and suffix when I do that?

-- WalterMundt - 22 Feb 2004

My Perl knowledge is very basic, so I wouldn't like to make code changes undiscussed (or without a last peer review). If you can provide a format option without prefix and suffix that's fine, as long as there is the option to fill in an alternative (when not found or when empty) text.

-- ArthurClemens - 22 Feb 2004

I don't have time to make the changes I'd like to make just yet for this patch; I'm moving it to PatchAdjustmentRequired and assigning myself until I can get around to fixing this. This is because I'd like to avoid having any topics "languishing" in PatchProposal for too long. I want to encourage the general policy of deciding on PatchProposals quickly so as not to leave contributors hanging, not knowing whether their work is going to be taken or not.

-- WalterMundt - 29 Feb 2004

Can you summarize what steps need to be taken?

-- ArthurClemens - 01 Mar 2004

I was going to, but then I realized that in this case it wouldn't be much harder to change it myself than to write up a list of things to do. So I fixed things up and committed it already.

-- WalterMundt - 01 Mar 2004

If there are no objections I would like to rename the variable from FORMFIELD to FIELD. This is in anticipation of FieldVariableToQueryNamedFields.

-- PeterThoeny - 13 Mar 2004

i would be hesitant to change the syntax of a patch 20 months after it's been posted. a surprisingly large number of installations have already applied this---even commenting on and contributing to this patch. perhaps the best compromise is to support both FORMFIELD and FORM?

-- WillNorris - 21 Mar 2004

I agree with Will, and add that FORMFIELD is what it is, while FIELD could refer to something else (i like specific names for things) and therefore suggest that the syntax of FieldVariableToQueryNamedFields be changed to be FORMFIELD

-- SvenDowideit - 22 Mar 2004

How do I use the format parameter? I can't make it work.

-- ArthurClemens - 21 Apr 2004

you should see the TopicClassification in the next field PatchAccepted

-- SvenDowideit - 21 Apr 2004

Sure, but format suggests something like:

%FORMFIELD{"TopicClassification" format="   * $somevalue"}%
Does $format do anything?

-- ArthurClemens - 21 Apr 2004

An attentive reader pointed to me that indeed I must use:

%FORMFIELD{"TopicClassification" format="   * $value"}%

Now, with format="" I always get the value displayed, due to

    $format    = extractNameValuePair( $args, "format" ) || '$value';

To avoid hacks like format="<nop>", it would be more logical not to show anything with format="".
So:

    $format    = extractNameValuePair( $args, "format" ) || undef;

-- ArthurClemens - 21 Apr 2004

... only setting format to "" generates a newline, that is translated to a <p />, not very desirable.

-- ArthurClemens - 22 Apr 2004

... so what works is to use:

    $format    = extractNameValuePair( $args, "format" ) || "<nop>";
but I am not sure if this is not just an ugly workaround that can be solved more beautifully.

-- ArthurClemens - 22 Apr 2004

I have made this change in cvs. So when no form field value is found, nothing is rendered.

-- ArthurClemens - 05 May 2004

I suggest to revert the "<nop>" change because it complicates further processing, e.g. by a CALC that tests for a form field.

The FORMFIELD doc is pending, but AFAIK you have already complete control with the two additional parameters alttext and default.

Also, a very simple cache algorithm could speed up this function considerably when retrieving several fields of the same topic.

-- PeterThoeny - 07 May 2004

Doc below that can be cut and pasted into TWikiVariables, by someone who doesn't get an InternalServerError whenever they try and save the bleeder. Doc reflects what is currently implemented. Note that I think code fixes are needed before this is acceptable for Cairo (cache as Peter suggests) so I put impl progress back to 70%.

The attached latest formfield.diff patch applies to SVN version 1553 to add cacheing and tidy the whole thing up as per spec. patch applied to SVN - SvenDowideit

FORMFIELD{"format"} -- renders a field in the form attached to some topic

  • Syntax: %FORMFIELD{"fieldname"}%
  • Supported parameters:
    Parameter: Description: Default:
    "fieldname" The name of a WebForm field required
    topic Topic where form data is located. May be of the form Web.TopicName Current topic
    format Format string. $value expands to the field value. "$value"
    default String to use when no value is defined for the field ""
    alttext String to put when field is not found in the form ""
    Example: %FORMFIELD{"ProjectName" topic="Projectweb.CurrentProject" default="" alttext="No project field found" default="none"}%

-- CrawfordCurrie - 01 Jul 2004

docco applied after half a dozen attempts using twikicvs (updated to todays alpha code) (ie no plugins, and new code). the internal server error still occurs frown i started playing with profiling it, but the *::BEGIN calls take up most of the time.

-- SvenDowideit - 11 Jul 2004

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff _getFormField.diff r3 r2 r1 manage 2.0 K 2003-02-02 - 23:20 UnknownUser first version (old)
Unknown file formatdiff formfield.diff r1 manage 5.1 K 2004-07-02 - 09:44 UnknownUser Rewritten to work as per spec, and cache META
Unknown file formatdiff getFormField.diff r3 r2 r1 manage 2.5 K 2004-02-20 - 23:18 UnknownUser Diffed against TWiki20040119beta - updated 21 Feb 2004
Unknown file formatdiff getFormField_conditional.diff r1 manage 2.5 K 2004-02-21 - 23:54 UnknownUser Adjusted patch to make function work conditional. Diffed against TWiki20040119beta.
Edit | Attach | Watch | Print version | History: r42 < r41 < r40 < r39 < r38 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r42 - 2004-08-20 - CrawfordCurrie
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.