[pmwiki-users] Input Select To Trigger Go To Page

[Patrick R. Michaud]

On Wed, May 09, 2007 at 09:50:34AM -1000, Sivakatirswami wrote:
> Under the previous "input" recipe structure
> 
> Project Pages:
> (:input form:)
>      (:select+ project:)
>        (:option :)Jump To Page:
>        (:pagelist group={$Group} name=-RecentChanges 
> fmt="#selectlistpages":)
>       (:selectend:)
> (:input end:)
> (:ifend:)
> 
> [@
> [[#selectlistpages]]
> (:option value="index.php?n={=$FullName}":)(:keep {=$Name}:)
> [[#selectlistpagesend]]
> @]
> 
> would trigger at GET request for PMwiki to go to another  page without 
> further need to add code to the configuration file. 

The only reason this "worked" before is because an external
recipe had configured the (:select+:) and/or (:option:) directive
to make it work.  In this case you did add code to the configuration
file -- it was just provide by a recipe as opposed to being
entered manually.

We can certainly come up with a similar recipe for the PmWiki
(:input:) markup.

> So before I 
> "throw in the towel" and swallow yet another 15 lines of archane 
> Javascript that I don't understand, will never be be able to fix, 
> is unmaintainable, cannot transfer to someone else etc...
> 
> I'm looking for a clear answer, first... what broke and why?

AFAIK, nothing has changed in PmWiki that would break the
select/option markup.

> 1) The old code cannot and will not be able to be
> simply re-written because ZAP no longer supports it?

Only Dan can answer this one.

> 
> 2) Or No the old (:option value="index.php?n={=$FullName}":)(:keep 
> {=$Name}:)
> cannot be change to a "input select" variation that works because
> PMwiki core no  longer supports it?

The PmWiki core never "supported" the (:option ...:) markup; that
was being provided by a recipe.  But neither has the core changed
such that an (:option:) markup will no longer work.

> ## is it a ZAP change or a PMwiki input core change the broke it?

See above.

> or (hopefully)
> 
> 3) yes there is a way to re-write
> (:option value="index.php?n={=$FullName}":)(:keep {=$Name}:)
> 
> in the some new fashion of
> 
> (:input select  value="index.php?n={=$FullName}":)(:keep {=$Name}:)
> 
> That will trigger a GET request for the page selected in the pull down.

My official position on this is that there should be a recipe
that adds an (:input jumpbox:) markup that can be used for this
feature.

> You see: I'm a bit spoiled because I use another language for almost
> all my CGI and desktop application development: Revolution and
> in that environment:
> [...]
> is all that I would need to get this done...3 lines in a desktop app, 5 
> lines in a CGI.
> so when I see these things like
> 
> "add this java garble to your config file"  it pushes a big button:
>   "why does it have to be so complicated... isn't there
> a simpler way?"

The overall amount of complexity remains constant -- the only question
is who gets to deal with the complexity.  

In the Revolution environment the complexity is still present, you 
just don't see it because it's all hidden behind the 3 or 5 lines
of code you write.  But, there's a key difference here -- I would
suspect that Revolution doesn't allow scripting to be performed
by lots of people who interact with the environment.  PmWiki is
a collaborative editing environment, and we generally don't want
to allow "any editor" to be able to do arbitrary functions in
Javascript or HTML.

In the case of PmWiki, complexity can go in the core, in a recipe,
in a configuration file, or in the wiki markup.  Thus far I've
decided that "jumpbox" doesn't automatically warrant inclusion
in the core, which means it's either a recipe or a local 
customization.  Eventually I (or someone else) will write it
as a recipe, and when that happens then it really will be
as simple as writing things like  (:input jumpbox:) or
(:pagelist fmt=#jumpbox:).  But until then, all we have is
the configuration code.

Pm