From: "Ovidiu Predescu" <[EMAIL PROTECTED]>
> On Monday, Dec 9, 2002, at 05:21 US/Pacific, Konstantin Piroumian wrote:
>
> > In case of the flow script you should place login() function call in
> > every
> > function that needs authorized access, while for the state machine
> > approach
> > you could create a superstate - AuthorizedState - for all the
> > sub-states
> > that needs authenticated user.
>
> Not really. You can automate this task by arranging in your sitemap to
> call a function that checks the login first, instead of your function.
> The following will do it:
>
> Sitemap:
>
> <map:match pattern="someUri/checkout">
> <map:call function="checkLogin">
> <map:parameter name="funarg" value="checkout"/>
> </map:call>
> </map:match>
Yes, this should work. But I'd prefer to avoid passing the function name as
parameter. What about this version:
<map:match pattern="someUri/*">
<map:call function="checkLogin">
<map:parameter name="funarg" value="{1}"/>
</map:call>
</map:match>
Or an alternate version with nested matchers:
<map:match pattern="private/**">
<map:call function="checkLogin">
<map:parameter name="funarg" value="checkout"/>
</map:call>
<map:match pattern="checkout">
<map:call function="checkout">
</map:match>
<map:match pattern="checkin">
<map:call function="checkin">
</map:match>
</map:match>
etc.
Will the above work as I expect? (Each 'private/**' request is checked for
authorization and then the processing continues with one of the nested
matchers). This one looks like the state machine approach with nested
states.
>
> Flow:
>
> var user;
>
> function login()
> {
> // send the necessary pages for the user
> // to login. Assigns to the global 'user' variable
> // the User object, which is later used throughout
> // the script to identify the user. See the prefs.js
> // sample in Cocoon for an example of such a function.
> }
>
> function checkLogin(funarg)
> {
> if (user == null)
> login();
> funarg();
> }
>
> The sitemap calls checkLogin() and passes as argument the function to
> be called when the user has already logged in. The login() function
> will ask the user to login, and will return only when the user
> successfully does so. At that moment the original function to be
> invoked is called.
>
> > In the project I'd been working, we'd been generating our state machine
> > descriptions directly from a UML modeling tool (it was XMI format),
> > then it
> > were processed by an XSLT to our (simpler) format. (The source code
> > was not
> > related to Cocoon neither it was open source, unfortunately)
>
> Having to use a tool is exactly what I'm trying to avoid. I'm finding
> myself in the constant situation of running on an unsupported platform
> for most of such tools. Writing simple scripts beats any time a verbose
> XML document.
Yes that's true for most of the cases. But in the situation when you are
required to create UML diagrams for all the system, it's much easier to
generate XML from them and even actions and selectors sceletons. When there
is a bunch of developers of different expertise level, this approach works
just fine: most of the developers should not be aware of the sitemap,
JavaScript or so, they just have to implement the actions that interact with
the business logic layer.
But again, that depends on your tasks, on your team. For the XMLForm wizards
scenario I'd prefer a state-machine approach, for something else, probably,
I'd choose the flow-script.
Regards,
Konstantin
>
> Best regards,
> --
> Ovidiu Predescu <[EMAIL PROTECTED]>
> http://webweavertech.com/ovidiu/weblog/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
