Re: Specifying page template for new pages in URL

Hi 

Gerry, you are conflating layout templates (css, images,
etc) used to view 
the wiki with page templates used when *editing* pages and
rather 
inflexibly implemented in dokuwiki with _template.txt in a
namespace see 
h
ttp://wiki.splitbrain.org/wiki:namespace_templates .

Jason, I agree a more flexible mechanism is needed...   at
the moment 
there appears to be only 
ht
tp://wiki.splitbrain.org/plugin:template_chooser which I
haven't tried, 
and requires hacking various js bit and which might be out
of date...

Regards
-ant

dokuwiki-bouncefreelists.org wrote on 2007/02/22 10:07:58
AM:

> Hi Jason,
> 
> have a look at 
> http://wiki.gammaproduction.de/english/dokuwi
ki/plugins/tplswitcher 
> maybe there is something that might help you. The only
problem i figured 

> is, that the template change has to be registered in a
session so that 
> the style will be loaded correctly too. Give it a try.
> 
> Gerry.
> 
> Jason Grout wrote:
> > Hi everyone,
> > 
> > I'm trying to make my classroom wiki easier to use
for my students.  I 

> > use the namespace template to provide templates
for student pages that 

> > answer homework questions.  However, this is
awkward for a few 
reasons:
> > 
> > 1. If student homework answer pages are in
different namespaces, then 
I 
> > have to copy the _template.txt file to each
namespace.  I can't do 
this 
> > directly because dokuwiki creates the directories,
so I can't just 
copy 
> > things around on the server.  I know how to work
around this, but it's 

> > just awkward (right now I use PHPShell to work
from the commandline as 

> > the webserver).
> > 
> > 2. If the homework answer pages are in the same
namespace, but require 

> > different templates, it's not possible to use the
namespace template 
> > feature.
> > 
> > It would be nice if I could specify a template to
use in the URL. 
Then, 
> > for example, the addnewpage plugin could be
modified so I could write 
> > something like:
> > 
> > To submit homework assignment 2, type a page name
here and press the 
> > "Add Page" button:
> > 
> > {{NEWPAGE>:homework: |
template=:homeworktemplates:homework1}}
> > 
> > 
> > Is there a way to specify in the URL a template to
use when creating a 

> > page?  I'm thinking of something like:
> > 
> > 
doku.php?id=:homework:problem20&do=edit&rev=&tem
plate=:homework:homework2
> > 
> > 
> > 
> > Thanks,
> > 
> > Jason
> -- 
> DokuWiki mailing list - more info at
> http://wi
ki.splitbrain.org/wiki:mailinglist



Disclaimer
Sanlam Life Insurance Limited Reg no 1998/021121/06 -
Licensed Financial 
Services Provider
Disclaimer and Directors
-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Anthony.CaetanoSanlam.co.za writes:

> Jason, I agree a more flexible mechanism is needed...  
at the moment 
> there appears to be only 
> ht
tp://wiki.splitbrain.org/plugin:template_chooser which I
haven't tried, 
> and requires hacking various js bit and which might be
out of date...

There is a plugin hook in the page template loading
mechanism (at least in 
the curent devel) which could be used to add the wanted
functionality to the 
addnewpage plugin.

Andi

-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Anthony.CaetanoSanlam.co.za wrote:
> Hi 
> 
> Gerry, you are conflating layout templates (css,
images, etc) used to view 
> the wiki with page templates used when *editing* pages
and rather 
> inflexibly implemented in dokuwiki with _template.txt
in a namespace see 
> h
ttp://wiki.splitbrain.org/wiki:namespace_templates .
> 
> Jason, I agree a more flexible mechanism is needed...  
at the moment 
> there appears to be only 
> ht
tp://wiki.splitbrain.org/plugin:template_chooser which I
haven't tried, 
> and requires hacking various js bit and which might be
out of date...


Yes, that's right.  I am talking about the page templates
used when 
editing pages, not the layout templates.

The template chooser requires too much action for the user
and also 
requires javascript, which takes it out of the picture for
me.  Also, it 
didn't seem to be able to automatically put in different
templates 
depending on URL parameters, though I suppose that
functionality could 
be added.

So I guess this answers my question that no, the
functionality doesn't 
exist right now, but I'm more than welcome to write it! 


Thanks,

