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:
- 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.
- 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\" /> <input type=\"submit\" value=\" Create \" /><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
--
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
i started playing with profiling it, but the *::BEGIN calls take up most of the time.
--
SvenDowideit - 11 Jul 2004