Hi Anthony,
Ive gone through your spec and dropped in comments and comparisons to
our system....
AK> At the programmers' discretion, wizards will enforce referrer identity and
AK> will not allow users to bookmark pages within wizards, reload pages, or
AK> proceed from one page another, willy-nilly.
Our cf_wizard tag doesn't cover this sort of thing, as we've
restricted it to dealing with only it's own functionality - the
referential integrity is a good thing, although we implement that
within the fusebox itself.
However one of the features of our wizards is taht they're not
step-aware - they don't have to know which step follows which etc,
allowing you to set up navigation between steps as you like, using
normal fusebox methods. There's an adaption I've added which allows
you to make wizards step-aware from the config file, and it lets you
specify conditions belonging to each individual step, which must be
met in order to allow the user to reach that step. If a step has a
condition attached to it, it gets evaluated, and if the result is
false the user is moved on to the next or previous step, depending on
the direction through the steps they were originally taking.
AK> Wizards are stored in subdirectories called "wiz" with subdirectories named
AK> after the function they are used to perform (ie.
AK> <siteroot>\wiz\addnewcompany\). The first page in a wizard is always
AK> "start.cfm" (ie. <siteroot>\wiz\addnewcompany\start.cfm).
We do something similar to this - not the /wiz/ bit, although that's
purely personal choice. A lot of our wizards are kicked of from a
content management portal, so they all get the fuseaction "start". In
a wizard without stepAwareness we have a line translating that to the
relevant first fuseaction, and ina step aware wizard the wizard tag
automatically does the translation to the first step in the set.
AK> Login, is a wizard that may include logic for first-time logins.
got one like this - I usually call it using cf_returnfuseaction
AK> Persistence: will be provided by custom tables, or more easily, by using
AK> session variables and the session fail-over mechanism. For instance,
AK> "session.addnewcompanywizard" will store state for the add new company
AK> wizard.
currently the wizard system stored each wizards satets in session
blocks, referencing them by a wizard_id. There's another optional
component to the wizards that has them store states in wddx,
translating it between steps. A further optional component allows
easy saving of states in the middle of a wizard - Ie if the user is in
the middle of filling out a very long wizard full of forms, the state
can be saved and re-accessed later on. Of course this isn't purely
wizard functionality, so the tag allows a save action, with pluinable
code to handle the saving itself - you can have the wizard output a
structure or a wddx packet and write whatever code you like to store
it - then later on use thatas the input to the wizard. (this is still
be mucked about with to make it perfectly customizable)
AK> Sequencing: will be maintained by custom programming in the page or
AK> form-processing controller. The traditional "workflow-step" handling
AK> mechanism will be avoided as overkill (ie. workflowID=xyz&step=2).
yup - in it's purest form, with none of the optional extra bits the
wizard tag simply manages states for you. You determine paths and
execution from within the fusebox, as per normal. This is great as
you can even wrap it around an existing application and just convert
your vars to reference the output scope. Oh, I forgot to mention that
it picks up attributes scoped vars from page to page and adds them to
the output scope as well, so yo8ur form variables etc will
automatically be put into the output scope. you can a pass the wizard
tag an ignorelist to keep certain things out of the output scope (by
default it ignores things like fuseaction, cfid,cftoken and anything
in the fusebox skiplist, plus anything in the ignorelist that you give
it.)
AK> Integrity: when it is absolutely necessary for pages to not be called out of
AK> sequence (ie. it will be damaging for them to be called out of sequence --
AK> for instance, bookmarking the confirm_and_delete_users handler page), a
AK> single-use token will be created to verify that the page is not being called
AK> twice (reload) and that is being called by an internal portal page, or even
AK> a specific portal page. If the token is invalid (it has been presented
AK> before or it was created externally), the <CF_xxxReferrerValidate> custom
AK> tag will relocate the user to the "start.cfm" page in the current
AK> subdirectory unless another redirectURL is provided. A valid token will be
AK> appended on this request. "Start.cfm", definitionally, can be called by
AK> anyone.
this only really matters for us when we're using step aware wizards
generally, and when we are, the step-aware code can deteremine the
direction of the user, either forward or back, page refresh, or jump
(which is going directly to a step, ie from wizard navigation etc)
AK> In addition to these three concern, XXXX has suggested that security may be
AK> an issue in any admin form. In the abstract, a form in a certain state is a
AK> "method" of a certain object type -- for instance, "add" user (type "user")
AK> or "edit" config (type "config"). Thus, we will permit binding forms to
AK> type methods and will permit enforcement of method permissions.
again, we let the fusebox methods handle security, although where
necessary this can be built into the conditions attached to variuos
steps when using step-aware wizards. Another thing to bear in mind is
that the user actually navigating the wizard will never see any of the
steps for whom the conditions are not met.
AK> Custom Tags
AK> CF_xxxReferrerTokenCreate
AK> Syntax <CF_xxxReferrerTokenCreate
AK> datasource=""
AK> r_token="" >
AK> Usage Creates a token used by the next page, for verifying the referrer
AK> identity.
Custom tags and includes are used as per normal - the cf_wizard tag
doesn't affect normal application execution at all. And we try not to
rely on referers as any server side relocations that occur can bugger
them up (speaking of which there is, among the accompanying wizard
util tags that we use with cf_wizard, a cf_wLocation which facilitates
server side redirects within the wizard, should they be necessary -
otherwise states can be interrupted and output variables set during
page execution would be lost.
AK> Database Tables
AK> t_referrer_tokens
AK> This table stores object templates.
AK> Field Usage
AK> referrer_token stores a referrer UUID token
AK> crtd_date date/time created
AK> referrer_port 443
AK> referrer_host_name www.xyz.com
AK> referrer_script_name /secured/wiz/addnewcompany/test.cfm
AK> referrer_query_string name=haha
cf_wizard doesn't have any relation to database logic at all - the
only time it know anything about a database is when using wddx stored
stated in the client scope, which is transparent anyways.
We went through specs much like this one to determine what we needed
when I built the tags, and have hammered them out pretty hard over the
last 6 months. The real driving focus was to give the requisite
functionality while restricting it to the necessary functions, and not
adding overhead or restrictions on the coders. The unix mentality of
"small tools for small jobs" holds true here, and it's worked very
well. The optional components are just that, optional, and can be
turned on or off in a config file if required - even without any of
them the default wizard functionality works beautifully
hope that helps...
Toby
------------------------------------------------------------------------------------
Life is Poetry, write it in your own words
------------------------------------------------------------------------------------
Toby Tremayne
Senior Technical Consultant
Code Poet and Zen Master of the Heavy Sleep
Lyricist Software
www.lyricist.com.au
m: +61 416 048 090
icq: 13107913
______________________________________________________________________
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
