[pmwiki-users] wikipublisher questions

John Rankin john.rankin at affinity.co.nz
Sun Apr 2 21:45:48 CDT 2006


On Monday, 3 April 2006 9:54 AM, noskule at gmx.net wrote:
>hi john
>PDF Links:
>* possability to customize the pdf links on the various locations (page, 
>wikiforms, wikitrail, wikilog) example in my case with a simple pdf icon 
>to the delivery-window(I'll whait, Email me)

Yes, these are all controlled by Fmt variables: $PublishCalendarFmt,
$PublishWikiFormFmt, $PublishTagFmt, $PrintTagFmt, $PageTypesetFmt, 
$FPLByGroupEndFmt (search). In turn, apart from $PageTypesetFmt,
these use $PDFOptionsFmt to insert the Options button.

I'll add this to the documentation.
>
>
>Dialogs:
>* provide a "pdf options" link in the delivery-window

The following could be achieved without too much effort:

- remove all the PDF options buttons and links

- add a PDF options button to the wikipublisher screen

- pressing PDF options takes you to the same screens you see at
  present

- pressing Submit *takes you back to the Wikipublisher screen*

The biggest issue is passing the data through corrently, but it
ought to be possible. I think a case can be made either way as to
whether this is better or worse than the current design. I'll
think about it.

To process the pdf request on the options screen is a *big* problem.
The options screen uses the wikiforms script, which is really quite 
stupid -- all it does is raise a form and send back the values for 
another script to process. Wikiforms itself knows nothing about
wikipublisher and it doesn't currently support multiple user-defined
buttons and layout control and the other stuff that the Wikipublisher
screen does for us and that you propose. 

So your image 1 is quite feasible, but your image 2 could be a great 
deal of effort to realise. Of course, we can do anything, given enough
time and money. Personally, I think it's a good thing that all PDF
requests leave the site from the same screen.

Of course, an administrator can write his or her own forms handler,
if desired -- you don't have to use the one we use. If you prefer
the interface shown in your example, there is nothing to stop you
from creating your own set of handlers and plugging them in.
Wikipublisher is configurable by design.

>* be klick "email" or "I'll wait" the users gets back to the wikipage 
>without to push  "Back to Page"

Your best bet is to customise the Fmt variables above so that they 
open new windows, and the user closes the window to get back.
>
>Buttons:
>* change "Email me" to "Email to" cause the user will probably not email 
>the pdf to himself, and if he does, it will not be wrong ida.

I think standard practice is to put buttons after their fields, 
not before, so would do it like this:

[.................] ( Email )

rather than

( Email to ) [.................] 

>* change "I'll whait" to "Download" cause 1.you dont no if the user 
>will/wants to whait , 2. it's not the description of the operation but 
>of the thing betwean, 3. you told them in the text allready that they 
>may have to whait and 4. It is bad attitude in our world of fast 
>processors and not god for the wikipublisher image ;-)

Good points! I'll change it.
>
>I dont mean the things  should be standard but would be nice if they 
>could realized . ..

You can do this just by editing the Site.Wikipublisher page:

(:wikipublisher wait='Download' email='Email' :)

but I'll change it in the next release.

<snip>
>>
>>Currently, as long as you are in the wiki, no new windows open;
>>  
>>
>this rule seams a bit to "general". IMO the question should be *what* 
>does the user on the page, and what he does next, than rather only the 
>next destination. So in the pdf operation the user will continue 
>browsing where he "stoped" to make the pdf. One solution to provide this 
>is a new window (cause if he close it he stands there where he want to 
>continue). It dont have to be the "new window" solution, but after the 
>pdf operation the users should stay automaticly at the right page to 
>continue browsing.  This may could be done that be pressing the "whait" 
>or "email" button the page changes to the wikipage where the user pushed 
>the pdf button. For my taste it would be the best solution (better than 
>new window)

If you can figure out how to do this, let me know!

We decided that in most cases generating a pdf is an occasional
activity and saving one button press wasn't worth the extra 
development effort. YMMV.

-- 
JR
--
John Rankin






More information about the pmwiki-users mailing list