Jason
-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Andreas Gohr wrote:
> Anthony.CaetanoSanlam.co.za writes:
> 
>> Jason, I agree a more flexible mechanism is
needed...   at the moment 
>> there appears to be only 
>> ht
tp://wiki.splitbrain.org/plugin:template_chooser which I
haven't 
>> tried, and requires hacking various js bit and
which might be out of 
>> date...
> 
> There is a plugin hook in the page template loading
mechanism (at least 
> in the curent devel) which could be used to add the
wanted functionality 
> to the addnewpage plugin.
> 
> Andi
> 


I looked on the events list page at:

http://wi
ki.splitbrain.org/wiki:events_list

Are you referring to the HTML_EDITFORM_INJECTION or 
HTML_PAGE_FROMTEMPLATE events?  It seems like the
HTML_PAGE_FROMTEMPLATE 
might be an interesting one to look at.

Let me make sure that I understand the event system.  I can
register a 
callback function that will be called when the event is
triggered.  From 
the documentation and the source in html_edit, it appears
that the only 
information I have to work with in the
HTML_PAGE_FROMTEMPLATE is the ID 
of the page being created.  That's not enough for my
purposes (I can't 
necessarily tell what template I want just from the
namespace), though 
it's a start.  Is there a way to access the URL parameters
from the 
event callback?  I'm sorry if I seem to have a fixation on
the URL 
parameters, but it's the only way I can think of passing the
name of a 
desired template to the create/edit page.

Thanks,

Jason
-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Jason Grout wrote:
>
> I looked on the events list page at:
>
> http://wi
ki.splitbrain.org/wiki:events_list
>
> Are you referring to the HTML_EDITFORM_INJECTION or 
> HTML_PAGE_FROMTEMPLATE events?  It seems like the 
> HTML_PAGE_FROMTEMPLATE might be an interesting one to
look at.
>
> Let me make sure that I understand the event system.  I
can register a 
> callback function that will be called when the event is
triggered.  
> From the documentation and the source in html_edit, it
appears that 
> the only information I have to work with in the
HTML_PAGE_FROMTEMPLATE 
> is the ID of the page being created.  That's not enough
for my 
> purposes (I can't necessarily tell what template I want
just from the 
> namespace), though it's a start.  Is there a way to
access the URL 
> parameters from the event callback?  I'm sorry if I
seem to have a 
> fixation on the URL parameters, but it's the only way I
can think of 
> passing the name of a desired template to the
create/edit page.
>
> Thanks,
>
> Jason

Sure,  $_GET['my_var'] !
-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Chris Smith wrote:
> Jason Grout wrote:
>>
>> I looked on the events list page at:
>>
>> http://wi
ki.splitbrain.org/wiki:events_list
>>
>> Are you referring to the HTML_EDITFORM_INJECTION or

>> HTML_PAGE_FROMTEMPLATE events?  It seems like the 
>> HTML_PAGE_FROMTEMPLATE might be an interesting one
to look at.
>>
>> Let me make sure that I understand the event
system.  I can register a 
>> callback function that will be called when the
event is triggered.  
>> From the documentation and the source in html_edit,
it appears that 
>> the only information I have to work with in the
HTML_PAGE_FROMTEMPLATE 
>> is the ID of the page being created.  That's not
enough for my 
>> purposes (I can't necessarily tell what template I
want just from the 
>> namespace), though it's a start.  Is there a way to
access the URL 
>> parameters from the event callback?  I'm sorry if I
seem to have a 
>> fixation on the URL parameters, but it's the only
way I can think of 
>> passing the name of a desired template to the
create/edit page.
>>
>> Thanks,
>>
>> Jason
> 
> Sure,  $_GET['my_var'] !

Aaah, right.  I figured it would be bad form to tamper with
the $_GET 
variable or assume that it exists.  It certainly gets the
job done, 
though, so if it's considered okay coding style, I'm all for
it.  It 
sounds like the HTML_PAGE_FROMTEMPLATE is all that is
needed, and I 
think that is triggered in the current stable release.  So I
guess I 
have the tools to do the job.  Just need to find the time
now...

Jason

-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Chris Smith wrote:
> Jason Grout wrote:
>>
>> I looked on the events list page at:
>>
>> http://wi
ki.splitbrain.org/wiki:events_list
>>
>> Are you referring to the HTML_EDITFORM_INJECTION or

