SessionVariablesAPI

The lib/uservars_pages plugin allows you to store user data as we had disscussed here.

There are two levels to the SessionVariablesAPI, light and full. The Light interface is intended for non-management uses i.e. plugins that do not need to search or edit other user's data. Both are implemented by plugins in the plugins/lib directory.

Light API

$ewiki_plugins['uservars_retrieve'] should be called through by auth plugins after they have set $ewiki_auth_user. $ewiki_plugins['uservars_store'] should be called by plugins after they have changed values.

Full API (extends the Light API)

$ewiki_plugins['uservars_store']($data=NULL, $username=NULL)
Saves $data as data for user of name $username or ewiki_auth_user if NULL. See light API if both are NULL.
$ewiki_plugins['uservars_retrieve']($username=NULL)
Returns the user data for user of name $username or $ewiki_auth_user if NULL.
function ewiki_get_uservar($varname, $defaultValue=NULL, $username=NULL)
returns value of user variable $varname or $defaultValue if it is not set.
function ewiki_set_uservar($varname, $value, $username=NULL)
set value of user variable $varname returns true on success
function ewiki_getall_uservar($username=NULL)
returns all uservariables for a user as an array.
function ewiki_clear_uservar($varname, $username=NULL)
unsets value of user variable $varname returns true on success
function ewiki_search_uservar($varname, $value=NULL)
returns array of $username => $value for users that have user variable $varname set (and equal to $value if $value is set)

$username is optional in all calls defaulting to the current $ewiki_auth_user. The uservars_pages implementation stores these variables on specially named pages, it is not efficient (especially on searches) but it should prove a good starting point. I have some simple interfaces to release and I should have some plugins based on these calls soon.

I've added or would like to add to these:

  • For login features:
    • $ewiki_plugins["Page"]["Login"]
    • $ewiki_plugins["Page"]["Logout"] - for system login/logout pages where available.

milky: I vote against this!! It is obviously wrong. You should use $ewiki_plugins["page"]["LogIn"] and LogOut respectively - looks more wiki-aware ;-)

Andy:Lets compromise--and do it my way :-) Seriously, I'll change it the names in my draft and.... done. Actually having them as WikiWords will be useful.

  • For session and user variables in cases like the new e-mail protect method and instead of using cookies directly. Cookie based implementations would be included in ewiki.php.
    • $ewiki_plugins["get_var"] - ewiki_getvar($a_variable; $a_defvalue=FALSE)
    • $ewiki_plugins["set_var"] - ewiki_setvar($a_variable; $a_value; $a_vartype=*EWIKI_VARTYPE_SESSION; $a_user='') falls back to a session variable when called for *EWIKI_VARTYPE_USER is called without user variables available.
  • I want to add these so that I can build off my SecurePlugin account functions for things like an *AnnouncementPlugin or a *PersonalHistoryPlugin without coupling them to my user system.

milky: the session variables thingi (?) seems senseful to me, and I'm currently working at the same problem for the ewiki PostProject; but I'm right now rather unsure, if it needs to be accessible by all ewiki plugins. It is probably easier to have a unique function name which then is called by all plugins that are aware of the session environment. Otherwise one had to write if($pf=$ewiki_plugins("get_var")){$pf(...);} or so all the time. Personally I favour to leave it to the yoursite.php wrapper around ewiki to be aware of all this, and to utilize a dedicated function call or $_SESSION or $_CONFIG array to store and retrieve variables, which could be automatically saved on PHP shutdown().

Andy: I finally got this, you mean like $GLOBALS["ewiki_author"] right? The problem with that is that I don't think the wrapper should know all about every plugin that you have loaded. I think your solution of grabbing a couple of global variables and making them arrays covers that perhaps. Anything you can say about what the PostProject entails?

milky: While the wrapper should not know about all plugins, the opposite counts too: All the plugins should not know about the wrapper :) - I didn't meant to create dozens of global variables which yoursite.phps` session handling code needed to be aware of, but just one (or two) arrays ($_EWIKI) to contain many state variables, like $_EWIKI["history"], $_EWIKI["_is_logged_in"], $_EWIKI["total_hits"], and so on...

The mystic PostProject has still very negative version numbers assigned, but I'll post the session code as soon as it is ready. That project btw is nothing more than another (much more) bloated example-N script.

milky: But this is actually worth an more detailed and ongoing discussion, but I'm still against introducing too much auth and user handling code into the core script. We should rather develop a stupid-proof and simple plugin extension which cares about all this.

Andy: I definately don't want the checks for the existance of the plugin, in fact, that's exactly why I want it in the core. What I was hoping to do was something like the render plugin where a simple implementation is included in the core and all plugins can call it or replace it as they might need to. Perhaps a separate plugin and include_once() or require_once() would serve all the same needs if that seems better to you.

