[pmwiki-users] More answers to: More Wikiforms

John Rankin john.rankin at affinity.co.nz
Wed Aug 1 21:06:11 CDT 2007


On Thursday, 2 August 2007 7:30 AM, Sameer Kumar <skumar at eharch.com> wrote:
>
>1. I see where the value= is coming from. In wikiform.php, look for:
> 
><snip>
> 
>2. The extra \\ characters, there are several possibilities.
><snip>
> 
>I will wait to hear from you.
> 
Bad news! I have tested this and it works correctly for me.
Can you give me access to a version of the wiki where
I have edit rights? That is, I can try the form for myself
and see exactly what is happening when you create a
new entry. Ideally, I'd like a plain pmwiki install, with
just the wikiforms recipe and default settings.

I can tell you where the problem is arising, I think.
In the FormData function is the line:

            $v = preg_replace("/([\\\]+\\n)+$/",'',
                implode("\\\\\\\\\n",$_REQUEST[$f[$i]['element']]));

This is supposed to produce the following field value:

line1\\
line2\\
line3

And on my system, it does.

In your case it appears to be taking all the \ characters 
literally. I am guessing that it's a php configuration
thing. You could try changing that line to:

            $v = preg_replace("/([\\\]+\\n)+$/",'',
                implode("\\\\\n",$_REQUEST[$f[$i]['element']]));

and see what you get...

>3. The Projectstext title.
> 
><snip>
> 
>4. The discussion page links.
> 
><snip>
> 
>Also, the View link doesn't pick up the view template.
>I think this is because of the ?action=view -- it won't
>let me save edits to Comments.PageActions, so I can't test
>this. Try removing the '?action=view' on the first item;
>I don't think it's needed.
> 
>It does not let me remove or modify 60;?action=view61;70; As
>soon as I do it, the 60;View61; tab goes dead and stops being a link.
>

We might have to contact the recipe author, but here is my guess...
In your local/config.php:

If you add the following line *before* you load wikiform.php:

    if ($action=='view') $action = 'browse';

that *might* fix it. However, if the other recipe relies on $action=='view',
you might have to load that recipe before you load wikiform.php.

>-------------------------------------------------------
> 
>John, I have a concern: What happens when a user wants to
>create a link to a Project page from another page? It seems
>that they will have to know the five digit number, isn57;t it?
>This means that by simply adding 56;[[56; and 56;]]57; to a
>wikiword, they may not be able to create a link. Would you
>agree that this would be a loss of an important functionality?
> 
The ability to link to a page using its title is not part of pmwiki's core
functionality AFAIK. So I think what you are really saying is that using
numbered page names makes them harder to link to when the numbered
pages have been given titles. This is true of any pmwiki page containing
a (:title:) directive -- to link to a page, you need to know its name.

Because several people have wanted to link to a form-generated page
using that page's title, I created the formtitle.php script. Let's come
back to this when the other problems are resolved -- it adds another
layer of complexity. I think we will be able to achieve what you want,
*provided that* the authors always fill in the title field.

>I have been wondering if it would be better if the actual
>project form is Project.Projectname which 60;includes61; the
>Project.00001 page instead of it being the other way round.
> 
>This would mean the following:
>1.   The user still creates a new page with the 56;Add a new project57; wikiform.
>2.   When the form is submitted, the form data is saved in
>Projects.00001 and the screen changes to
>Projects.Museum?action=edit for the user to now create the actual Project page.
>3.   Upon save, the user is presented with a Projects.Museum
>form with Projects.00001 already 56;included57;, complete with
>a 60;=>Edit form61; link which would take the user back to
>Projects.00001 form page for editing of the form data.
>4.   The important thing will be to ensure that pmwiki
>understands the relationship between Projects.00001 and Projects.Museum.
>5.   This will ensure that the project page is Projects.Museum and not Projects.00001.
> 
>What do you think? Is this achievable?
> 
>S
You would need robust solutions to the following questions:

1. How do you link from Projects.00001 to Projects.Museum?

You are reliant on somebody to enter 'Museum' somewhere on the
form. It the author leaves that field blank, you are in trouble.

On the other hand, with Projects.00001 and Projectstext.00001
you can generate the link automatically.

2. How do you link from Projects.Museum to Projects.00001?

You could rely on the text of Projects.Museum containing
[[Projects.00001]] but an author can simply edit that out
and the link is lost.

Or you will have to maintain a separate Projects.NamesAndNumbers
page to cross-reference the pages and look this up whenever you
come to link from Museum to 00001.

On the other hand, with Projects.00001 and Projectstext.00001
you can generate the link automatically.
 
3. How do you *guarantee* this never breaks?

For example, what is to stop an author from linking Projects.00009
to Projects.Museum too?

The best idea I can think of is to create text pages of the form:

Projects.00001-Museum instead of Projectstext.00001 or
Projects.Museum.

That way, you can expand the name around the -- and use the
numeric prefix to link to the form page with the alphabetic
suffix as the title.

However, this doesn't meet your wish to be able to link to
[[museum]]. So I think yiu might be faced with a trade-off
between convenience and robustness. You can have a fragile
solution with memorable page names or a robust solution
with numeric page names.

At first sight, your suggestion solves the immediate
problem, but creates others. On the whole, I think
it might be a step backwards, but it may be that I just
haven't seen how to make it work. Let's come back
to it when everything else is sorted out.
-- 
JR
--
John Rankin






More information about the pmwiki-users mailing list