>> HTML_PAGE_FROMTEMPLATE events?  It seems like the 
>> HTML_PAGE_FROMTEMPLATE might be an interesting one
to look at.
>>
>> Let me make sure that I understand the event
system.  I can register a 
>> callback function that will be called when the
event is triggered.  
>> From the documentation and the source in html_edit,
it appears that 
>> the only information I have to work with in the
HTML_PAGE_FROMTEMPLATE 
>> is the ID of the page being created.  That's not
enough for my 
>> purposes (I can't necessarily tell what template I
want just from the 
>> namespace), though it's a start.  Is there a way to
access the URL 
>> parameters from the event callback?  I'm sorry if I
seem to have a 
>> fixation on the URL parameters, but it's the only
way I can think of 
>> passing the name of a desired template to the
create/edit page.
>>
>> Thanks,
>>
>> Jason
> 
> Sure,  $_GET['my_var'] !

Okay, it's done.

There's a newpagetemplate action plugin that will look for
the 
"newpagetemplate" parameter in $_REQUEST.  If the
parameter exists, then 
the page is loaded as a template, with the substitutions
currently 
offered by the namespace templates.  Note that this
overrides the 
namespace template.

I have a quick question about my implementation.  In the
following, a 
BEFORE callback is an event handler registered with the
BEFORE 
advisement (sp?), and similarly for an AFTER callback. I
implemented the 
plugin as a BEFORE callback, then manually set the
$event->result 
variable and called $event->preventDefault().  Is that
all right to do 
in a BEFORE callback?  The documentation seems to indicate
that you 
should only mess with $event->result in an AFTER
callback.  However, I'd 
just as soon not go through the expense of loading the
default namespace 
template if I know I'm overriding it.  I suppose I could
make two 
callbacks, one BEFORE and one AFTER, with the BEFORE
callback checking 
the $_REQUEST variable and preventing the default, while the
AFTER 
callback actually loads the page, but that seems wasteful as
well.

I've also patched the addnewpage plugin to take advantage of
the 
newpagetemplate functionality.  The new syntax is:

{{NEWPAGE>ns|:newpage:template}}

where the new page template follows the vertical bar.  I
posted the 
patch up to the addnewpage plugin discussion area.

Thanks again for everyone's help!

Jason
-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Jason Grout wrote:
>
> Okay, it's done.
>
> There's a newpagetemplate action plugin that will look
for the 
> "newpagetemplate" parameter in $_REQUEST.  If
the parameter exists, 
> then the page is loaded as a template, with the
substitutions 
> currently offered by the namespace templates.  Note
that this 
> overrides the namespace template.
>
> I have a quick question about my implementation.  In
the following, a 
> BEFORE callback is an event handler registered with the
BEFORE 
> advisement (sp?), and similarly for an AFTER callback.
I implemented 
> the plugin as a BEFORE callback, then manually set the
$event->result 
> variable and called $event->preventDefault().  Is
that all right to do 
> in a BEFORE callback?  The documentation seems to
indicate that you 
> should only mess with $event->result in an AFTER
callback.  However, 
> I'd just as soon not go through the expense of loading
the default 
> namespace template if I know I'm overriding it.  I
suppose I could 
> make two callbacks, one BEFORE and one AFTER, with the
BEFORE callback 
> checking the $_REQUEST variable and preventing the
default, while the 
> AFTER callback actually loads the page, but that seems
wasteful as well.
>
> I've also patched the addnewpage plugin to take
advantage of the 
> newpagetemplate functionality.  The new syntax is:
>
> {{NEWPAGE>ns|:newpage:template}}
>
> where the new page template follows the vertical bar. 
I posted the 
> patch up to the addnewpage plugin discussion area.
>
> Thanks again for everyone's help!
>
> Jason

There aren't so many rules in how you do things in a
plugin.

The method you have chosen seems sensible.  If a plugin
needs to modify 
an existing result it should handle  the "AFTER" 
event - in so much as 
there is a result, it is guaranteed to exist.  If a plugin
provides a 
result "instead of" the DW result it really should
do that using the 
"BEFORE" advise and call preventDefault(), that
way you are maintaining 
the model that "AFTER" handlers will see the
result.  You're doing that. 

If this isn't  clear in the documentation, please feel free
to enhance 
it 

Cheers,

Chris

PS.  I think the above may be the argument I missed for the
original 
three advise system.

before event - prepares the data
event - creates a result
after event - modifes a result

Under our present system, where order isn't guaranteed, one
before 
handler that prepares the data may be called after a
different handler 
that sets a result.

Any one for a change 



