[ewiki] Re: auth plugins: new page access (was Re: Re: auth_ perm_unix: new pages access)

I'm going ot respond to some points below, but I also want to propose an
alternative.  Take a cue from the $data['forced_version'] implementation
that we use already, can we set $data['no_content'], $data['create'], or
even just set $data['version']=0 in ewiki_page().  I would suggest using
these as follows:

* $data['no_content'] - indicates that no data is in the database for
this page.  Plugins may check for this value to determine whether the
absence of a $data['content'] indicates that the page does not have any
content data rather than that it was simply not passed.
* $data['create'] - indicates that the page did not previously exist and
that the current edit will be creating it.  Set only for pages which do
not exist and will not be handled by a page plugin, should be unset by
handlers as appropriate.
* $data['version']=0 - set as above and creates no extra fields. 
Plugins may check with a === to discern non-existant pages.

Of these I think  $data['version']=0 makes the most sense and can
provide all the benefits of a create action without most of the
downsides.  If it seems good to you lets investigate that path instead
of create.

-Andy

On Thu, 2004-03-11 at 15:06, Mario Salzer wrote:
> > As for modifying the _auth call, please explain how you would do this to
> > avoid stumbling over the fact that you may or may not be getting data in
> > $data.  
> 
> The problem is obviously only for all the funny look-ahead _auth()
> calls. My simple answer to this was, that one just must accept that
> you cannot 100% accurately tell about page accessibility until you 
> try to access it (with the full and latest $data loaded).

That is not acceptable to my company.  Whether in the core or my own
deployment of ewiki I have to hide the titles of inaccessible pages. 

> And the "edit"/"create" switching most only would occour for ewiki_auth()
> lookahead calls, that actually were called with the second parameter
> being "edit". This only happens at one place as far as I know (the
> control-line), and we have the full $data available for that case.

Some of the binary pages need a similar function.   edit_append manage
plugins are another example.

> > The main benefits from adding a create action IMOWRCH are exactly from
> > polluting the global scope with it.  Some possible uses:
> >
> > * Making your aedit_template plugin appear and run only on page creation.
> > * Allowing my "edit_append" manage plugins (in perm_liveuser) to give the
> > original author extra abilities to setup the rights for a page when they
> > create a page.
> > * Allowing a different editor to be used for creation i.e. choice of upload
> > a file, copy a page, start fresh, create a forum...
> > * Flagging page creation in the logs.
> > * You may want... search as described below.
> 
> Making the if_page_already_exists() check once and renaming the global
> $action var obviously had a lot of advantages, but there are of course
> cons too:
> - it was simply more complex then
> - there then always needed to be a double-check where currently =="edit"
>   is tested
>   (- page plugins may get confused, because they always were to be
>      "create"d even if they actually handled some data "edit"ing
>      internally; what again changed with ghost/cache pages)
> - more unintuitive and unreliable to not have automatic page creation
automatic page creation would still exist, ewiki_page() would detect
edits and convert them to create where appropriate.

> - code duplication, and "create" plugins eventually harmful to existing
>   pages (there then had to be a very strong check against page existence)
I suppose it could lead to code duplication in the future, but initially
I would just call the edit plugins with $action="edit"

> - a new "create" action should then be visible to the outside
>   (?id=create/NewPage), but appears to not give any benefits(?)
It could be used to allow people to create pages without tossing them
into editing an existing page.  This seems useless except that the
addpost plugins would be able to use it so as to not create posts that
already exist by failing at a later check.(not sure that counts as
useful, seems dumb even as I say it :-)  

> - duplication of CSS selectors:
>      .wiki.edit.ThisPage, .wiki.create.ThisPage { ... }
>   (though this may be an advantage, if users really cared about "edit"
>   vs "create" actions)

Ouch, that does put a damper on it.  Though some may actually prefer
this.

> So I'm very undecided about introduction of a "create" action, and
> it still looks unnecessary to me to introduce a purely internal action
> name here (except for the _auth stuff). Meanwhile we could however use
> a handler/page_init plugin to check the implications (for later hardwiring
> of a "create" action).

It's something like a state or subaction, but I don't think we want to
create a global or pass something else around for this either.

Other related posts: