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 <a> element with the provided link as the href
attribute. A call to
* [EMAIL PROTECTED] org.apache.tapestry.MarkupWriter#end()} is <em>not</em>
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]