-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Chris Smith wrote:
> Jason Grout wrote:
>>
>> Okay, it's done.
>>
>> There's a newpagetemplate action plugin that will
look for the 
>> "newpagetemplate" parameter in $_REQUEST.
 If the parameter exists, 
>> then the page is loaded as a template, with the
substitutions 
>> currently offered by the namespace templates.  Note
that this 
>> overrides the namespace template.
>>
>> I have a quick question about my implementation. 
In the following, a 
>> BEFORE callback is an event handler registered with
the BEFORE 
>> advisement (sp?), and similarly for an AFTER
callback. I implemented 
>> the plugin as a BEFORE callback, then manually set
the $event->result 
>> variable and called $event->preventDefault(). 
Is that all right to 
>> do in a BEFORE callback?  The documentation seems
to indicate that 
>> you should only mess with $event->result in an
AFTER callback.  
>> However, I'd just as soon not go through the
expense of loading the 
>> default namespace template if I know I'm overriding
it.  I suppose I 
>> could make two callbacks, one BEFORE and one AFTER,
with the BEFORE 
>> callback checking the $_REQUEST variable and
preventing the default, 
>> while the AFTER callback actually loads the page,
but that seems 
>> wasteful as well.
>>
>> I've also patched the addnewpage plugin to take
advantage of the 
>> newpagetemplate functionality.  The new syntax is:
>>
>> {{NEWPAGE>ns|:newpage:template}}
>>
>> where the new page template follows the vertical
bar.  I posted the 
>> patch up to the addnewpage plugin discussion area.
>>
>> Thanks again for everyone's help!
>>
>> Jason
>
> There aren't so many rules in how you do things in a
plugin.
>
Okay, that clears up a few things.  However, the structure
was one of 
the biggest reasons I chose DokuWiki (PmWiki seemed like
spaghetti code 
in comparison, for instance, but I didn't get to know it
very well).  I 
guess I love having a nice, clearly structured way of doing
things.  The 
hard part is making the structure as flexible as it needs to
be, but 
still clear enough to be useful.


> The method you have chosen seems sensible.  If a plugin
needs to 
> modify an existing result it should handle  the
"AFTER"  event - in so 
> much as there is a result, it is guaranteed to exist. 
If a plugin 
> provides a result "instead of" the DW result
it really should do that 
> using the "BEFORE" advise and call
preventDefault(), that way you are 
> maintaining the model that "AFTER" handlers
will see the result.  
> You're doing that. 
>
> If this isn't  clear in the documentation, please feel
free to enhance 
> it 
>
> Cheers,
>
> Chris
>
> PS.  I think the above may be the argument I missed for
the original 
> three advise system.
>
> before event - prepares the data
> event - creates a result
> after event - modifes a result
>
> Under our present system, where order isn't guaranteed,
one before 
> handler that prepares the data may be called after a
different handler 
> that sets a result.
>
> Any one for a change 
>

(changing title to reflect a discussion on the event
system)

So really my plugin should be _replacing_ the default event.
 It should 
be called after the BEFORE callbacks, replace the default
event, and 
before the AFTER callbacks.

Here's an idea, taken from the Common Lisp object system
(which is 
amazing, by the way , but is
also a natural extension of what we have 
here already.

There are three advisements: "BEFORE",
"" (empty string), and "AFTER".  
Specifying "BEFORE" gives a BEFORE callback,
"" gives a primary 
callback, and "AFTER" gives an AFTER callback. 
These are then called 
thusly:

  - First, all BEFORE callbacks are called.  It might be
nice here to 
allow a callback to stop the propagation of BEFORE
callbacks, jumping 
straight to primary callbacks.  However, the job is to
prepare data, so 
I can't stop the primary callbacks or AFTER callbacks.  The
only thing 
that the BEFORE callbacks should mess with is $data.
  - Second, all primary callbacks are called, with the
default callback 
being called last.  Again, any callback can stop the
propagation (which 
also stops the default callback from being called).  The job
here is to 
fill $event->result with something meaningful.
  - Third, all AFTER callbacks are called.  Again, we can
stop the 
propagation at any time.  The job here is to modify the data
in 
$event->result. 

It would be nice if we could force an order to these
callbacks, but that 
can wait for another day.  When you say that order isn't
guaranteed, I 
assume that it _is_ guaranteed that all BEFORE callbacks
execute before 
the default method, which executes before all AFTER
callbacks, but that 
the order of BEFORE callbacks isn't specified and the order
of AFTER 
callbacks isn't specified.

It seems like it wouldn't be too hard to modify the existing
system to 
be like the system described above (famous last words, yeah,
I know).  
It would add a little structure to the existing system and
make it more 
clear how to implement different callbacks.

After doing a bit of research into other systems that use
events and 
triggers, here's something interesting that e107 wiki does (

http:/
/wiki.e107.org/?title=Core_event_trigger ):  You can
register a 
file that is loaded and function that is executed when an
event is 
triggered.  The idea is to not have to parse every single
callback 
function every time you load a page (is that DokuWiki does
now?).  I 
haven't done any profiling, (which is the first thing that
needs to be 
done to see if this will speed up things), but if we cut
down on the 
number of things we load, it can't be a bad thing.  I'd love
to see a 
huge speed increase in DokuWiki.


