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
<[EMAIL PROTECTED]> wrote:
> On Sat, 17 Nov 2007 14:41:16 -0200, Howard Lewis
On Sat, 17 Nov 2007 14:41:16 -0200, Howard Lewis Ship <[EMAIL PROTECTED]>
wrote:
On Nov 16, 2007 10:39 PM, Patrick Moore <[EMAIL PROTECTED]> wrote:
I disagree with philosophy of forcing people to have the services only
injected via constructors because:
1. it results in a monster construc
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
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 o
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 resu
On Nov 16, 2007 10:39 PM, Patrick Moore <[EMAIL PROTECTED]> 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 tha
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 servi
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
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 documentati
On Nov 9, 2007 7:09 PM, Howard Lewis Ship <[EMAIL PROTECTED]> 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
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
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 injec
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 co
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 i
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 i
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
<[EMAIL PROTECTED]> wrote:
Hi
Thanks again for this effort of documentation.
I have a question about dependency injection between services.
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)
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 backg
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 cou
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 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 <[EMAIL PROTECTED]> wrote:
> I've been working on new documentation about Tapestry IoC (similar
> stuff will be comin
21 matches
Mail list logo
