It may help when reading the HiveDocs for Infrastructure (
http://tapestry.apache.org/tapestry4/tapestry/hivedocs/config/tapestry.I
nfrastructure.html ) that the following two getters provide the same
functionality:
@InjectObject("service:tapestry.globals.WebRequest")
public abstract WebRequest getRequest();
@InjectObject("infrastructure:request")
public abstract WebRequest getRequest();
And also looking at it from the opposite side:
http://tapestry.apache.org/tapestry4/tapestry/hivedocs/module/tapestry.g
lobals.html
I have yet to have time to really wrap my brain around HiveMind, but my
interpretation is that tapestry.Infrastructure, being a configuration
point, is a set of configuration properties that, in this case, Tapestry
is using (hehe, me smart). This is a higher level than
tapestry.globals.WebRequest, which is a specific service provider. i.e.
"infrastructure:request" should probably be the preferred method; not
only for less typing, but also because it's a higher-level view:
Tapestry could later swap out its configuration with another
service-provider without affecting our applications ... basically the
benefit of coding-to-interfaces.
Jim
-----Original Message-----
From: Epstein, Ezra [mailto:[EMAIL PROTECTED]
Sent: Friday, July 14, 2006 1:35 PM
To: Tapestry users
Subject: RE: Inject and the infrastructure namespace
Yes, but the static (.xml) config'd part of it could be inspected
dynamically. 'course when used via inject where the parameter (e.g.,
class name) is provided dynamically it's a meaningless concept, but for
most of the things that hivemind has built-in it's not: they're static.
Guess I'm still figuring out how to even read HiveDoc... Since that
seems to be how the info are (statically) available.
Thanks,
Ezra Epstein
-----Original Message-----
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Friday, July 14, 2006 10:30 AM
To: 'Tapestry users'
Subject: RE: Inject and the infrastructure namespace
Service providers don't have "contents." Take the "instance" provider,
for example. It can provide an object of any class which has a public
no-argument constructor. Or, consider the "class" provider. It can
provide any java.lang.Class object given a class name. So, there's no
real way for it to be able to tell you "here are all of the objects that
I can provide."
-----Original Message-----
From: Epstein, Ezra [mailto:[EMAIL PROTECTED]
Sent: Friday, July 14, 2006 1:21 PM
To: Tapestry users
Subject: RE: Inject and the infrastructure namespace
http://tapestry.apache.org/tapestry4/tapestry/apidocs/org/apache/tapestr
y/se
rvices/Infrastructure.html
But clearly the converse is not true: there are properties available via
the
infrastructure: prefix that are not in the interface. The WebContext
(infrastructure:context) is an example that comes to mind.
Isn't it odd that one can't inspect the service providers for their
contents? String interpretation can still be idiosyncratic and the s.ps
could still have a way to expose what they've parsed. I'm surprised if
HiveMind lacks this feature common to most IoC containers.
Thanks,
Ezra Epstein
-----Original Message-----
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 5:28 PM
To: 'Tapestry users'
Subject: RE: Inject and the infrastructure namespace
Take a look at the Infrastructure interface. Any property from the
interface is available via the infrastructure: prefix.
-----Original Message-----
From: Epstein, Ezra [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 7:07 PM
To: Tapestry users
Subject: Inject and the infrastructure namespace
This:
@InjectObject("infrastructure:context")
works fine. And of course there's the 'request' available from
infrastructure. Can someone kindly point me to the docs that list all
the possible values that may be placed after the "infrastructure:"
tag/namespace for a default tapestry+portlet deployment?
Thanks,
Ezra Epstein
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
