Perhaps time would be better spent decoupling dynamic configuration from IOC,
at least as a first step.
On May 22, 2013, at 3:33 PM, Thiago H de Paula Figueiredo wrote:
> On Wed, 22 May 2013 16:30:04 -0300, Lenny Primak
> wrote:
>
>> I don't see myself getting paid for this :) As much as I w
On Wed, 22 May 2013 16:30:04 -0300, Lenny Primak
wrote:
I don't see myself getting paid for this :) As much as I would love to,
I cannot afford this :)
Same for me (except I don't see the need for replacing Tapestry-IoC, but
sometimes we write code just because "why not?")). :) On the o
On May 22, 2013, at 3:27 PM, Thiago H de Paula Figueiredo wrote:
> On Wed, 22 May 2013 15:00:41 -0300, Lenny Primak
> wrote:
>
>>> You're really interested in removing Tapestry-IoC of Tapestry. I see your
>>> good intentions there even if I disagree. I suggest you something which I'd
>>> lov
On Wed, 22 May 2013 15:00:41 -0300, Lenny Primak
wrote:
You're really interested in removing Tapestry-IoC of Tapestry. I see
your good intentions there even if I disagree. I suggest you something
which I'd love to see in this discussion: Tapestry is open-source, so
what about you writing
On May 22, 2013, at 1:53 PM, Thiago H de Paula Figueiredo wrote:
> On Wed, 22 May 2013 14:18:06 -0300, Lenny Primak
> wrote:
>
>> You guys keep talking about distributed configuration.
>> How is this related to IOC anyway?
>
> Very easy answer: this is about configuration of services/beans, a
On Wed, 22 May 2013 14:18:06 -0300, Lenny Primak
wrote:
You guys keep talking about distributed configuration.
How is this related to IOC anyway?
Very easy answer: this is about configuration of services/beans, and
services/beans are the core of IoC.
The only way it is related is becau
You guys keep talking about distributed configuration.
How is this related to IOC anyway?
The only way it is related is because its baked into tapestry IOC.
These ought to be 2 separate modules.
If, indeed there is a dire need to distributed configuration (I don't believe
there is such an integral
On Wed, 22 May 2013 09:07:19 -0300, Robert Zeigler
wrote:
Unfortunately, no other IOC system (that I've seen) offers something
quite like T5-IOC's "distributed configuration". The closest is perhaps
MultiBinding/MapBinding in Guice
(http://code.google.com/p/google-guice/wiki/Multibinding
Unfortunately, no other IOC system (that I've seen) offers something quite like
T5-IOC's "distributed configuration". The closest is perhaps
MultiBinding/MapBinding in Guice
(http://code.google.com/p/google-guice/wiki/Multibindings). But any similar
Guice/Spring solutions I've seen to date jus
On Tue, May 21, 2013 at 7:12 PM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Tue, 21 May 2013 23:09:29 -0300, Kalle Korhonen <
> kalle.o.korho...@gmail.com> wrote:
>
>> Lance has not participated in this thread even with a single message.
>>
> Thanks for correcting me, Kalle! I
On Tue, 21 May 2013 23:09:29 -0300, Kalle Korhonen
wrote:
Lance has not participated in this thread even with a single message.
Thanks for correcting me, Kalle! I was talking about Lenny, not Lance.
Sorry, Lance! Damn similar names . . . :P
--
Thiago H. de Paula Figueiredo
On Tue, May 21, 2013 at 6:53 PM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
> On Tue, 21 May 2013 20:28:11 -0300, Lenny Primak
> wrote:
>
If Tapestry replaces T-IoC with something else, we would cause such a huge
> backward compatibility problem that most people would abandon Tapes
On Tue, 21 May 2013 20:28:11 -0300, Lenny Primak
wrote:
You are missing my point.
This is not about how bad / great tapestry-ioc is.
This is about having to learn yet another DI system
before you can truly use tapestry to its full potential.
You still need to learn one anyway. And, after le
"Well, yes, your screwdriver is great I guess, but I already know how to
use a hammer."
On Wed, May 22, 2013 at 12:28 AM, Lenny Primak wrote:
> You are missing my point.
> This is not about how bad / great tapestry-ioc is.
> This is about having to learn yet another DI system
> before you can tr
You are missing my point.
This is not about how bad / great tapestry-ioc is.
This is about having to learn yet another DI system
before you can truly use tapestry to its full potential.
If it used an existing IOC, the barrier to entry would be lower.
On May 21, 2013, at 6:01 AM, Inge Solvoll wro
Couldn't agree more with Inge
I have worked with tapestry-Guice & tapestry-Spring IOC and I think one of the
merits of Tapestry IOC is how easily you can integrate it with any IOC.
Any web framework needs some build-in IOC, It may be a couple of Java classes
but it is there. In Tap
I love Tapestry IOC. When used in a very basic way, it's almost
indistinguishable from Guice. Actually it's less intrusive since you don't
need annotations for injection.
Tapestry is very powerful when you do more advanced stuff, and I just love
that the power's there even though I don't use it th
I don't think neither I nor hantsy have any realistic action items that will
possibly be implemented,
simply because the maintainers have too much stake in the status quo.
There is nothing wrong with that. It is legitimate to protect your investment,
especially if you making a living off of it.
And I forgot another huge reason for not replacing Tapestry-IoC in
Tapestry: backward compatibility. Unfortunately, we just can't break
compatibility in such a large way. Many people still void Tapestry due to
its past history of completely non-backward compatible changes and the
Tapestry t
On Wed, May 15, 2013 at 10:23 PM, hantsy wrote:
> Tapestry should embrace the existed and mature specs, such JSR330, Bean
> Validation, Managed Bean, etc, Spring has supported them in 3.0 natively.
>
I don't really agree with this logic. It leaves no room for innovation.
Everyone would just us
I'm not getting what are you trying to say. Is it "lets replace
tapestry-ioc with some other ioc"?
Or "lets implement proper CDI support"?
> If you are implying that this is all so important, why isn't every
project on the planet using Tapestry-IOC?
> I would be very happy using the Web Framework
> As I said in another thread, you're suggesting replacing Tapestry-IoC
> with CDI. If that was done, people would still learn one IoC framework
> in order to learn Tapestry. CDI has a broader reach (in termos of
> concepts and features) than T-IoC. Not much people use CDI now (I may
> be wrong, o
On Wed, 15 May 2013 18:57:55 -0300, Lenny Primak
wrote:
I agree that distributed configuration is great.
But, it's not equivalent to tapestry-ioc.
Agreed.
There are lots of ready-made solutions for distributed configurations
already.
You can also easily build one on top of ready-made CDI
I agree that distributed configuration is great.
But, it's not equivalent to tapestry-ioc. There are lots of ready-made
solutions for distributed configurations already.
You can also easily build one on top of ready-made CDI implementation, if you
really want to (I don't think there is a need)
On Wed, 15 May 2013 17:30:17 -0300, Lenny Primak
wrote:
using the CDI spec. I am not even sure that what you are calling
Distributed Configuration is even needed for the Web Framework.
Just take a look at Tapestry (the web framework) itself. Look at how a new
coercion, request handler,
Starting new topic... nothing relating to tapestry-CDI announcement...
I am sure you grasp the technology just fine.
But this is a bit changing the topic.
I am talking about IOC specifically.
You are mentioning distributed configuration.
There are plenty of ways to implement what needs to be don
26 matches
Mail list logo
