[pmwiki-users] wikipublisher questions
john.rankin at affinity.co.nz
Mon Apr 3 17:08:54 CDT 2006
On Tuesday, 4 April 2006 1:29 AM, noskule at gmx.net wrote:
>John Rankin schrieb:
>>- 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
>>- pressing Submit *takes you back to the Wikipublisher screen*
>>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 . . ..
Just be aware that we implemented what was feasible, given the
constraints of time, cost, skill, and reuse of existing code. We
didn't start with an unconstrained "ideally the interface would
look like this, how do we implement it"; rather we started with
"these are the constraints, what's the best interface we can build".
The hard part of your approach is that the Options button has to
be context sensitive; it needs to know which of the many kinds of
typesetting request is being made and generate a different form
with different hidden variables in each case. On the other hand,
by making it an extra button on existing forms, it already has
the information it needs, 'cos it's already there in the form.
This also let us add the options code incrementally -- with it
on the Wikipublisher page, you have to implement all or nothing.
In your approach, every time one adds a new type of typesetting
command (someone wants to publish a calendar from one of the
other calendars, for example), one has to do everything twice:
once in the code to add a Typeset button and once to add a new
kind of Option. And you don't have a choice -- you can't choose
not to offer Options for a particular service, or turn it off
temporarily because something has broken.
In other words: do not underestimate the complexity of what you
are proposing. I'm not yet convinced that the benefits are worth
the costs. Still, if you have a real project with a real budget,
let us know!
>>[.................] ( Email )
>>( Email to ) [.................]
>yep better, but at least it sould be consistent in a way. To write:
> Email to [......] submit
>needs so much space .. .
Yes, we tried and rejected that for the same reason.
Version 2.0.4 uses 'Email'.
>>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
>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 . . . .
It may not be that simple. The form sends you to the url of the
wikipublisher server, which may be in the same window or a new one.
So you are handing off control to another server. As I say, I don't
know enough to answer your question (hence the constraint about
building what we had the skill to build, which may not be what one
wants to build).
Cheers and thanks again for the comments. I hope you don't mind that
my answer boils down to "I don't know and it's too hard to figure out."
More information about the pmwiki-users