Thanks,

Jason

-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

I think Chris and Jason both gave eloquent descriptions of
why "BEFORE" 
and "AFTER" event callbacks are important. The
semantics of the event 
call backs are different. It has been a long time since the
early event 
system discussions, but I think this is essentially how it
is intended 
to work....

The current code could probably enforce the semantic
differences 
better. (Too sleepy to think this through any more clearly
at the 
moment.)

Regards, Ben Coburn


-------------------
   silicodon.net
-------------------

-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Jason, if you haven't already,  please check back in
the archives for 
our original discussions on events.  Quite a bit of what you
say was 
covered there.

Ben,
My original system did have three callbacks.  That was
reduced to 
two when there wasn't seen any real difference between
BEFORE and the 
event itself.  I think we've now found that difference 

all,
I don't think it would be difficult to add a new advisement.
 
Practically, its the same as BEFORE.  The difference is in
its 
recommended use. All existing plugins would continue to work
unchanged.  
In time their authors would decide whether or not their use
of the 
original BEFORE callback should take place during the data
preparation 
phase or during the action phase.

Jason. I don't think there is any need to add a
"stop further 
advisements" facility. Can you give an example of where
it could be useful?

Cheers,

Chris
-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Chris Smith wrote:
> 
> 
> Jason, if you haven't already,  please check back in
the archives for 
> our original discussions on events.  Quite a bit of
what you say was 
> covered there.

Thanks for the pointer.  I didn't realize the huge amount of
discussion 
that went on last April.  I suppose it should have been
obvious to me 
from the great design that exists now that a lot of thought
and 
discussion went into it.


> 
> Ben, My original system did have three callbacks. 
That was reduced to 
> two when there wasn't seen any real difference between
BEFORE and the 
> event itself.  I think we've now found that difference

> 
> all, I don't think it would be difficult to add a new
advisement.  
> Practically, its the same as BEFORE.  The difference is
in its 
> recommended use. All existing plugins would continue to
work unchanged.  
> In time their authors would decide whether or not their
use of the 
> original BEFORE callback should take place during the
data preparation 
> phase or during the action phase.

Because the order between BEFORE events is not guaranteed, I
think there 
is a nontrivial difference between BEFORE events and the
primary 
callback--it's not just a difference in labeling.  One place
(maybe the 
only place) the difference comes up when I want to replace
the default 
action of the event.  If I have one plugin that wants to
prepare data, 
but another plugin that acts on the data and replaces the
default 
action, I can't guarantee that the preparer plugin gets run
before the 
action.  In an (admittedly contrived) example, suppose I
have one plugin 
that performs redirects---it's always modifying the $id
attribute of 
events so that the default action is always acting on a
different page 
than what was originally set.  If I implement my replacement
action as a 
BEFORE callback, then I have no way of guaranteeing that the
redirect 
plugin can do it's job before I do my action.

I do agree that adding the new advise (or maybe I should say
the 
original third advise) would not break existing
functionality.  It would 
just provide more guarantees about when a callback is run.


> 
> Jason. I don't think there is any need to add a
"stop further 
> advisements" facility. Can you give an example of
where it could be useful?

There are two reasons I added that:

1. To my understanding, that is what the stopPropagation()
function 
already does.  I was carrying forward (what I thought was)
an 
already-existing feature.  Why a BEFORE callback would
prevent other 
BEFORE callbacks from being processed is debatable, though,
especially 
if the order in which the callbacks are processed is not
known.

2. stopPropagation() called in a primary callback (the new
advisement) 
is something like the preventDefault(), just relabeled to be
consistent 
with the idea that no other callbacks in the primary
callback list will 
be called.

Two comments:

