NAME
Hub::Webapp::Client -
Part of the Hub Library
SYNOPSIS
DESCRIPTION
METHODS
| clean | getclientcookie | mkurl | save | upload |
| clear | has | new | set | |
| endreq | load | newreq | setrelay | |
| get | logreq | restorereq | take |
- clean
-
Usage: cleanClear everything but in-use data
- clear
-
Usage: clearClear all session data
- endreq
-
Usage: endreqEnds the request (saves session to disk)
- get
-
Usage: get KEYDirectly get by key
-
Usage: getclientcookiePrint the client key as a cookie
- has
-
Usage: has KEYReturn 1 if the specified element is defined, 0 if not.
- load
-
Usage: loadLoad a session file. Note that this *takes over* the current request. Most notably, this loaded file is resaved when endreq() is called.
- logreq
-
Usage: logreqLog request state information
- mkurl
-
Usage: mkurl CGIPARAMS, [OPTIONS] Usage: mkurl OPTIONS Usage: mkurlCreate url with current context information. Parameters encountered first take prescedence.
Where, CGIPARAMS can be:
SCALAR "name=George;_action=assisinate;time=yesterday" HASHREF { name => "George", _action => "assasinate", time => "yesterday", } ARRAYREF [ "name="George", "_action="assasinate", "time="yesterday", ]And, OPTIONS can be:
--noparams No parameters --referrer Create a link to the referring page --lastreq Link to the last request (even if it's the same handler)
- new
-
Usage: new Usage: new CLIENTDIRConstructor.
- newreq
-
Usage: newreq Usage: newreq CGI->new() Usage: newreq "_display=login&s_username=ryan" Usage: newreq "_display=login", "s_username=ryan"Come to life
- restorereq
-
Usage: restorereq LEVELRestore a request from the history.
Where LEVEL can be:
0 Current request (no operation performed) 1 Last request 2 The one before the last 3 The one before that 4 The one before that max No-op, you cannot go back farther than: REQHISTORYSIZE - 1
- save
-
Usage: saveWrite to disk
- set
-
Usage: set KEY, DATADirectly set by key
- setrelay
-
Usage: setrelay( "login" ); Usage: setrelay( "login", "username=ryan&password=" ); Usage: setrelay( "login", "username=ryan", "password=" );Set relay (next handler and parameters) data
- take
-
Usage: take KEYDirectly get by key, then delete it
- upload
-
Usage: uploadUpload multi-part form data
INTERNAL
| AUTOLOAD | _mkcgiinst | _refresh | _setreqkey |
| DESTROY | _mkfilename | _setclientkey | _validate |
| _init | _parsecgi | _setmeta |
- AUTOLOAD
-
Usage: AUTOLOADAutoload get/set/take/has calls and translate them into correct instance method calls.
The method name is translated as:
$class->aaabbb( ... ) aaa Is the method part, and can be: get|set|take|has bbb Is the root identifier part. I can be anything, but these special ones are re-routed: current|signal|baseIf the aaa part is not one of the four, an error is logged.
If the bbb part is not of the two special ones, then it is considerred to be the id of the root hash whithin which we will handle data.
A bbb part of 'current' sets the bbb part to the current handler.
A bbb part of 'signal' is the same as 'current' in display context, but if we are inside an action request, 'signal' is re-routed to the action hash (where the action signals are stored.)
Given that were invoked by a request of:
.=p001;..=index;_id=42;name=joe Then Becomes Returns getsignal( "id" ) get->( "p001:id" ) 42 setcurrent( "id", 1002 ) set->( "p001:id", 43 )and subsequently invoked with a request of:
.=p001;..=index;_action=print;_id=1001;name=jimmy Then Becomes Returns getsignal( "id" ) get->( "ACTION:id" ) 1001 setcurrent( "id", 1002 ) set->( "p001:id", 1002 ) getcurrent( "name" ) get->( "p001:name" ) joe getsignal( "name" ) get->( "ACTION:name" ) jimmy getaction( "name" ) get->( "ACTION:name" ) jimmyAnd for any other bbb part:
This Becomes getfoo( "id" ) get->( "FOO:id" ) setFoo( "id", 1004 ) error! set_Foo( "id", 1004 ) error! set_foo( "id", 1004 ) error! setfoo( "user:name", "joe" ) set->( "FOO:user:name", "joe" ) hasjunk( "mail" ) has->( "JUNK:mail" ) takeunk( "mail" ) has->( "JUNK:mail" )SUBREQUESTS
A bbb part of 'base' sets the bbb part to the base handler hash. This is use to share data in subrequests. Here are three requests, where the second two are subrequests:
1) .=p001;_view=ltr 2) .=p001:summary;_sort=date 3) .=p001:summary:print;_orientation=landscapeIn the third request, the following happens:
getbase( "view" ) ltr getsignal( "orientation" ) landscape getsignal( "sort" ) getmeta( "handler" ) p001:summary:print getmeta( "baseid" ) p001 getmeta( "reqid1" ) summary getmeta( "reqid2" ) printNOTE: The data hash for the above is:
%p001{ sort == 1 %summary{ %print{ orientation == landscape } sort == date } view == ltr }The subrequest 'summary' is stored under the base request 'p001', which means that you would cause problems where you to:
.=p001;_summary=on -or- setbase( "summary", "on" )as you would be overwriting the nested data.
- DESTROY
-
Hub::lmsg( "EVAL: $eval" );
- _parsecgi
-
Usage: _parsecgiPopulate ourselves with new data recieved through the CGI. Also handle system (.) parameters.
- _setclientkey
-
Usage: _setclientkey1) Use the client key specified in a cookie 2) Or, use the .clientkey CGI parameter 3) Or, generate a new key
AUTHOR
Ryan Gies
COPYRIGHT
Copyright (c) 2006 Livesite Networks, LLC. All rights reserved.
Copyright (c) 2000-2005 Ryan Gies. All rights reserved.
UPDATED
This file created by on at