Re: [T5] Re-inject or inherit services in children ?
Howard Lewis Ship wrote: [..] I kind of think that if you can't find a true purpose for the base class beyond a convienient place for the common injections, then perhaps you are on the wrong track. Well, now that you explain me that, I think it's my problem. I almost only use the base page/component as a container for common services/logic. But as you said, it should be better suited to create new services than a base page for that, and only use them where they are needed. I kind of like the list of injections in my components ... it's kind of like a cast of characters in a play. And I completely agree with that. In each component, I use a really visible comment to hilight the injected services : just with that, I can (almost) know what the component is going to do, or at least what may be its side effects. So, it's a really good reason to inject services every time they are really need. Ok, so I should build more unit services, make some facade for logically linked services... Well, just really use the power of Tapestry services ;) Thank you really much for the advices, and I believe I'm going to remove this needless base page :) -- Francois Armand Etudes & Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [T5] Re-inject or inherit services in children ?
I've found that, quite often, there's a little bit of processing
around the injected service method invocation, so that's where the
base page can really add some value: collect and pre-processing the
values before invoking the method.
For example, I was just working on PageLink and ActionLink and
refactoring out an AbstractLink:
public abstract class AbstractLink
{
@Inject
private ComponentInvocationMap _componentInvocationMap;
/**
* An anchor value to append to the generated URL (the hash
separator will be added automatically).
*/
@Parameter(defaultPrefix = LITERAL_BINDING_PREFIX)
private String _anchor;
@Inject
private ComponentResources _resources;
private final String buildHref(Link link)
{
String href = link.toURI();
if (_anchor == null) return href;
return href + "#" + _anchor;
}
/**
* Writes an element with the provided link as the href
attribute. A call to
* [EMAIL PROTECTED] org.apache.tapestry.MarkupWriter#end()} is not
provided.Automatically appends
* an anchor if the component's anchor parameter is non-null.
Informal parameters are rendered as well.
*
* @param writer to write markup to
* @param clientId value written as the id attribute
* @param link the link that will form the href
* @param namesAndValues additional attributes to write
*/
protected void writeLink(MarkupWriter writer, String clientId,
Link link, Object... namesAndValues)
{
Element e = writer.element("a", "href", buildHref(link), "id",
clientId);
writer.attributes(namesAndValues);
_resources.renderInformalParameters(writer);
_componentInvocationMap.store(e, link);
}
/**
* Used for testing.
*/
void inject(String anchor, ComponentInvocationMap map,
ComponentResources resources)
{
_anchor = anchor;
_componentInvocationMap = map;
_resources = resources;
}
}
This approach simplified PageLink andActionLink and totally hid the
ugly ComponentInvocationMap (that is, we didn't have to re-inject it
into subclasses, or provide a protected getter method).
I kind of think that if you can't find a true purpose for the base
class beyond a convienient place for the common injections, then
perhaps you are on the wrong track. I kind of like the list of
injections in my components ... it's kind of like a cast of characters
in a play.
Another option is to create a facade service that wraps around the
many services your application needs, so that just a single facade,
rather than many individual services, can be injected. Again, this is
an alternative to a base class.
On Dec 6, 2007 12:47 AM, Francois Armand <[EMAIL PROTECTED]> wrote:
> Hello !
>
> My project is a little more advanced, so I spent some time refactoring
> the code. Along this refactoring, I saw that I have a lot if component
> and class that inherit a base page (yes, that's why I have a base page ;).
> I inject on this page some quite common services (for example, an
> authorization service).
>
> So, what is the best pattern, in regard of Tapestry 5, for a page or
> component that extends my page base : inject (again) the services, or
> get it from the parent (what suppose that these services have matching
> getter in the base page).
>
> I believe injection is cheap, but a base page is here to provide common
> services, so I'm prone to choose the inherit pattern.
> What do you think about it ?
>
> --
> Francois Armand
> Etudes & Développements J2EE
> Groupe Linagora - http://www.linagora.com
> Tél.: +33 (0)1 58 18 68 28
> ---
> InterLDAP - http://interldap.org
> FederID - http://www.federid.org/
> Open Source identities management and federation
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Creator Apache Tapestry and Apache HiveMind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[T5] Re-inject or inherit services in children ?
Hello ! My project is a little more advanced, so I spent some time refactoring the code. Along this refactoring, I saw that I have a lot if component and class that inherit a base page (yes, that's why I have a base page ;). I inject on this page some quite common services (for example, an authorization service). So, what is the best pattern, in regard of Tapestry 5, for a page or component that extends my page base : inject (again) the services, or get it from the parent (what suppose that these services have matching getter in the base page). I believe injection is cheap, but a base page is here to provide common services, so I'm prone to choose the inherit pattern. What do you think about it ? -- Francois Armand Etudes & Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
