[T5] Tapestry-IOC Features and Readiness

["richard.hensley" <Ri...@McKesson.com>]

I'm a long time hivemind user. I'm looking to get rid of XML configuration,
so I'm considering transitioning to tapestry-ioc. I have a few questions.

1. Is it ready for production use?

I've found the following features missing.

 - Pooled service model
 - Explicit primitive, however I think that module build* method's
eliminates the need
 - Multiple configuration injections into a service

2. Fortunately, I don't need these features. However are there any other
differences?
 
I'm currently working on a proof of concept using tapestry-ioc.

Richard
-- 
View this message in context: http://www.nabble.com/-T5--Tapestry-IOC-Features-and-Readiness-tf4805832.html#a13748830
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [T5] Tapestry-IOC Features and Readiness

[Thiago H de Paula Figueiredo <th...@gmail.com>]

Talking about Tapestry-IoC (that I love :), I would like to

1) Ask Howard to take a look at  
https://issues.apache.org/jira/browse/TAPESTRY-1874.

2) Ask Howard about setter-based injection, at least for objects that for  
some reason or another need to be created outside T-IoC. Spring supports  
it, Tapestry-IoC and Guice don't. There must be a good reason, I just  
don't know it. :)

Thanks in advance. :)

-- 
Thiago H. de Paula Figueiredo
Desenvolvedor, Instrutor e Consultor de Tecnologia
Eteg Tecnologia da Informação Ltda.
http://www.eteg.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [T5] Tapestry-IOC Features and Readiness

[Howard Lewis Ship <hl...@gmail.com>]

On Nov 14, 2007 7:23 AM, richard.hensley <Ri...@mckesson.com> wrote:
>
> I'm a long time hivemind user. I'm looking to get rid of XML configuration,
> so I'm considering transitioning to tapestry-ioc. I have a few questions.
>
> 1. Is it ready for production use?
>
> I've found the following features missing.
>
>  - Pooled service model

Just the new minimalism; is the pooled service model that useful?  It
isn't included because it isn't known whether it is actually used.

>  - Explicit primitive, however I think that module build* method's
> eliminates the need
>  - Multiple configuration injections into a service

This was one of the great simplifications: to make configurations
owned by services. In the rare places where a service needs two
configurations, I've been splitting into into two services. That's
actually made things easier to test and may represent an improved
seperation of concerns.

>
> 2. Fortunately, I don't need these features.

See!

> However are there any other
> differences?

Service proxy serialization is on the to-do list.  And I do remember
who first requested it for HiveMind!

You have may more options, for things that are service-like but not
services. 5.0.7. In 5.0.6 you can use ObjectLocator.autobuild() to
build an object (and let the container handle the dependencies).  In
5.0.7 you can use ObjectLocator.proxy() to create a just-in-time proxy
that is autobuilt.

Exception reporting is improved.  Case insensitivity is great.
Startup speed is improved over HiveMind by a lot. I've been working on
a a kind of dashboard service to give you insight into which services
are instantiated and, eventually, which methods are being invoked.

T5 IoC makes the whole IoC thing a joy (*) because for the normal case
(services interfaces a unique/specific to a single service) there's
just no configuration beyond ServiceBinder.bind(), things just snap
together automatically. With HiveMind is was always "now I have to go
write the XML for this service"  and even I always had to go check the
docs for the right syntax, but with T5 IoC, I just define a
constructor and it's usually done.  With ambiguous services, it may be
a little more help ... a contribution to Alias to provide
disambiguation or (more likely) adding a marker annotation to the
service and the point of injection.

(*) Right up until you are making contributions into certain critical
service configurations such as TypeCoercer or MasterObjectProvider.
That can still be challenging since those services are needed for many
kinds of automatic service location, so you have to be careful about
any injections into the contributer methods.

>
> I'm currently working on a proof of concept using tapestry-ioc.
>
> Richard

And here I thought you'd abandoned us for Ruby on Rails!

> --
> View this message in context: http://www.nabble.com/-T5--Tapestry-IOC-Features-and-Readiness-tf4805832.html#a13748830
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



-- 
Howard M. Lewis Ship
Partner and Senior Architect at Feature50

Creator Apache Tapestry and Apache HiveMind

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org