An overused word it may be, but it has a fairly concrete meaning in
Tapestry. It feels like its getting a tad warm, so please allay any
fires brewing. I'm no expert in T5 either, but the notion of object
persistence is /not at all/ intrinsic to what services are. A service
may provide a mechanism for such persistence (like tapestry-hibernate),
but services exist for a generic reason - to provide functionality to
your application.
What parts? Pages, components, domain objects, other services, etc etc.
tapestry-hibernate provides a direct service implementation for object
persistence. Components or pages may use this directly, or you may have
an ORM abstraction layer in your app. They are simply about functionality.
The persistence I think you are talking about is application state -
tying an object to a certain user (session). Such objects are your ASOs,
but they are not themselves services. They are managed by a service
(ApplicationStateManager). An ASO would be something like a User object
that holds data you would expect (user name, real name, etc). It's a
domain object, not a service. The object used to authenticate the user
(and thus provide that object) might be a service.
Of course services are sometimes scoped per-thread, meaning that each
request (and therefore each requesting client) gets a copy instantiated
just for it. I guess its feasible that you could tie such a service to a
specific request as an ASO, but again this isn't what services do.
Pardon my rambling, but the real issue just became clear. In theory
(yes, theory), application state is just that: state. State is data, not
behavior. Services encapsulate behavior. Sure, there may be pragmatic
reasons for blurring the lines, but that is the conceptual difference
and is worth noting (even if sometimes violated for the sake of pragmatism).
sincerely, and hopefully not confusingly,
chris
Peter Stavrinides wrote:
As far as I'm concerned service is an ugly word everyone likes to
throw around, what you are really dealing with is the concept of
persistence with Pojo's using Inversion of Control.
Peter Stavrinides wrote:
A concept problem? really?? now I am curious as to what this concept
problem actually, is could you explain it.
Peter
MavenMan wrote:
Peter Stavrinides wrote:
Hi Chris
ApplicationStateManager is a service , I also think a service and
an aso are completely different thing.
in a word, It is a concept problem.
are completely different
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
