Chris,
FYI services do not primarily exist to provide functionality to an
application, Java code has all the mechanisms to do that. Services
provide the decoupling and abstraction desirable to prevent dependency
failures. The "service" aspect is the contract to reuse code. Services
are conducive to "interoperability", so they are usually for enterprise
environments, but we IT people love buzzwords don't we? on that note:
>a true POJO has a public non-arguments constructor
Howard I get what you are saying, but what you are talking about is a
bean, which has a no arg constructor.
All Java objects are POJO's... POJO's have only three "theoretical"
restrictions:
1. They shouldn't extend prespecified classes
2. They shouldn't Implement prespecified interfaces
3. They shouldn't contain prespecified annotations
Is it fair to say ASO's were treated as services by the container in T4?
...ASO's need to be serializable, this wasn't a big deal though in T4, I
used transient objects where needed, worked great, plain Java code!
Peter
Howard Lewis Ship wrote:
I have some expertise in Tapestry, and I side with Chris.
An ASO is a global object that is associated with a particular user,
typically via the user's HttpSession. It doesn't have a service interface,
as it is typically a POJO. Because it doesn't have an interface, Tapesty
doesn't create a proxy for the ASO.
In most cases, the ASO is a true POJO (a true POJO has a public
non-arguments constructor) in which case Tapestry can manage the ASO
entirely, creating it as necessary. To be honest, since the ASO code was
written, Tapestry has gotten smarter, and could probably operate on a more
complicated constructor using the normal autobuild approach. This would
allow injection of services into an ASO ... which is dangerous, because
service proxies are not serializable, and an ASO typically must be.
You can also explicitly define the ASO, which gives you an opportunity to
provide the code to instantiate the ASO. This is what you currently do if
your ASO doesn't have a simple constructor.
If you need to access an ASO from a component, you use the @ApplicationState
annotation, which marks a field as being linked to an ASO.
If a service needs access to an ASO, it must inject the ApplicationState, it
must obtain the ASO from the ApplicationStateManager.
http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry/services/ApplicationStateManager.html
On 10/15/07, Peter Stavrinides <[EMAIL PROTECTED]> wrote:
Hi Chris
I am no expert on T5, but strongly disagree with you.
Peter
Chris Lewis wrote:
Hi Peter
1) I think the general opinion on this is that a service and an aso
are completely different animals. I can't think of a situation where
I'd ever want an aso to be a service (or vice versa), but that's just
me. If there is a way to do this, someone else will need to chime in.
2) @Inject it. Assuming you bound or built your service, you can
simply inject it using @Inject as the general type (usually an
interface) of object, and Tapestry IoC will resolve it for you.
sincerely,
chris
Peter Stavrinides wrote:
Hi all,
Following on from a previous post on this subject I have some
questions on Tapestry 5 IoC:
1. How do you register an ASO as a service if you have to provide
arguments to the constructor (i.e. you cannot use @ApplicationState
in this case).
2. How do you retrieve a service object that has been contributed to
the framework
Thanks
Peter
---------------------------------------------------------------------
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]