1. the stopPropagation function doesn't seem to make much
sense when 
there is no control over the order in which the callbacks
are processed. 
As far as I can tell, it seems like the most likely uses of
the 
stopPropagation function are when you are saying either
"I want to be 
the only plugin to handle this, and I just hope that I'm the
first one 
called" or "I know absolutely that no other plugin
has any interest in 
handling this, so I'm going to just stop processing right
now to save 
time."  Either of these statements doesn't make much
sense.  You can't 
guarantee that you are the only one to handle a situation
(that's the 
whole point of the event system---to let people have access
to things), 
and you have no way of knowing that there will never be a
plugin 
interested in processing things after you are done
processing your bit.

2. As far as I can see, the preventDefault function has two
uses:
   (a) you are replacing the default action, so you don't
want the 
default action clobbering what you're doing.
   (b) you have some reason to want _nothing_ done---the
default or any 
other replacements for the default shouldn't happen.

In (a), with the proposed addition of a third "primary
callback" advise, 
you would implement your callback as a primary callback and
then use 
stopPropagation.

In (b), if you called preventDefault from a BEFORE callback,
then that 
had better also prevent _any_ primary callbacks from being
called, not 
just the default one.


I might have missed some things in the above comments. 
Please feel free 
to correct me.

Thanks,

Jason

-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Jason Grout wrote:
> Chris Smith wrote:
>>
>> Jason. I don't think there is any need to add a
"stop further 
>> advisements" facility. Can you give an example
of where it could be 
>> useful?
>
> There are two reasons I added that:
>
> 1. To my understanding, that is what the
stopPropagation() function 
> already does.  I was carrying forward (what I thought
was) an 
> already-existing feature.  Why a BEFORE callback would
prevent other 
> BEFORE callbacks from being processed is debatable,
though, especially 
> if the order in which the callbacks are processed is
not known.

Partly because it was carrying out three functions.  
- If it carries out a different version of the action any
other BEFORE 
handlers are no longer BEFORE (this reason would be removed
by a change 
to three advisements). 
- If it alters the event data in such a way as to make it
unreliable for 
other handlers to process the data.
- If it terminates the event.

 iirc, stopPropagation only prevents further propagation of
the current 
advisement, it doesn't have any effect on other
advisements.

>
> 2. stopPropagation() called in a primary callback (the
new advisement) 
> is something like the preventDefault(), just relabeled
to be 
> consistent with the idea that no other callbacks in the
primary 
> callback list will be called.
>
> Two comments:
>
> 1. the stopPropagation function doesn't seem to make
much sense when 
> there is no control over the order in which the
callbacks are processed. 
Order shouldn't affect whether or not its called.   The
choice to call 
stopPropagation should be based on what the handler does.  
A plugin can 
not know what other plugins are installed in the system. 
Because of 
that it can't make any assumptions about what it comes
before or 
after.   A plugin should make the decision to call
stopPropagation 
because it has done something that makes any further
handlers unsafe or 
unnecessary.

> As far as I can tell, it seems like the most likely
uses of the 
> stopPropagation function are when you are saying either
"I want to be 
> the only plugin to handle this, and I just hope that
I'm the first one 
> called" or "I know absolutely that no other
plugin has any interest in 
> handling this, so I'm going to just stop processing
right now to save 
> time."  Either of these statements doesn't make
much sense.  You can't 
> guarantee that you are the only one to handle a
situation (that's the 
> whole point of the event system---to let people have
access to 
> things), and you have no way of knowing that there will
never be a 
> plugin interested in processing things after you are
done processing 
> your bit.
e.g. a plugin to verify that a registration form was filled
in by a real 
person not a spam bot.  If it detects a spam bot, it
determines the 
registration will not go ahead.  It issues a stopPropagation
and a 
preventDefault.  If it passes the registration it does
neither of 
these.  A second plugin to handle a ban list does a similar
thing based 
on its own decision making process.   Swap the order and the
same thing 
happens.

>
> 2. As far as I can see, the preventDefault function has
two uses:
>   (a) you are replacing the default action, so you
don't want the 
> default action clobbering what you're doing.
>   (b) you have some reason to want _nothing_ done---the
default or any 
> other replacements for the default shouldn't happen.
>
> In (a), with the proposed addition of a third
"primary callback" 
> advise, you would implement your callback as a primary
callback and 
> then use stopPropagation.
>
> In (b), if you called preventDefault from a BEFORE
callback, then that 
> had better also prevent _any_ primary callbacks from
being called, not 
> just the default one.
>
That is fair.

