You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2007/11/09 19:09:04 UTC
Feedback wanted on IoC documentation
I've been working on new documentation about Tapestry IoC (similar
stuff will be coming for Tapestry core):
Overview:
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
Cookbook:
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
Feedback is encouraged!
--
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
Re: Feedback wanted on IoC documentation
Posted by Peter Stavrinides <p....@albourne.com>.
A very commendable effort Howard! I believe this type of documentation
will go a long way towards a more usable and marketable framework.
A minor comment from an editorial perspective regarding the cookbook
section, perhaps the naming is misleading: 'cookbook' represents
recepies so you might expect some concise yet complete examples with
very limited explanatory notes geared towards producing the result.
Perhaps you should change this naming convention, or simply combine the
two sections.
Peter
Howard Lewis Ship wrote:
> I've been working on new documentation about Tapestry IoC (similar
> stuff will be coming for Tapestry core):
>
> Overview:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>
> Cookbook:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>
> Feedback is encouraged!
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Feedback wanted on IoC documentation
Posted by Jiri Mares <Ji...@svt.cz>.
Hi,
the documentation is really getting better, more understandable. But I would like to print it and read offline (from
paper), is there any way how to show all documentation as one HTML page or PDF to print it easily?
Jirka
Howard Lewis Ship napsal(a):
> I've been working on new documentation about Tapestry IoC (similar
> stuff will be coming for Tapestry core):
>
> Overview:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>
> Cookbook:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>
> Feedback is encouraged!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Feedback wanted on IoC documentation
Posted by "robert.sanders" <ro...@ipov.net>.
Overall: Very good, if this stuff gets a little more fleshed out it will
be a huge help in getting started with T5. I would suggest that on the
last example in the overview (MonitorModule) you add a tiny bit of text
explaining that the contribute method is part of Tapestry IoC's
configuration conventions - after I read though the rest of the cookbook
this made sense.
Howard Lewis Ship wrote:
> I've been working on new documentation about Tapestry IoC (similar
> stuff will be coming for Tapestry core):
>
> Overview:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>
> Cookbook:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>
> Feedback is encouraged!
>
>
--
Robert r. Sanders
Chief Technologist
iPOV
(334) 821-5412
www.ipov.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Feedback wanted on IoC documentation
Posted by Massimo Lusetti <ml...@gmail.com>.
On Nov 9, 2007 7:09 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Feedback is encouraged!
I've already said this kind of works are invaluable expecially when
are written side by side with concrete examples as the ones taken from
tapestry-core.
In this regards the only this i would say is the fact that i would
show some more examples external to the tapestry world. Some sort of
hello world services examples.
Anyway i've already used this doc to show some benefits to my
collegues and it has roven to be good.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Feedback wanted on IoC documentation
Posted by Martin Strand <do...@gmail.com>.
Thanks for taking the time to explain. I haven't looked closely into T5,
maybe constructor injection is impossible. I just don't understand why it
would be insufficient in this case. Or is it just that you prefer
annotated fields?
Your example:
> Constructor injection is insufficient for components, because Tapestry
> needs to really know about the individual fields. For example, if
> you:
>
> @Inject
> private MyService _service;
>
> ... and then in some code:
>
> void onActionFromNotAGoodIdea()
> {
> _service = new MyOtherImpl();
> }
>
> You'll actually get a runtime error explaining that the field is read
> only.
But with constructor injection the fields could be final instead and that
code wouldn't even compile!
Perhaps it would be possible if only services could be injected this way?
Martin
On Sun, 11 Nov 2007 00:29:50 +0100, Howard Lewis Ship <hl...@gmail.com>
wrote:
> Services are loaded by the normal class loader without any special
> trickery. We create classes (proxies and such), but don't modify
> existing classes for Tapestry IoC. This is necessary to ensure that
> services code inter-operates properly with all kinds of third party,
> legacy and other code that is far, far beyond the scope of Tapestry
> IoC.
>
> To encourage service implementations to properly store service
> depenencies as final instance variables, such dependencies are passed
> only into the constructor.
>
> So for services, injection is assumed, for the constructor parameters
> (as if an @Inject annotation was present).
>
> Now for components, it's a different story. The component classes are
> very specific to Tapestry, not intended for reuse elsewhere, and are
> modified at runtime to work properly and efficiently within the
> constraints of Tapestry's multi-threaded runtime environment.
>
> Tapestry components are quite a bit different from service, in terms
> of lifecycle, and in terms of the what can be injected (all sorts of
> resources besides services) and in the fact that they quite often have
> considerable (if largely temporary)
> internal state, while services most often have no internal state at all.
>
> Constructor injection is insufficient for components, because Tapestry
> needs to really know about the individual fields. For example, if
> you:
>
> @Inject
> private MyService _service;
>
> ... and then in some code:
>
> void onActionFromNotAGoodIdea()
> {
> _service = new MyOtherImpl();
> }
>
> You'll actually get a runtime error explaining that the field is read
> only.
>
> So field injection is both necessary and requires far less typing ...
> you don't have to write a constructor and assigning all the fields
> from it. On the other hand, the fields aren't final (though they often
> act final).
>
> The real downside is that you have a similar concept, injection, with
> two very different expressions.
>
> It would be interesting if Tapestry IoC could support injection on
> fields, and "backtrack" from the field to the constructor parameter.
> It might also be interesting if components could define a constructor
> and Tapestry could work forwards from the parameter annotations
> forwards to the fields. I think both approaches would require a large
> amount of effort and may not actually add any value.
>
> Certainly in the short term, people would be much happier if we got
> the Ajax support going.
>
> Of course, I'm writing this on my PC while I get Leopard installed
> onto my Mac (my main development machine).
>
> On Nov 10, 2007 12:43 PM, Michael Courcy <mi...@gmail.com>
> wrote:
>> Hi
>>
>> Thanks again for this effort of documentation.
>>
>> I have a question about dependency injection between services.
>>
>> We can inject a service thanks to the @Inject annotation in a page
>> component.
>> I find this feature pretty handy.
>>
>> But (correct me if I'm wrong but I think I'm not because I test it) we
>> can't @Inject a service in a sercice.
>> Instead we must provide the service to the other service through its
>> constructor.
>>
>> Why did you make this choice ?
>>
>> I would find useful as well to inject a service in a service with the
>> same annotation ?
>>
>> Michael
>>
>>
>> Howard Lewis Ship a écrit :
>> > I've been working on new documentation about Tapestry IoC (similar
>> > stuff will be coming for Tapestry core):
>> >
>> > Overview:
>> >
>> >
>> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>> >
>> > Cookbook:
>> >
>> >
>> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>> >
>> > Feedback is encouraged!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Feedback wanted on IoC documentation
Posted by Michael Courcy <mi...@gmail.com>.
Ok I think I have understood your explainations (actually I'm not pretty
sure)
The component is totally managed by tapestry and by injecting services
through @Inject annotation you get more control on its fields.
While in the other hand you encourage proper storage of service by
making injection only available through constructor.
Well, honestly I don't have enough experiences to assess that, it's
doing the job properly anyway, I was a bit curious that's all.
I agree on the fact that making those two ways dependencies injection
available in both context won't bring that much compare to the
expectation of the community : Ajax and the next tutorial on form ;-).
Thanks for your answer.
Michael
Howard Lewis Ship a écrit :
> Services are loaded by the normal class loader without any special
> trickery. We create classes (proxies and such), but don't modify
> existing classes for Tapestry IoC. This is necessary to ensure that
> services code inter-operates properly with all kinds of third party,
> legacy and other code that is far, far beyond the scope of Tapestry
> IoC.
>
> To encourage service implementations to properly store service
> depenencies as final instance variables, such dependencies are passed
> only into the constructor.
>
> So for services, injection is assumed, for the constructor parameters
> (as if an @Inject annotation was present).
>
> Now for components, it's a different story. The component classes are
> very specific to Tapestry, not intended for reuse elsewhere, and are
> modified at runtime to work properly and efficiently within the
> constraints of Tapestry's multi-threaded runtime environment.
>
> Tapestry components are quite a bit different from service, in terms
> of lifecycle, and in terms of the what can be injected (all sorts of
> resources besides services) and in the fact that they quite often have
> considerable (if largely temporary)
> internal state, while services most often have no internal state at all.
>
> Constructor injection is insufficient for components, because Tapestry
> needs to really know about the individual fields. For example, if
> you:
>
> @Inject
> private MyService _service;
>
> ... and then in some code:
>
> void onActionFromNotAGoodIdea()
> {
> _service = new MyOtherImpl();
> }
>
> You'll actually get a runtime error explaining that the field is read only.
>
> So field injection is both necessary and requires far less typing ...
> you don't have to write a constructor and assigning all the fields
> from it. On the other hand, the fields aren't final (though they often
> act final).
>
> The real downside is that you have a similar concept, injection, with
> two very different expressions.
>
> It would be interesting if Tapestry IoC could support injection on
> fields, and "backtrack" from the field to the constructor parameter.
> It might also be interesting if components could define a constructor
> and Tapestry could work forwards from the parameter annotations
> forwards to the fields. I think both approaches would require a large
> amount of effort and may not actually add any value.
>
> Certainly in the short term, people would be much happier if we got
> the Ajax support going.
>
> Of course, I'm writing this on my PC while I get Leopard installed
> onto my Mac (my main development machine).
>
> On Nov 10, 2007 12:43 PM, Michael Courcy <mi...@gmail.com> wrote:
>
>> Hi
>>
>> Thanks again for this effort of documentation.
>>
>> I have a question about dependency injection between services.
>>
>> We can inject a service thanks to the @Inject annotation in a page
>> component.
>> I find this feature pretty handy.
>>
>> But (correct me if I'm wrong but I think I'm not because I test it) we
>> can't @Inject a service in a sercice.
>> Instead we must provide the service to the other service through its
>> constructor.
>>
>> Why did you make this choice ?
>>
>> I would find useful as well to inject a service in a service with the
>> same annotation ?
>>
>> Michael
>>
>>
>> Howard Lewis Ship a écrit :
>>
>>> I've been working on new documentation about Tapestry IoC (similar
>>> stuff will be coming for Tapestry core):
>>>
>>> Overview:
>>>
>>> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>>>
>>> Cookbook:
>>>
>>> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>>>
>>> Feedback is encouraged!
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
>
>
Re: Feedback wanted on IoC documentation
Posted by Howard Lewis Ship <hl...@gmail.com>.
Services are loaded by the normal class loader without any special
trickery. We create classes (proxies and such), but don't modify
existing classes for Tapestry IoC. This is necessary to ensure that
services code inter-operates properly with all kinds of third party,
legacy and other code that is far, far beyond the scope of Tapestry
IoC.
To encourage service implementations to properly store service
depenencies as final instance variables, such dependencies are passed
only into the constructor.
So for services, injection is assumed, for the constructor parameters
(as if an @Inject annotation was present).
Now for components, it's a different story. The component classes are
very specific to Tapestry, not intended for reuse elsewhere, and are
modified at runtime to work properly and efficiently within the
constraints of Tapestry's multi-threaded runtime environment.
Tapestry components are quite a bit different from service, in terms
of lifecycle, and in terms of the what can be injected (all sorts of
resources besides services) and in the fact that they quite often have
considerable (if largely temporary)
internal state, while services most often have no internal state at all.
Constructor injection is insufficient for components, because Tapestry
needs to really know about the individual fields. For example, if
you:
@Inject
private MyService _service;
... and then in some code:
void onActionFromNotAGoodIdea()
{
_service = new MyOtherImpl();
}
You'll actually get a runtime error explaining that the field is read only.
So field injection is both necessary and requires far less typing ...
you don't have to write a constructor and assigning all the fields
from it. On the other hand, the fields aren't final (though they often
act final).
The real downside is that you have a similar concept, injection, with
two very different expressions.
It would be interesting if Tapestry IoC could support injection on
fields, and "backtrack" from the field to the constructor parameter.
It might also be interesting if components could define a constructor
and Tapestry could work forwards from the parameter annotations
forwards to the fields. I think both approaches would require a large
amount of effort and may not actually add any value.
Certainly in the short term, people would be much happier if we got
the Ajax support going.
Of course, I'm writing this on my PC while I get Leopard installed
onto my Mac (my main development machine).
On Nov 10, 2007 12:43 PM, Michael Courcy <mi...@gmail.com> wrote:
> Hi
>
> Thanks again for this effort of documentation.
>
> I have a question about dependency injection between services.
>
> We can inject a service thanks to the @Inject annotation in a page
> component.
> I find this feature pretty handy.
>
> But (correct me if I'm wrong but I think I'm not because I test it) we
> can't @Inject a service in a sercice.
> Instead we must provide the service to the other service through its
> constructor.
>
> Why did you make this choice ?
>
> I would find useful as well to inject a service in a service with the
> same annotation ?
>
> Michael
>
>
> Howard Lewis Ship a écrit :
> > I've been working on new documentation about Tapestry IoC (similar
> > stuff will be coming for Tapestry core):
> >
> > Overview:
> >
> > http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
> >
> > Cookbook:
> >
> > http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
> >
> > Feedback is encouraged!
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Feedback wanted on IoC documentation
Posted by Patrick Moore <pa...@amplafi.com>.
Hi Renat --
That's a good point that having the service model be the switching point is
probably better place to do the magic. It has a certain elegance of
simplicity and robustness. Haven't read the T5 documentation, so I am going
to presume (?) that anything I can do in hivemind today I can do with
Tapestry5 IoC tomorrow.
Still won't make the fields final as setters/getters will be needed to wire
objects manually for testing. But at least dynamic substitution of server
providers should be possible.
-Pat
On Nov 17, 2007 3:49 PM, Renat Zubairov <re...@gmail.com> wrote:
> Hello Patrick, All,
>
> Concerning use case of swapping services, it's actually happening already,
> and quite frequently, imagine singleton service instance with "threaded"
> services injected inside. So my point it that swapping of the services is
> already there, however it's happening not on the layer of fields in the
> service implementation but on the level of proxies (that's how it works in
> T4 (HM1.1) and I assume in T5).
> So singleton service has a reference to proxy, but proxy finds the
> implementation of the service dynamically based on the Thread where it is
> called.
> If we are talking about the usecase that in case system (JVM) is
> overloaded
> proxy may decide to forward the calls to the remote JVM in the cluster,
> and
> I guess this usecase is already implemented.
>
> Renat
>
> On 17/11/2007, Patrick Moore <pa...@amplafi.com> wrote:
> >
> > Hi --
> >
> > On Nov 17, 2007 8:41 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > > On Nov 16, 2007 10:39 PM, Patrick Moore <pa...@amplafi.com> wrote:
> > > > Hi Howard --
> > > > I disagree with philosophy of forcing people to have the services
> only
> > > > injected via constructors because:
> > > >
> > > > 1. it results in a monster constructors for some key services.
> > >
> > > I would say that those key services may be insufficiently factored
> > > into smaller cooperating services. Seperation of concerns!
> > >
> >
> > Actually just the opposite! We have facade-pattern services that
> present
> > a
> > unified interface point to the "outside" code. But under the hood the
> > facade
> > service delegates to the smaller services.
> >
> > Of course we use the facade pattern so that we can isolate changes to
> the
> > underlying services. But those facade-pattern services talk to many
> other
> > services.
> >
> >
> > > > 5. You are assuming that it is unconceivable for services once
> > wired
> > > > together to ever want to be rewired - and this is not the case.
> > >
> > > I see that as a whole can of worms. I strongly think that static
> > > structure / dynamic behavior extends into the services tier.
> > >
> >
> > Oh I understand that as well -- and its not something I suggest doing as
> a
> > normal course. The major uses I am thinking about are around swapping
> out
> > local services for a remote implementation of a service. Not your normal
> > use
> > case I grant you! And I am going to do everything I can to design an
> > alternative solution. But having to bring down the server in order to
> > reconfigure it, or to require programmatic changes to do reconfiguration
> > seems bad.
> >
> >
> > > >
> > > > But at the end of the day - why be dogmatic about this?
> > >
> > > Because I'm a very stubborn person?
> >
> >
> > Wouldn't know! But I complement your stubbornness wrt at least one
> thing
> > -- the tapestry error messages are far superior to many other
> > packages out
> > there, open-source or otherwise.
> >
> > >
> > >
> > > Points well taken. We could definitely do something like Guice and
> > > allow the Inject annotation on methods as well as method parameters,
> > > to indicate a method which represents a point of injection.
> > >
> >
> > Thanks for listening...
> >
> >
> > -Pat
> >
>
>
>
> --
> Best regards,
> Renat Zubairov
>
Re: Feedback wanted on IoC documentation
Posted by Renat Zubairov <re...@gmail.com>.
Hello Patrick, All,
Concerning use case of swapping services, it's actually happening already,
and quite frequently, imagine singleton service instance with "threaded"
services injected inside. So my point it that swapping of the services is
already there, however it's happening not on the layer of fields in the
service implementation but on the level of proxies (that's how it works in
T4 (HM1.1) and I assume in T5).
So singleton service has a reference to proxy, but proxy finds the
implementation of the service dynamically based on the Thread where it is
called.
If we are talking about the usecase that in case system (JVM) is overloaded
proxy may decide to forward the calls to the remote JVM in the cluster, and
I guess this usecase is already implemented.
Renat
On 17/11/2007, Patrick Moore <pa...@amplafi.com> wrote:
>
> Hi --
>
> On Nov 17, 2007 8:41 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> > On Nov 16, 2007 10:39 PM, Patrick Moore <pa...@amplafi.com> wrote:
> > > Hi Howard --
> > > I disagree with philosophy of forcing people to have the services only
> > > injected via constructors because:
> > >
> > > 1. it results in a monster constructors for some key services.
> >
> > I would say that those key services may be insufficiently factored
> > into smaller cooperating services. Seperation of concerns!
> >
>
> Actually just the opposite! We have facade-pattern services that present
> a
> unified interface point to the "outside" code. But under the hood the
> facade
> service delegates to the smaller services.
>
> Of course we use the facade pattern so that we can isolate changes to the
> underlying services. But those facade-pattern services talk to many other
> services.
>
>
> > > 5. You are assuming that it is unconceivable for services once
> wired
> > > together to ever want to be rewired - and this is not the case.
> >
> > I see that as a whole can of worms. I strongly think that static
> > structure / dynamic behavior extends into the services tier.
> >
>
> Oh I understand that as well -- and its not something I suggest doing as a
> normal course. The major uses I am thinking about are around swapping out
> local services for a remote implementation of a service. Not your normal
> use
> case I grant you! And I am going to do everything I can to design an
> alternative solution. But having to bring down the server in order to
> reconfigure it, or to require programmatic changes to do reconfiguration
> seems bad.
>
>
> > >
> > > But at the end of the day - why be dogmatic about this?
> >
> > Because I'm a very stubborn person?
>
>
> Wouldn't know! But I complement your stubbornness wrt at least one thing
> -- the tapestry error messages are far superior to many other
> packages out
> there, open-source or otherwise.
>
> >
> >
> > Points well taken. We could definitely do something like Guice and
> > allow the Inject annotation on methods as well as method parameters,
> > to indicate a method which represents a point of injection.
> >
>
> Thanks for listening...
>
>
> -Pat
>
--
Best regards,
Renat Zubairov
Re: Feedback wanted on IoC documentation
Posted by Patrick Moore <pa...@amplafi.com>.
Hi --
On Nov 17, 2007 8:41 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> On Nov 16, 2007 10:39 PM, Patrick Moore <pa...@amplafi.com> wrote:
> > Hi Howard --
> > I disagree with philosophy of forcing people to have the services only
> > injected via constructors because:
> >
> > 1. it results in a monster constructors for some key services.
>
> I would say that those key services may be insufficiently factored
> into smaller cooperating services. Seperation of concerns!
>
Actually just the opposite! We have facade-pattern services that present a
unified interface point to the "outside" code. But under the hood the facade
service delegates to the smaller services.
Of course we use the facade pattern so that we can isolate changes to the
underlying services. But those facade-pattern services talk to many other
services.
> > 5. You are assuming that it is unconceivable for services once wired
> > together to ever want to be rewired - and this is not the case.
>
> I see that as a whole can of worms. I strongly think that static
> structure / dynamic behavior extends into the services tier.
>
Oh I understand that as well -- and its not something I suggest doing as a
normal course. The major uses I am thinking about are around swapping out
local services for a remote implementation of a service. Not your normal use
case I grant you! And I am going to do everything I can to design an
alternative solution. But having to bring down the server in order to
reconfigure it, or to require programmatic changes to do reconfiguration
seems bad.
> >
> > But at the end of the day - why be dogmatic about this?
>
> Because I'm a very stubborn person?
Wouldn't know! But I complement your stubbornness wrt at least one thing
-- the tapestry error messages are far superior to many other packages out
there, open-source or otherwise.
>
>
> Points well taken. We could definitely do something like Guice and
> allow the Inject annotation on methods as well as method parameters,
> to indicate a method which represents a point of injection.
>
Thanks for listening...
-Pat
Re: Feedback wanted on IoC documentation
Posted by Howard Lewis Ship <hl...@gmail.com>.
That's what service builder methods are for. They're the shim for
services that don't have a proper constructor, or that have more
complicated initialization logic.
On Nov 19, 2007 4:16 AM, Thiago H de Paula Figueiredo
<th...@gmail.com> wrote:
> On Sat, 17 Nov 2007 14:41:16 -0200, Howard Lewis Ship <hl...@gmail.com>
> wrote:
>
> > On Nov 16, 2007 10:39 PM, Patrick Moore <pa...@amplafi.com> wrote:
> >> I disagree with philosophy of forcing people to have the services only
> >> injected via constructors because:
> >>
> >> 1. it results in a monster constructors for some key services.
> >
> > I would say that those key services may be insufficiently factored
> > into smaller cooperating services. Seperation of concerns!
>
> What about services you can't add constructors, like Hibernate sessions?
>
> --
> 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
>
>
--
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
Re: Feedback wanted on IoC documentation
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Sat, 17 Nov 2007 14:41:16 -0200, Howard Lewis Ship <hl...@gmail.com>
wrote:
> On Nov 16, 2007 10:39 PM, Patrick Moore <pa...@amplafi.com> wrote:
>> I disagree with philosophy of forcing people to have the services only
>> injected via constructors because:
>>
>> 1. it results in a monster constructors for some key services.
>
> I would say that those key services may be insufficiently factored
> into smaller cooperating services. Seperation of concerns!
What about services you can't add constructors, like Hibernate sessions?
--
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: Feedback wanted on IoC documentation
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Nov 16, 2007 10:39 PM, Patrick Moore <pa...@amplafi.com> wrote:
> Hi Howard --
>
> I appreciate the work you are doing on T5 and look forward to moving to it
> when it is further along.
>
> I just want to comment on the only-constructor injection policy that you are
> promoting. And the fact that the two paragraphs are contradictory. In the
> first you acknowledge that services may be outside the scope of Tapestry
> IoC. But in the next you go on to say that "To encourage service
> implementations to properly store service depenencies as final instance
> variables, such dependencies are passed
> only into the constructor." which doesn't jive with the
> "place-nice-with-others" phrasing in the first paragraph.
>
> I disagree with philosophy of forcing people to have the services only
> injected via constructors because:
>
> 1. it results in a monster constructors for some key services.
I would say that those key services may be insufficiently factored
into smaller cooperating services. Seperation of concerns!
> 2. yet another barrier to converting from T4
> 3. unnecessarily imposing a requirement on the Tapestry developer.
> 4. meaningless - just because you force a monster constructor doesn't
> mean the person is going to make it a final member.
> 5. You are assuming that it is unconceivable for services once wired
> together to ever want to be rewired - and this is not the case.
I see that as a whole can of worms. I strongly think that static
structure / dynamic behavior extends into the services tier.
>
> But at the end of the day - why be dogmatic about this?
Because I'm a very stubborn person?
Points well taken. We could definitely do something like Guice and
allow the Inject annotation on methods as well as method parameters,
to indicate a method which represents a point of injection.
>
> Or did I misunderstand something?
>
> -Pat
>
> P.S. the case for rewiring is thus: Originally wiring the service it is
> wired to a local version of another service. While the server is running,
> the local service is turned off and replaced with a reference to a remote
> version of the service. This would happen if the box is experiencing high
> traffic volumes and rather than handle all the work on the current box, the
> server starts sending some traffic to an different server. The idea of
> rigid, statically wired services defeats this flexibility.
>
>
> On Nov 10, 2007 3:22 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> > Services are loaded by the normal class loader without any special
> > trickery. We create classes (proxies and such), but don't modify
> > existing classes for Tapestry IoC. This is necessary to ensure that
> > services code inter-operates properly with all kinds of third party,
> > legacy and other code that is far, far beyond the scope of Tapestry
> > IoC.
> >
> > To encourage service implementations to properly store service
> > depenencies as final instance variables, such dependencies are passed
> > only into the constructor.
> >
> > So for services, injection is assumed, for the constructor parameters
> > (as if an @Inject annotation was present).
> >
> >
>
--
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
Re: Feedback wanted on IoC documentation
Posted by Patrick Moore <pa...@amplafi.com>.
Hi Howard --
I appreciate the work you are doing on T5 and look forward to moving to it
when it is further along.
I just want to comment on the only-constructor injection policy that you are
promoting. And the fact that the two paragraphs are contradictory. In the
first you acknowledge that services may be outside the scope of Tapestry
IoC. But in the next you go on to say that "To encourage service
implementations to properly store service depenencies as final instance
variables, such dependencies are passed
only into the constructor." which doesn't jive with the
"place-nice-with-others" phrasing in the first paragraph.
I disagree with philosophy of forcing people to have the services only
injected via constructors because:
1. it results in a monster constructors for some key services.
2. yet another barrier to converting from T4
3. unnecessarily imposing a requirement on the Tapestry developer.
4. meaningless - just because you force a monster constructor doesn't
mean the person is going to make it a final member.
5. You are assuming that it is unconceivable for services once wired
together to ever want to be rewired - and this is not the case.
But at the end of the day - why be dogmatic about this?
Or did I misunderstand something?
-Pat
P.S. the case for rewiring is thus: Originally wiring the service it is
wired to a local version of another service. While the server is running,
the local service is turned off and replaced with a reference to a remote
version of the service. This would happen if the box is experiencing high
traffic volumes and rather than handle all the work on the current box, the
server starts sending some traffic to an different server. The idea of
rigid, statically wired services defeats this flexibility.
On Nov 10, 2007 3:22 PM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Services are loaded by the normal class loader without any special
> trickery. We create classes (proxies and such), but don't modify
> existing classes for Tapestry IoC. This is necessary to ensure that
> services code inter-operates properly with all kinds of third party,
> legacy and other code that is far, far beyond the scope of Tapestry
> IoC.
>
> To encourage service implementations to properly store service
> depenencies as final instance variables, such dependencies are passed
> only into the constructor.
>
> So for services, injection is assumed, for the constructor parameters
> (as if an @Inject annotation was present).
>
>
Re: Feedback wanted on IoC documentation
Posted by Howard Lewis Ship <hl...@gmail.com>.
Services are loaded by the normal class loader without any special
trickery. We create classes (proxies and such), but don't modify
existing classes for Tapestry IoC. This is necessary to ensure that
services code inter-operates properly with all kinds of third party,
legacy and other code that is far, far beyond the scope of Tapestry
IoC.
To encourage service implementations to properly store service
depenencies as final instance variables, such dependencies are passed
only into the constructor.
So for services, injection is assumed, for the constructor parameters
(as if an @Inject annotation was present).
Now for components, it's a different story. The component classes are
very specific to Tapestry, not intended for reuse elsewhere, and are
modified at runtime to work properly and efficiently within the
constraints of Tapestry's multi-threaded runtime environment.
Tapestry components are quite a bit different from service, in terms
of lifecycle, and in terms of the what can be injected (all sorts of
resources besides services) and in the fact that they q
On Nov 10, 2007 12:59 PM, Martin Strand
<do...@gmail.com> wrote:
> I was just wondering the opposite - why not constructor injection for
> pages/components?
>
> Martin
>
>
> On Sat, 10 Nov 2007 21:43:10 +0100, Michael Courcy
> <mi...@gmail.com> wrote:
>
> > Hi
> >
> > Thanks again for this effort of documentation.
> >
> > I have a question about dependency injection between services.
> >
> > We can inject a service thanks to the @Inject annotation in a page
> > component.
> > I find this feature pretty handy.
> >
> > But (correct me if I'm wrong but I think I'm not because I test it) we
> > can't @Inject a service in a sercice.
> > Instead we must provide the service to the other service through its
> > constructor.
> >
> > Why did you make this choice ?
> >
> > I would find useful as well to inject a service in a service with the
> > same annotation ?
> >
> > Michael
> >
> >
> > Howard Lewis Ship a écrit :
> >> I've been working on new documentation about Tapestry IoC (similar
> >> stuff will be coming for Tapestry core):
> >>
> >> Overview:
> >>
> >> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
> >>
> >> Cookbook:
> >>
> >> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
> >>
> >> Feedback is encouraged!
>
> ---------------------------------------------------------------------
> 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
Re: Feedback wanted on IoC documentation
Posted by Martin Strand <do...@gmail.com>.
I was just wondering the opposite - why not constructor injection for
pages/components?
Martin
On Sat, 10 Nov 2007 21:43:10 +0100, Michael Courcy
<mi...@gmail.com> wrote:
> Hi
>
> Thanks again for this effort of documentation.
>
> I have a question about dependency injection between services.
>
> We can inject a service thanks to the @Inject annotation in a page
> component.
> I find this feature pretty handy.
>
> But (correct me if I'm wrong but I think I'm not because I test it) we
> can't @Inject a service in a sercice.
> Instead we must provide the service to the other service through its
> constructor.
>
> Why did you make this choice ?
>
> I would find useful as well to inject a service in a service with the
> same annotation ?
>
> Michael
>
>
> Howard Lewis Ship a écrit :
>> I've been working on new documentation about Tapestry IoC (similar
>> stuff will be coming for Tapestry core):
>>
>> Overview:
>>
>> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>>
>> Cookbook:
>>
>> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>>
>> Feedback is encouraged!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Feedback wanted on IoC documentation
Posted by Michael Courcy <mi...@gmail.com>.
Hi
Thanks again for this effort of documentation.
I have a question about dependency injection between services.
We can inject a service thanks to the @Inject annotation in a page
component.
I find this feature pretty handy.
But (correct me if I'm wrong but I think I'm not because I test it) we
can't @Inject a service in a sercice.
Instead we must provide the service to the other service through its
constructor.
Why did you make this choice ?
I would find useful as well to inject a service in a service with the
same annotation ?
Michael
Howard Lewis Ship a écrit :
> I've been working on new documentation about Tapestry IoC (similar
> stuff will be coming for Tapestry core):
>
> Overview:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>
> Cookbook:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>
> Feedback is encouraged!
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Feedback wanted on IoC documentation
Posted by Davor Hrg <hr...@gmail.com>.
the topics are very interesting, but seem hard when first reading...
the text can be expanded bit more for easier understanding.
I've read this page few times
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/patterns.html
and currently can only think of:
add link to Chain of command:
http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/command.html
so people can read that page for details.
Davor Hrg
On Nov 9, 2007 7:52 PM, Ben Acker < benacker@gmail.com> wrote:
> Looks good, but having it split into linkable sections would be useful if
> folks can't read the whole thing at once (same or multi-page).
>
> On Nov 9, 2007 10:09 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> > I've been working on new documentation about Tapestry IoC (similar
> > stuff will be coming for Tapestry core):
> >
> > Overview:
> >
> > http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
> >
> > Cookbook:
> >
> >
> >
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
> >
> > Feedback is encouraged!
> >
> > --
> > 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
> >
> >
>
Re: Feedback wanted on IoC documentation
Posted by Ben Acker <be...@gmail.com>.
Looks good, but having it split into linkable sections would be useful if
folks can't read the whole thing at once (same or multi-page).
On Nov 9, 2007 10:09 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> I've been working on new documentation about Tapestry IoC (similar
> stuff will be coming for Tapestry core):
>
> Overview:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>
> Cookbook:
>
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>
> Feedback is encouraged!
>
> --
> 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
>
>
Re: Feedback wanted on IoC documentation
Posted by Christian Edward Gruber <ch...@gmail.com>.
I agree. I'm using tapestry-ioc in a new UI framework I'm building
for desktops, and this is really helping out.
Christian.
On 9-Nov-07, at 5:52 PM, Andy Huhn wrote:
> Howard,
>
> Excellent documentation! I'm a newbie to the world of Tapestry, IoC,
> and front-end development in general (my background is ETL
> development--large batch loads of data between different systems).
> I've
> struggled for weeks to piece concepts together from the documentation
> and examples I could find.
>
> This pulls together in one place a lot of very valuable information
> into
> a wonderful overview.
>
> OVERVIEW
> The overview page was easy reading, and made a lot of sense to me. I
> wouldn't change a thing.
>
> COOKBOOK - Basics
> I was somewhat confused reading the section on service disambiguation,
> but I'll take your word that there's more info on it later--that after
> reading the "Basics" page, I won't need to have a firm grasp of it.
>
> COOKBOOK - Service Configurations
> Excellent page! All of this has been over my head up until now.
> Extremely useful documentation here.
>
> I was very glad to see that one of your examples also explained a
> Dispatcher. I've seen discussion of that on the mailing list the last
> few days, and have really wanted to understand it better.
>
> Also, I think it would be helpful to include an example of receiving a
> Mapped Configuration. There is an example of contributing, but not
> one
> of receiving.
>
> COOKBOOK - Using Patterns
> I found myself losing interest in this page, because I couldn't see
> how
> I would ever need to contribute an injection. Because of that, it was
> hard for me to engage to see how I could use the pattern.
>
> Thanks for putting so much effort and thought into the
> documentation...it's very valuable for us users, and for the
> acceptance
> of the project!
>
> Andy
>
> On Fri, 2007-11-09 at 10:09 -0800, Howard Lewis Ship wrote:
>> I've been working on new documentation about Tapestry IoC (similar
>> stuff will be coming for Tapestry core):
>>
>> Overview:
>>
>> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>>
>> Cookbook:
>>
>> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>>
>> Feedback is encouraged!
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Feedback wanted on IoC documentation
Posted by Andy Huhn <am...@insightbb.com>.
Howard,
Excellent documentation! I'm a newbie to the world of Tapestry, IoC,
and front-end development in general (my background is ETL
development--large batch loads of data between different systems). I've
struggled for weeks to piece concepts together from the documentation
and examples I could find.
This pulls together in one place a lot of very valuable information into
a wonderful overview.
OVERVIEW
The overview page was easy reading, and made a lot of sense to me. I
wouldn't change a thing.
COOKBOOK - Basics
I was somewhat confused reading the section on service disambiguation,
but I'll take your word that there's more info on it later--that after
reading the "Basics" page, I won't need to have a firm grasp of it.
COOKBOOK - Service Configurations
Excellent page! All of this has been over my head up until now.
Extremely useful documentation here.
I was very glad to see that one of your examples also explained a
Dispatcher. I've seen discussion of that on the mailing list the last
few days, and have really wanted to understand it better.
Also, I think it would be helpful to include an example of receiving a
Mapped Configuration. There is an example of contributing, but not one
of receiving.
COOKBOOK - Using Patterns
I found myself losing interest in this page, because I couldn't see how
I would ever need to contribute an injection. Because of that, it was
hard for me to engage to see how I could use the pattern.
Thanks for putting so much effort and thought into the
documentation...it's very valuable for us users, and for the acceptance
of the project!
Andy
On Fri, 2007-11-09 at 10:09 -0800, Howard Lewis Ship wrote:
> I've been working on new documentation about Tapestry IoC (similar
> stuff will be coming for Tapestry core):
>
> Overview:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/overview.html
>
> Cookbook:
>
> http://tapestry.formos.com/nightly/tapestry5/tapestry-ioc/cookbook/index.html
>
> Feedback is encouraged!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org