On Nov 14, 2007 7:23 AM, richard.hensley [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Howard M. Lewis Ship
Partner and Senior Architect at Feature50
Creator Apache Tapestry and Apache HiveMind
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
