click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian A." <a.adrian.t...@gmail.com>
Subject Re: Issues or no issue...
Date Tue, 15 Jun 2010 12:17:37 GMT
> I think Control#onDeploy should be deprecated as it
> has some major drawbacks:
>
>   - Control has to be instantiated during startup in order to invoke onDeploy. At startup
time there
> is no request, and thus no Context object. The net effect of this is that the Control
cannot rely on
> Context in it's constructor. Accessing Context in the Control constructor is useful because
one can
> pull data from the Session to retrieve state.
>   - changes to the resources have to be updated in two places, once for getHeadElements
and again for
> onDeploy
IMHO onDeploy should not be deprecated, as it's a smart approach for the 
components to be "aware" and
handle their own resources in a pretty "independent manner": not many 
other frameworks have this feature - even worse for most other: the user 
has to take manually care of the resources.

For development mode, or "very dynamic" applications, it's very nice 
that the Component can take care of itself :)

Of course, maybe onDeploy + getHeadElements could be further improved to 
reduce code duplication, or maybe there's a better approach, but IMHO 
onDeploy is just a too nice feature of Click to deprecate it.

Adrian.


Mime
View raw message