[
https://issues.apache.org/jira/browse/LABS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Gianni updated LABS-240:
-------------------------------
Issue Type: New Feature (was: Bug)
> [web] Provide before and after handlers
> ---------------------------------------
>
> Key: LABS-240
> URL: https://issues.apache.org/jira/browse/LABS-240
> Project: Labs
> Issue Type: New Feature
> Components: Magma
> Affects Versions: Current
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: Current
>
>
> In a number of situation a WebHandler may want to perform some actions before
> any call to a do or handle method. While this is achievable with aspects,
> aspect method patterns knowledge is not require for the role of web
> programmer, so a simpler method should be provided.
> A good way could be to use an already existing "standard", for example using
> @Before and @After annotations similar to those provided by Junit 4 or even
> predefined names like setup and tearDown like it was in Junit 3 and how it is
> in the startup package.
> A good use case is, for example, when a certain value could be passed via
> different environment methods. For example, a user preference which could be
> present as a cookie or as a session parameter, giving precedence to one of
> them, for example to cookies. In that case, every doMethod who wants to use
> that user preference will end up checking if one of the two has been passed,
> and using the most appropiate one. This could be done in a setup method, as
> if it was an aspect.
> Also, there are actions that need to be done before or after every request,
> or every request in a certain zone of the site.
> A good use case for this is the automatic user login. A login handler could
> use cookies to mark a user, and then automatically log in when he comes back
> to the site. Anyway, this should be done before any processing of the site is
> done, cause having or not having a user could change the behaviour of a
> number of site elements (like, display or not a login box, or a messages box
> and so on).
> For this situation, adding setup methods to the RootWebHandler will mean
> "call me every request". Nesting the setup method in another handler will
> limit the scope.
> Using setup/teardown methods could bring a number of problems :
> - Performances : for the automatic login system, we need many data passed to
> the handler, for example sessionUser, cookieUser and the like. We don't need
> to pass the cookies if the user is already logged in for example, or even if
> a session is already present (we need to check only the first request that
> arrives). In more complicated situations ths could be a huge performance
> impact.
> - Conflicts : anyone wanting to do something before every request will create
> a setup method in the RootWebHandler, and if they need environment
> informations (like sessionUser) they will try to add the setter. This can
> easily lead to conflicts.
> Also there are some limitations, for example the user may expect to be able
> to do something in the setup method, like redirecting to a login page, or
> displaying an error page telling something as a result of parameters
> evaluation.
> While we don't want to provide something with all the features of an aspect
> (using which all this stuff is already possible), it could help to have the
> setup method return an HtmlProducer. If it return null, nothing happens, if
> it returns something, that something is returned instead of the doMethod that
> was originally being called.
> This solution can also help mitigate the performance problem. Infact an
> "AutomaticLoginHandler" could handle all the automatic login stuff in it's
> doCheckForLogin method, environmental getters and setters would be placed
> only in that handler. That do would return null by default, since there is no
> need to do anything if the user cannot be automatically logged in. In the
> rootWebHandler only a setup method calling that do method if no session user
> is present is needed, avoiding the binding of all cookies if not necessary.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
