>AFAIK, just set the tapestry.production-mode symbol to true and service reloading is turned off.<
Wasn't this also turning of the template realoading and Page/Component replacement? Which I would like to have enabled. Ok I use Screenshots and a Firefox Selenium Driver with a trigger so the testcase opens a firefox window that is visible to me and then waits until I am done with inspecting the result. It also is able to take a screenshot and compare it to an expected image of the page or at least presenting me the image. I use a JFrame image viewer that updates every time the image changes. Makes it simple to just run the test and look at the pages outcome when doing this style adjustments. This way I rather use no reload capability at all. But sometimes it happens. > Of course, you can still inject services (including service implementations) by id, so you can get the implementations themselves when the needs arises.< How can I inject a concrete implementations? >>I dont need this and I would love to be able to cast my Service instances to the impl class which is quite a good way.<< > That's quite against the idea of IoC and OOP in general, which is about *not* using specific implementations of a given service as far as possible.< Please do not lecture me on OOP :-) I did my share with doing this Interface first programming style in 2001 (i guess) - programming only with public interfaces and public static factories for several weeks to get into and adopt this style. So if I do not want to use interfaces at all it has a good reason and is fully in line with OOP and IOC you can trust me. Today I am totally against using interfaces for services as long as you control the code and also are the end user of your code. It is simplier and clearer. No additional interface to document, maintain and to describe something you already see in the interface. Also it makes everything feel stiff and decoupled in a not useful way. So Yes it is good to have services around but it is depressing having an IOC that forces you to use service interfaces instead of concrete instances, makes no sense and feels overly complex ... So that has nothing to do with IOC and OOP, its just about to ease the implementation of the IOC (now in doupt) and also might have historic reason. So this lesson is not about OOP, IOC or whatever. This is about having a service for implementation that is serving concrete implemenation needs. So nothing to design (in terms of architecture) or to abstract here. Just plain old dependency inversion within the implementation realm. PS: you mentioned this its against OOP thing quite some times. Stop doing so. OOP is something different then a style. Its a way to decompose and model reality (well a section of it). Thats all. Nothing about style. There is some measure of good and not so good OOP but this is well... style. And yet again there are those principles, which are good to know and all. The rest is cognitive properties like experience, complexity and all this more or less fishy defined stuff. So yes OOP ok but nope not against it, I can ensure you :). 2013/10/15 Thiago H de Paula Figueiredo <thiag...@gmail.com> > On Tue, 15 Oct 2013 13:01:51 -0300, Martin Kersten < > martin.kersten...@gmail.com> wrote: > > I struggle a bit with the class loader supporting service implemenation >> reloading. >> > > AFAIK, just set the tapestry.production-mode symbol to true and service > reloading is turned off. > > > I dont need this and I would love to be able to cast my Service instances >> to the impl class which is quite a good way. >> > > That's quite against the idea of IoC and OOP in general, which is about > *not* using specific implementations of a given service as far as possible. > Of course, you can still inject services (including service > implementations) by id, so you can get the implementations themselves when > the needs arises. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@tapestry.**apache.org<users-unsubscr...@tapestry.apache.org> > For additional commands, e-mail: users-h...@tapestry.apache.org > >
