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

Sivakatirswami katir at hindu.org
Thu May 10 04:12:51 CDT 2007


Thank you!  That's a very clear answer. Bottom line answer being:

No, at this time there is no syntax under the new "input select"
mark up to trigger a GET request from a page list selection.
And that this is a result of changes in ZAP, not PMwiki core.

which is all I was really asking...

but this was also instructive;

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

Good point and point well taken.

So it was ZAP (that contained the "complexity")
which changed putting the burden of making it work back
on an a manual entry in the config file.

Understood. As you say, whether its 20 line of code in a recipe
or 20 lines of code in PMwiki core or 20 lines of code in the farmconfig.php

it's still the same "overall amt"

And this is a useful insight also:

 > 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.

That make sense as well. I guess I'm a "blickered" by
dealing in completely closed wiki context (only very trusted
users ever get in) but I can see that the PMwiki core must
work across more open environments... and security would
mandate making sure that open tickering at the
mark up level wasn't too broadly "accepted." by the core.

OK, then,  I will have to make the jumpbox recipe work.
(right now it's not... I tried it...)

Thank you for your patience in explaining the
situation.

Sivakatirswami

Patrick R. Michaud wrote:
> 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
> 




More information about the pmwiki-users mailing list