Someone correct me if I'm wrong, but you can't inject ComponentResources into a module because it doesn't yet exist. I believe ComponentResources is created when the rendering is actually underway, and modules are processed before this happens.

chris

Peter Stavrinides wrote:
My previous post contained this code:
@Inject
private ComponentResources resources_;

  public void contributeApplicationStateManager(
           MappedConfiguration<Class, ApplicationStateContribution>
configuration) {
       ApplicationStateCreator<BreadCrumbs> creator = new
ApplicationStateCreator<BreadCrumbs>() {
           public BreadCrumbs create() {
               return new BreadCrumbs(resources_);
           }
       };

       configuration.add(BreadCrumbs.class, new
ApplicationStateContribution(
               "session", creator));
   }

I had originally tried it like this, but couldn't figure out how to set service properties correctly, resources_ kept turning up null.

lasitha wrote:
Actually, it may be easier to contribute to the
ApplicationStateManager instead of having it injected and
getting/setting from it yourself.

See the section on 'Configuring ASOs' here:
http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html

Cheers, lasitha.

On 10/15/07, Peter Stavrinides <[EMAIL PROTECTED]> wrote:
Thanks Robert, I think I have my answer now.

Robert Zeigler wrote:
Use the ApplicationStateManager?

@Inject
ApplicationStateManager _manager;

MyObject foo = new MyObject(someArguments);
_manager.set(MyObject.class,foo);

Cheers,

Robert

On Oct 15, 2007, at 10/156:58 AM , Peter Stavrinides wrote:

Since you are confused by the question, let me rephrase it in a
different way then:

1. How do you register an ASO with the IoC managed container (or
registry if you prefer that word) if you have to provide arguments in
the constructor (i.e. you cannot use @ApplicationState in this case).



MavenMan wrote:
I just to say maybe the concept problem is you are dealing with is the
concept of persistence with Pojo's using Inversion of Control , so
you are mixed-up. many folk have
talk about the good of ioc .Now could you give me a explain of how
t5 manage the service and aso?
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]




---------------------------------------------------------------------
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]

Reply via email to