preventDefault in a BEFORE advisement should prevent both
subsequent 
advisements being triggered as well as preventing the
default action.
preventDefault in the EVENT advisement will only prevent the
default action.

stopPropagation should only prevent further propagation of
the current 
advisement.

That does leave an opening for a new mechanism for EVENT
handlers to 
prevent the AFTER advisement.  I think it would be
sufficient to add a 
parameter to preventDefault  to indicate whether or not to 
trigger an 
AFTER advise.   That would be like saying either:
- I have handle the default action, there are results which
should be 
made available via the AFTER advise.
- I have cancelled the action.  Nothing happened, ergo there
is nothing 
to be after, so don't issue an AFTER advise.

For the purposes of simplicity and clarity it may be better
to make 
three functions

preventDefault - cancel default action and EVENT advise. 
Includes one 
parameter to control issue of AFTER advise (defaults to
true).
stopPropagation - stop further propagation of this advise. 
Other advise 
are not affected.
cancelEvent -  stop propagation, do not issue any further
advise,  do 
not carry out the default action (when issued in BEFORE or
EVENT advises).

Cheers,

Chris



-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist

Chris Smith wrote:
> Jason Grout wrote:
>> Chris Smith wrote:
>>>
>>> Jason. I don't think there is any need to
add a "stop further 
>>> advisements" facility. Can you give an
example of where it could be 
>>> useful?
>>
>> There are two reasons I added that:
>>
>> 1. To my understanding, that is what the
stopPropagation() function 
>> already does.  I was carrying forward (what I
thought was) an 
>> already-existing feature.  Why a BEFORE callback
would prevent other 
>> BEFORE callbacks from being processed is debatable,
though, especially 
>> if the order in which the callbacks are processed
is not known.
> 
> Partly because it was carrying out three functions.  -
If it carries out 
> a different version of the action any other BEFORE
handlers are no 
> longer BEFORE (this reason would be removed by a change
to three 
> advisements). - If it alters the event data in such a
way as to make it 
> unreliable for other handlers to process the data.
> - If it terminates the event.

Those reasons make sense.  I guess I should call
stopPropagation in my
plugin right now, then.


> 
> iirc, stopPropagation only prevents further propagation
of the current 
> advisement, it doesn't have any effect on other
advisements.

Okay, that was what I was assuming (stopPropagation only
stops the
current advisement), but apparently didn't state clearly.




> 
>>
>> 2. stopPropagation() called in a primary callback
(the new advisement) 
>> is something like the preventDefault(), just
relabeled to be 
>> consistent with the idea that no other callbacks in
the primary 
>> callback list will be called.
>>
>> Two comments:
>>
>> 1. the stopPropagation function doesn't seem to
make much sense when 
>> there is no control over the order in which the
callbacks are processed. 

> Order shouldn't affect whether or not its called.   The
choice to call 
> stopPropagation should be based on what the handler
does.   A plugin can 
> not know what other plugins are installed in the
system.  Because of 
> that it can't make any assumptions about what it comes
before or 
> after.   A plugin should make the decision to call
stopPropagation 
> because it has done something that makes any further
handlers unsafe or 
> unnecessary.
> 

Aaah, I think I understand better now.  Going back to an
idea from last
April, there is a contract between DokuWiki and a plugin
about what is
in the information passed with an event.  If a plugin
violates that
contract by changing the information, then other plugins
should not be
called.  Is that a correct way to think about it?  I can see
a case made
for passing the event data by reference into the callbacks
so they can
modify whatever they want, but I can also see the case made
for passing
a copy of the event data in so that one plugin can't
accidentally mess
up everyone else's data and violate the contract.

As for making things unnecessary, I hope that that is a rare
case---what
might be considered unnecessary now may not be considered
unnecessary in
the future.






>> As far as I can tell, it seems like the most likely
uses of the 
>> stopPropagation function are when you are saying
either "I want to be 
>> the only plugin to handle this, and I just hope
that I'm the first one 
>> called" or "I know absolutely that no
other plugin has any interest in 
>> handling this, so I'm going to just stop processing
right now to save 
>> time."  Either of these statements doesn't
make much sense.  You can't 
>> guarantee that you are the only one to handle a
situation (that's the 
>> whole point of the event system---to let people
have access to 
>> things), and you have no way of knowing that there
will never be a 
>> plugin interested in processing things after you
are done processing 
>> your bit.
> e.g. a plugin to verify that a registration form was
filled in by a real 
> person not a spam bot.  If it detects a spam bot, it
determines the 
> registration will not go ahead.  It issues a
stopPropagation and a 
> preventDefault.  If it passes the registration it does
neither of 
> these.  A second plugin to handle a ban list does a
similar thing based 
> on its own decision making process.   Swap the order
and the same thing 
> happens.