milky: You're right, function_exists() or if(isset()) is no solution, but introducing two empty function bodies is not one percent less evil. There wouldn't be any problem if ewiki was object-oriented, but you know there is the 'library' subtitle above it. What I'd like to tell is that, ewiki is more like gtk, while coWiki for example looks like Gnome, and we should not try to produce virtual functions (beside the ewiki_auth() and ewiki_database(), which actually are) when we actually do not use objects and encapsulation. However for a 'library' there's another way around the problem: global variables. This is a good thing, because not only function names belong to the API, but also and more important the variables (and their structure).

Andy: I hadn't meant for them to be empty, just simple and cookie based. Unfortunately my best experience is object oriented so I don't have the same sense of outrage with regard to empty functions. The getter/setter function stems from the same line of thought of course.

milky: I don't like cookies (because of the way they are utilized nowadays). Many sites utilize PHP's session() stuff, which resets an PHPSESSID with every page retrieval, which I personally find very annoying. Also a cookie validity of 'until 2038' often suggests to visit another site soon. And I'd rather like the Mozilla coders would have added a way to deny endlessly valid cookies immediately (instead of the current default 90 days restriciton).

But whatever, back to ewiki: if your ewiki_set_var() function contained nothing more but a call to PHPs` setcookie() - why don't you just use that one?! The question is, if such a function would be hardcoded into the core - what could it wrap around? The only advantage about a global state variable storage array ($_CONFIG, $_USER, $_EWIKI) was, that the "Set-Cookie:" header would be emitted immediately by PHP.

Have you an example of what such a set_var() call would do, and an idea what a $ewiki_plugins[] replacement could do instead?

Andy: Sure, although cookies can substitute for session variables and can store data on a particular machine nearly indefinately they cannot truly be associated with a user. The *AnnouncementPlugin provides an example of this. Consider that the announcement plugin prefaces the first page a user visits with an announcement page if that announcement is newer than the last one they viewed. With long-term cookies the user would see this announcement at each computer they visit from. If the wiki they visit has instead replaced *_var with functions that actually understand users the same function would now display the announcement only once. Having a replaceable functions allows the *AnnoucementPlugin, the authentication plugin, and the wrapper to be mutually unaware. A variable array does or nearly does the same.

milky: So we probably won't need a function call, but a standard name for the array to contain and intershare the session variables. So not $ewiki_plugins["set_var"] but an $ewiki_plugins["vars"] is required. However the plugins array (while keeping variable usage low) is a bad place to store them (some wrong usage decisions in the last versions), so we should decide on a better global variable name. I'm currently using $_CONFIG and $_USER, but I'd rather like somthing like $_EWIKI or $_EWIKI_SESSION_VARS or whatever... The name is not all that important, but we should concentrate on not more than two or three of them. This way it would be easy to add and fetch variables without requirement on any function (no error triggering, no checking), while it would be rather easy for your user and session handling code to merge that state/session variables into say $_SESSION for automated storage (by PHP).

Andy: I think you're onto something. If I stay awake long enough I'll write up a plan for RemappingVariables. Not that I think we should jump everything to a new style but I want to see where things would go if they did move. I kind of jumped at the plugin function to match the existing style of plugin functions.

milky: I also like the require_once() idea, but that call needed to go into just the plugins that would use the session variable functions. Right now there is no plugin which could use it - you probably intended it for the more advanced and interactive plugins; but this will only be a very few I guess. So no need to worry too much about the standard. And let me suggest it again, the global concentration variable would become part of the ewiki API like a function did, while providing an easier and cleaner interface.

Andy: The E-mail plugin is using cookies already and I'd like to apply whatever we do in this regard to that. The plugins that I forsee using this are:

  • email_protect - to show its message only once
  • phplib_auth - internal use.
  • edit_savesize - I have a request that the effect of the + on the edit screen be maintained between visits. I would use this mechanism to meet that request.
  • view_announce - to indicate the last announcement seen, I'll probably code this because I'm inviting my users to bookmark pages for their departments.
  • page_history - to store a list of the pages that a visitor has visited.

milky: I think the email_protect is worth its own cookie, as this allowed interoparibility with the http://nanoweb.si.kz/ implementation.

For edit_savesize there is no need for ewiki to set any cookie, because ewiki will never notive the resizement of the textarea. Instead you'll need to rewrite the JS to set a cookie client-side. But I recommend against it, as you will soon get requests to add an - link also then. (I'll already plan to add a constant to define the textarea size site-wide configurable, which could be changed from user-settings).

Andy: Yeah a + a - and a hidden field to store the current value.

milky: For the others you'll don't want a cookie function, but a session variable storage, what an array like $_SESSION or $_USER, $_CONFIG, $_EWIKI would well suit, I believe.

Andy: Well, I sure don't want a cookie function but one would make those plugins functional for those with no other choice.

milky: Let's vote for a nice an short global $_VARNAME (or two)!

Andy: It's 11:30pm now, I'll vote after I sleep... whenever that may be.

Andy: Still haven't slept (9:30am) but here's the other thing we need to think about, how do we specify the three to five different retention policies? (constant, variable, session var, machine var, user var). I've started laying out the problem on RemappingVariables, but I didn't get far.

EditThisPage BackLinks PageInfo Pages like this RSS/Atom last changed on Fri Oct 16 03:08:20 2009
bottom corner