[
https://issues.apache.org/jira/browse/LABS-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654678#action_12654678
]
Simone Gianni commented on LABS-192:
------------------------------------
A common case where having them separated makes things more complex than they
should be is when a do-method should delegate to other do-methods OR
handle-methods.
For example, I could have a doLoginBox method, that reads as follows :
public HtmlProducer doLoginBox() {
if (sessionUser == null) {
return handleLoginForm().do_default();
} else {
return doHelloUser();
}
}
The do_default() call is used to resolve the login form (supposing it is a
SmartForm, so a handler) to an HtmlProducer.
Having SmartForm be an HtmlProducer itself (as any other handler), would
simplify this code, and could even bring to :
public HtmlProducer doLoginBox() {
if (sessionUser == null) {
return new SmartForm(new LoginRequest(), ...);
} else {
return doHelloUser();
}
}
Anyway this second solution, while legal, would bring to a blur between
do-methods and handle-methods, making one of the two useless.
While this is not bad at all, still some kind of problems arise, cause handlers
will generate URLs to them (why use handlers otherwise?), and these urls will
be resolved re-calling the do method and "hoping" it will return the same
handler again. From a certain POV, this is nothing new : right now it is
already possible to place an "if" in a handle method, causing the same problem,
and anyway such problems will arise in every web application and a web
developer is aware of how it works.
Another problem could be the tendency of the developer to declare all methods
returning a HtmlProducer, making it impossible to use calls from outside (like
in Templates or in links using cglib), or introducing dangerous casts. So the
rule of thumb should be "declare the method as returning the highest possible
class in the hierarchy", which is far beyond the complexity we would like to
achieve. Right now, instead, the rules are "declare a do-method returning a
Producer, declare a handle-method returning the kind of handler it is going to
return", which makes it far simpler, but requires spurious handle methods here
and there.
Another common use case is the opposite of the one before : a method that
usually returns a certain handler, but occasionally should return something
else, like a page saying that you are not allowed to see this part of the site.
In this case, no hierarchy will ever help, cause we need the method to return
the handler class and still return from inside the method a producer.
This case is only resolvable with a specific exception, containing a producer,
thrown inside the method instead of returning the expected handler, but while
this exception can easily be caught during the programmatic resolve of a URI,
it cannot be resolved easily during external calls from a Template. In fact,
even placing an aspect to capture it, it will fail because the JVM will check
for proper casts. This mean that, to properly handle this situation and give
all this flexibility, all calls from outside (not from a do or handle method)
must be mocked with cglib and then executed in an environment able to catch the
exception and act properly. This is not a problem cause calls for links would
have been handled this way anyway, and calls for templates should be handled
this way for performance reasons (for the ifNeeded and byDefault).
> WEB: Merge handler and producers in a single hierarchy
> ------------------------------------------------------
>
> Key: LABS-192
> URL: https://issues.apache.org/jira/browse/LABS-192
> Project: Labs
> Issue Type: Improvement
> Components: Magma
> Affects Versions: Current
> Reporter: Simone Gianni
> Assignee: Simone Gianni
> Fix For: Future
>
>
> Having them separated makes a lot of stuff complex, and duplicates a lot of
> code since both have very similar parameters (like the creating handler, the
> base and complete path etc..).
> The system could consider the handler a kind of producer which is further
> resolvable to obtain yet another producer, until the resulting producer is
> not resolvable anymore.
> So, the common interface could contain a single method "resolve", which will
> ultimately return a non resolvable producer, either the same producer that
> has been called or null if the request is not resolvable.
--
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]
