You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tiles.apache.org by mck <mc...@apache.org> on 2011/12/10 00:19:57 UTC
rename "util" packages (and remove package tangles)
Can we remove/rename util packages...
I'd be more comfortable seeing the Util classes treated as peer classes
residing in the packages where are primarily used (and ofc then be
package-protected if possible).
I think this comes under a general good practice where package tangles
in project are a lot easier to avoid if packages are named based off
functionality rather than on type. (Functionality is grouped but types
exist throughout).
So i'm wondering if there isn't objection if it's a good opportunity now
to do it, starting with tiles-request-api.
For example in tiles-request-api if we move everything in the util
package back to the request package, and also ContextResolver up to the
request package we completely untangle that submodule.
~mck
--
"The only thing I know, is that I know nothing." Socrates
| http://tech.finn.no | http://github.com/finn-no |
Re: rename "util" packages (and remove package tangles)
Posted by mck <mc...@apache.org>.
On Wed, 2011-12-14 at 17:38 +0100, mck wrote:
> But I'm entirely sure of it yet.
But I'm *not* entirely sure of it yet.
--
"Laugh, share some happiness with the world. God knows we all have
problems, believe that sometimes it pays to act like a fool to make
someone else happy!" Anon
| http://tech.finn.no | http://github.com/finn-no |
Re: rename "util" packages (and remove package tangles)
Posted by mck <mc...@apache.org>.
On Tue, 2011-12-13 at 19:29 -0500, Nicolas LE BAS wrote:
> It just means you have to either implement getContext(scope) for every
> view request
So far this sounds good to me. But I'm entirely sure of it yet. Let me
do the refactor first and then we can take a look from there... ok?
~mck
--
"Living on Earth is expensive, but it does include a free trip around
the sun every year." Unknown
| http://tech.finn.no | http://github.com/finn-no |
Re: rename "util" packages (and remove package tangles)
Posted by Nicolas LE BAS <ma...@nlebas.net>.
On 11-12-13 04:18 PM, mck wrote:
>
> For example in AbstractClientRequest you're thinking of replacing
>
> ContextResolver resolver = ApplicationAccess.getContextResolver(applicationContext);
> return resolver.getContext(this, scope);
>
> with what?
I could do it if you want, but the idea is:
- for AbstractClientRequest (i.e. ServletRequest and PortletRequest)
there is no wrapping, so:
* getContext(scope) just maps the methods getRequestScope(),
getSessionScope() and getApplicationScope(). This can be implemented
just as easily by hand.
* getAvailableScopes() simply returns getNativeScopes()!
- for RequestWrapper (i.e. JspRequest, VelocityRequest, FreemarkerRequest):
* getContext(scope) calls the ReflexionContextResolver to map the
method getPageScope() and the methods of the wrapped request. This can
be implemented as:
if("page".equals(scope)) return getPageScope();
else return super.getContext(scope);
* getAvailableScopes() concatenates getNativeScopes() with the
getAvailableScopes() of the wrapped request.
It just means you have to either implement getContext(scope) for every
view request, or declare an abstract method getPageScope() in an
abstract class somewhere (perhaps AbstractViewRequest).
Of course this is true only for ReflexionContextResolver, and we could
arguably create a different implementation. But I think the current
behaviour and set of scopes are so widely used that they're unlikely to
change at any time. Eventually more scopes might appear for new request
implementations (if we're interfacing with Seam or Webflow for
instance). But between subclassing and wrapping, I believe we have
enough flexibility to add as many scopes as we want.
Discussing it makes me realize that, without ContextResolver, we might
even be able to remove getNativeScopes(). Applications would want to
call getAvailableScopes() anyway.
>> Perhaps we should also take the opportunity to expand the
>> package-level javadoc.
>
> Absolutely, but i think you have a better grasp here and can come up
> with a far better overview description. I can help flesh out the class
> docs then.
OK, I'll do that sometime this week hopefully :)
Nick
Re: rename "util" packages (and remove package tangles)
Posted by mck <mc...@apache.org>.
> * RequestUtil goes into o.a.t.r.collection
Yes, and i'll rename it to something more relevant... (eg
CollectionUtil)
> * ContextResolver was useful with Tiles 2, but I'm not sure it serves a
> purpose anymore. The Request abstraction (with its wrapping mechanisms)
> is just more powerful. Perhaps we can remove it entirely.
You need to enlighten me some more here.
For example in AbstractClientRequest you're thinking of replacing
ContextResolver resolver = ApplicationAccess.getContextResolver(applicationContext);
return resolver.getContext(this, scope);
with what?
Or did you want to remove Request's getContext(scope) and
getAvailableScopes(..) methods altogether?
> Perhaps we should also take the opportunity to expand the
> package-level javadoc.
Absolutely, but i think you have a better grasp here and can come up
with a far better overview description. I can help flesh out the class
docs then.
~mck
--
“Innovators and creative geniuses cannot be reared in schools. They are
precisely the men who defy what the school has taught them.” - Ludwig
von Mises
| http://tech.finn.no | http://github.com/finn-no |
Re: rename "util" packages (and remove package tangles)
Posted by Nicolas LE BAS <ma...@nlebas.net>.
On 11-12-09 06:19 PM, mck wrote:
> Can we remove/rename util packages...
+1
I'm no fan of "util" classes and static methods either.
> For example in tiles-request-api if we move everything in the util
> package back to the request package, and also ContextResolver up to the
> request package we completely untangle that submodule.
I'd be a little more specific in 3 cases:
* RequestUtil goes into o.a.t.r.collection
* ContextResolver was useful with Tiles 2, but I'm not sure it serves a
purpose anymore. The Request abstraction (with its wrapping mechanisms)
is just more powerful. Perhaps we can remove it entirely.
* if we remove the ContextResolver, very little remains in
ApplicationAccess: only the registration of the ApplicationContext
object within itself (which is awkward, especially since it is used only
by servlets) and a constant that can be moved to the interface
ApplicationContext (or perhaps even to o.a.t.r.servlet.ServletUtil: it
is used only for ServletContexts).
* I like the idea of moving the rest to the top package.
Perhaps we should also take the opportunity to expand the package-level
javadoc.
Nick
Re: rename "util" packages (and remove package tangles)
Posted by Greg Reddin <gr...@gmail.com>.
+1. I like the idea of API cleanup, which it seems like this does.
Greg
On Fri, Dec 9, 2011 at 5:19 PM, mck <mc...@apache.org> wrote:
> Can we remove/rename util packages...
>
> I'd be more comfortable seeing the Util classes treated as peer classes
> residing in the packages where are primarily used (and ofc then be
> package-protected if possible).
>
> I think this comes under a general good practice where package tangles
> in project are a lot easier to avoid if packages are named based off
> functionality rather than on type. (Functionality is grouped but types
> exist throughout).
>
> So i'm wondering if there isn't objection if it's a good opportunity now
> to do it, starting with tiles-request-api.
>
> For example in tiles-request-api if we move everything in the util
> package back to the request package, and also ContextResolver up to the
> request package we completely untangle that submodule.
>
> ~mck
>
>
> --
> "The only thing I know, is that I know nothing." Socrates
>
> | http://tech.finn.no | http://github.com/finn-no |
>
>
>