Right.  Okay, good point.  That's another situation when
you'd want to
call these functions.  And access control plugins
(allow/deny decisions)
can be swapped around as much as you want, as long as the
plugin does
nothing to allow and stops everything to deny.

> 
>>
>> 2. As far as I can see, the preventDefault function
has two uses:
>>   (a) you are replacing the default action, so you
don't want the 
>> default action clobbering what you're doing.
>>   (b) you have some reason to want _nothing_
done---the default or any 
>> other replacements for the default shouldn't
happen.
>>
>> In (a), with the proposed addition of a third
"primary callback" 
>> advise, you would implement your callback as a
primary callback and 
>> then use stopPropagation.
>>
>> In (b), if you called preventDefault from a BEFORE
callback, then that 
>> had better also prevent _any_ primary callbacks
from being called, not 
>> just the default one.
>>
> That is fair.
> 
> preventDefault in a BEFORE advisement should prevent
both subsequent 
> advisements being triggered as well as preventing the
default action.
> preventDefault in the EVENT advisement will only
prevent the default 
> action.

Would preventDefault in the EVENT advisement (nice name, by
the way)
prevent other EVENT callbacks (i.e., would it act like
stopPropagation?)

With the behavior of preventDefault in the BEFORE
advisement, I vote for
a name-change to preventEvent or something like that.



> 
> stopPropagation should only prevent further propagation
of the current 
> advisement.
> 
> That does leave an opening for a new mechanism for
EVENT handlers to 
> prevent the AFTER advisement.  I think it would be
sufficient to add a 
> parameter to preventDefault  to indicate whether or not
to  trigger an 
> AFTER advise.   That would be like saying either:
> - I have handle the default action, there are results
which should be 
> made available via the AFTER advise.
> - I have cancelled the action.  Nothing happened, ergo
there is nothing 
> to be after, so don't issue an AFTER advise.
> 
> For the purposes of simplicity and clarity it may be
better to make 
> three functions
> 
> preventDefault - cancel default action and EVENT
advise.  Includes one 
> parameter to control issue of AFTER advise (defaults to
true).
> stopPropagation - stop further propagation of this
advise.  Other advise 
> are not affected.
> cancelEvent -  stop propagation, do not issue any
further advise,  do 
> not carry out the default action (when issued in BEFORE
or EVENT advises).

So, to clarify what you're saying, calling:

  - preventDefault in BEFORE, with the adviseAfter parameter
true, will
continue processing BEFORE callbacks and then immediately
skip to
processing AFTER callbacks.
  - preventDefault in BEFORE, with adviseAfter parameter
false, will
continue processing BEFORE callbacks and then exit the event
handling.
  - preventDefault in EVENT, with adviseAfter parameter
true, will
continue processing EVENT callbacks, skip the default
action, and then
start processing the AFTER callbacks.
  - preventDefault in EVENT, with adviseAfter parameter
false, will
continue processing EVENT callbacks, skip the default
action, and then
exit the event handling.
  - preventDefaultin AFTER callbacks does nothing.
  - stopPropagation, called in any advisement, will skip
straight to the
next advisement.  That means if it is called in EVENT, then
we skip the
rest of the EVENT callbacks _and_ the default action and
skip straight
to AFTER callbacks.
  - cancelEvent immediately exits the event handling (after
the current
callback finishes, of course).

Is that correct?

I don't like that the preventDefault action means something
different if
it's called in BEFORE vs. EVENT.  I'll think about that
one.

Another issue: suppose a BEFORE event calls preventDefault. 
Then
another BEFORE event sets the preventDefault variable back
to false
(yes, I know you shouldn't mess with the variables, but it's
still
possible).  Should the default action be called?  I suppose
the
preventDefault value is only checked once, right before
calling the
default action, so the answer would be yes.  Should we do
something to
enforce plugins not tampering with the preventDefault
variables, or just
leave it as an understanding?


Thanks,

Jason

-- 
DokuWiki mailing list - more info at
http://wi
ki.splitbrain.org/wiki:mailinglist