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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > > Hi -- > > > > On Nov 17, 2007 8:41 AM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > > On Nov 16, 2007 10:39 PM, Patrick Moore <[EMAIL PROTECTED]> 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 >
