[pmwiki-users] wikipublisher questions

[noskule]

John Rankin schrieb:

>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.
>  
>
cool, I will work on it if its published.

>>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.
>
At the moment theres no concret commercial project, but if, that could 
happen . . ..

>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 ) [.................]
>  
>
yep better, but at least it sould be consistent in a way. To write:
 Email to [......] submit
needs so much space .. .

>  
>
>>* 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!
>  
>
Hm, I ask this in a forum, hope i get an answer, I would try to put the 
following code:

header("Location:|{$PageUrl}|");

at the end of the  point where publishpdf executes the form submit 
command, but I couldnt find  the location in the code. (thats just from 
a "not realy understand php view). But if you could provide me with a 
hint where it is I try  out some things . . . .

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