|
Cookbook /
WikiFormsBugsWikiform Bug ReportsPage for bug reports for the WikiForms recipe. Stating default text doesn't work with explicit two-dimensional field sizes (PmWiki 2.1.17, WikiForms 1.48) - NOT A BUGI just found that when I supply default text, excplicit field sizes don't work. If I specify:
I get an erroneous form as the quotation is not correctly parsed. This feature is not currently supported. You can specify (text=rows*columns) to make a scrolling text box, but cannot specify a default value at this time.
Thanks for the clarification!
Font changes in mid-form, affecting default field sizes (PmWiki 2.1.17, WikiForms 1.48)If I specify
the form is OK, but the size information is ignored. As of 2006-09-02, I am unable to replicate this problem. It works for me; I get a field called name, containing Default, 50 characters wide.
Hm, upon closer investigation, I noticed that it was the first field on my form that is affected, and that I get a proportional font there (Arial or something), but a monotype font (Courier) in the rest of the fields. So the width probably is 50 characters indeed, but the character width differs. So it's a cosmetic problem only. --Henning September 05, 2006, at 09:53 AM
Suffix-defined FormTemplates "cannot be associated" (PmWiki 2.1.17, WikiForms 1.45) - FIXED IN 1.48These two variants don't work for me:
--Henning August 23, 2006, at 11:21 AM Maybe I should try to describe what I'm doing: I've got set up a number of groups named like D300-Doks.D300-Doks These groups work well if they have a template like D300-Doks.FormTemplate. However, if I delete that in-group template and instead create Doks.Doks and Doks.FormTemplate or Forms.Forms and Forms.Doks I get the following error message: PmWiki can't process your request cannot associate a form with 'D300-Doks.D300-Doks' We are sorry for any inconvenience. Am I doing something wrong, or have I indeed found a bug? --Henning August 29, 2006, at 05:03 AM
Looks like this broke at some point for some reason. I'll investigate -- currently, it isn't looking up the group suffix, so it isn't finding the template. (a couple of hours later...) Ah! It broke when PmWiki changed $FmtP to $FmtPV. I think I have fixed it -- try version 1.48 jr
Great! It seems that all is working fine with the latest fix hfwang
Thanks! It works as intended with 1.48! --Henning September 05, 2006, at 09:53 AM
CR in text field leads to text suppression in wikilist (PmWiki 2.1.17, WikiForms 1.45, 1.48)I just noticed that the use of CR line breaks in text fields leads to the suppression of the lines after the first CR in the wikilist.
This is not an easy problem to solve in a general way without creating undesirable side-effects. Consider the case of a text field that contains an itemised list. It would not be a good idea to apply any of the proposed solutions to such a field value. The design has to be robust across a wide range of usage scenarios. If the wiki list doesn't show what the user wants, it is surely easy enough to edit the page and change it.
With the amount of text we store in the forms, it would be beneficial to have a simple way of structuring it using by CRs.
Some of the data has been imported from MS Office software where it already had line breaks, so there are lots of pages affected, and an inexperienced user might introduce more unnoticed. To "sell" the WikiForm solution as replacement for the MS Office solution, I pointed out that if desired, it would be possible to copy and paste the complete data back into Excel anytime. The way CRs are handled blocks this route, which is a bit of a problem.
I'm not sure I understand the problem with the itemized list. It wouldn't be rendered as an itemized list in the table, but we'd get the asterisks and the full text if the [[<<]] markup were used as a CR substitute, wouldn't we? From my point of view, that appears better than dropping the lines entirely. --Henning September 05, 2006, at 09:53 AM
The wikilist directive is a compromise. It tries to do something "reasonable" for a wide range of usage situations. This meant making quite a few design trade-offs to get a solution that actually works reliably. In your situation, it's not doing the right thing. But if we change it to support your situation, then it will have undesirable consequences in other situations. For example, suppose a user has made use of the title option; currently, if that field is included, wikilist omits the title directive from the data it retrieves, which is a desirable result. So I think the best option is that rather than change wikilist, you need a new custom directive that emits the entire field value. You may even want it to emit an advanced table and actually process the markup from the source pages.
It may be time to consider creating a custom report writer that lets users build formatted reports from the data on form-based pages. If this is evaluated at the same time as include processing, then all markup will get processed in the display page. jr
You are right! The point about "all markup" is absolutely convincing - I was having problems with the "Attach:" markup, too, and now I see that it's all part of a higher-level issue. My problem is that I'm not PHP-literate, so I'm not capable of creating that custom report writer by myself. Maybe I should try to learn PHP, though I guess even if I take that route, it's going to take some time before I can contribute anything of value. We are always happy to accept commissions to meet special requirements. Alternatively, you might be able to build close to what you want using the pagelist directive with an include-style format. It depends on what you want the resulting page to look like. jr
Commission is an interesting option, if I can get my employer to fund it. Multinational mega-corporation - no idea if the concept of supporting Open Source development will get accepted by the buereaucracy, but I'm always optimistic :-) I'll also look at the pagelist directive, I haven't checked it out yet but it seems to be a very powerful and universal tool. --Henning September 29, 2006, at 11:52 AM
I just received a discouraging response from within the company :-( I was able to create a useful overview using a customized searchbox directive (hadn't properly understood what it was about before), which I have described in WikiFormsRecipes#pagelist. I couldn't think of a way of providing absolute links in my recipe, though, as this would require manipulation of the field content. (I'm not even sure it's possible at all.) --Henning October 19, 2006, at 10:30 AM
The CR issue is conceptually an important one because once data was entered that way, it's sort of "trapped" in PmWiki because it's not possible to simply copy & paste it back into an MS Office table (as I had promised naively). Fortunately, no-one has asked for that one yet. I guess I could improvise on file level then. --Henning September 22, 2006, at 08:34 AM "Attach:" markup does not work as text field default (PmWiki 2.1.21, WikiForms 1.48)I tried to use the following text as default for the first field in the form: [[Attach: The idea was to use this to enter links like the following one: [[Attach:Test.txt|Test Document]] However, after pressing submit to go to the standard edit page, the data entered previously has vanished completely (including the default text). If I do not provide a default text, everything works an normal. --Henning September 14, 2006, at 09:34 AM Perhaps the best solution would be to provide an "attach" field type, that automatically wraps the contents in suitable attach markup. jr
Good idea. I guess it would have to have two components, filename and link text. (I also thought about having link text only and provide a clickable symbol for uploading, like for the "?update=y" action, but while convenient, that would have some disadvantages if the filename already exists etc.) --Henning September 29, 2006, at 11:52 AM
Here is a suitably modified file (wikiform-attach.phpΔ) that adds an (attach) field type as described, which inserts the markup: Attach: before the field text. It does not provide an alternative link text option. (I couldn't work out the reg expressions syntax to adapt the function DeLink, so I added a new one DeAttach.) Francis March 05, 2007, at 05:03 AM
See Also Cookbook:WikiFormsRecipes#attach
PHP error message upon editing password-protected pages, date field related (PmWiki 2.1.21, WikiForms 1.48, 1.50)This one took me unaware, but it's sort of a biggie. If I edit a page that is protected by a write password and I have not entered that write password yet, I get the following error messages:
The error occurrs in the line that implodes the date field: implode('-',$_REQUEST[$f[$i]['element']]));
The result is the loss of the data entered in the date field. The sequence is as follows:
(I have set up numerous WikiForm instances in my Wiki, but they are either not password-protected at all, or they are protected by a read password that simultaneously serves as write password, so the password prompt never came up precisely after pressing "Edit Form" before.) --Henning September 15, 2006, at 09:36 AM Version 1.50 may fix this problem. I changed the code to open forms for editing with $auth='edit', so now PmWiki should prompt for a password before loading the form for editing, not after. jr 27 Sep 2006
Unfortunately, the problem remains the same (but the warning occurs in line 449 now, confirming that I'm using the new version). Should I use a specific version of PmWiki? I have not upgraded to 2.2.x yet. --Henning September 29, 2006, at 11:52 AM Layout problem with ?update=y (PmWiki 2.1.21, WikiForms 1.50)I've found a layout problem with the ?update=y action: If an updatable link is displayed in a table field and the link text is close to the maximum size of the field, the update symbol vanishes (MS Internet Explorer) or moves to the left side, graphically overlapping the attach link (Opera). I'm not using any special CSS files. I suspect that the upload symbol is not figured in when determining table row height, and the apparently vanished symbol is actually moved to the (invisible) second line in a table field if it's wrapped around. (I'm using the default upload symbol which appears to be a superscript Delta.) --Henning October 23, 2006, at 10:18 AM PITS |