I have a good opinion about Tapestry IoC approach in general
(including the now defunct Hivemind), and I wanted to investigate Guice.
There's some conflicting requirements to address here - we don't want
to write/maintain our own IoC container, yet, we don't want to embed a
huge third-party engine, of which we'll use only a subset of features.
I'd like it to work standalone, as well as be able to integrate (or at
least play well) with popular IoC containers (how many containers in
one app is too many?). Then there's a matter of modeler support, which
is adverse to annotations, and favors XML or other config files...
All in all, I think assembling a core of Cayenne stack via such a
container should open some interesting possibilities, beyond
organizing current configuration.
Andrus
On Jun 2, 2009, at 6:53 PM, Robert Zeigler wrote:
> If you're really considering going the 3rd party ioc route, I highly
> recommend T5IOC.
> Note that configuration is (typically) done via code in T5IOC, but I
> find it extremely flexible & powerful, while still being simple to
> use (and small! :).
> If not that, then guice. I'd even go for pico (though preferably
> not). Anything but the monster that spring has become. ;)
>
> Robert
>
> On Jun 2, 2009, at 6/29:02 AM , Andrus Adamchik wrote:
>
>>
>> On Jun 2, 2009, at 4:38 PM, Andrus Adamchik wrote:
>>
>>>>
>>>> Modeler support will be covered by setting class name of strategy
>>>
>>> I am afraid this approach will be rather arbitrary to the end
>>> user, so I suggest we discuss it some more before putting it in
>>> Cayenne. Marking an entity to use "soft delete" based on some
>>> criteria is a clear and understandable feature. Setting a "delete
>>> strategy" is not, and will contribute to confusion. This is
>>> totally be ok as a backend extension point, but I will hate to see
>>> that as a general use feature.
>>
>> In this context let me mention one idea for Cayenne 3.0 + N, that
>> I've been thinking about for some time. I am taking this to a
>> separate thread to avoid distraction from the soft delete
>> discussion, which has only tangential relevance.
>>
>> Since we already have a bunch of extension points throughout the
>> stack, some exposed via the Modeler (misplaced like cache JGroups
>> config, or justified like Adapter config), and some are available
>> only via the code, we need a way to reign them in. The standard way
>> of doing that is via an IoC container.
>>
>> No, I don't want to bundle Spring with Cayenne, besides it has to
>> integrate with the larger app ecosystem, so we still need to figure
>> the technical details. But the point is that we will be able to
>> provide a single place to configure all extension points, separate
>> from the mapping. As unlike the mapping those parameters are often
>> different for the same project, depending on the environment where
>> it is deployed.
>>
>> Right now this place is cayenne.xml (and it might as well stay this
>> way in the future), just that unlike say Spring config files, it
>> has a rigid structure and is not generic enough to handle arbitrary
>> extensions and dependencies. It was ok for the early versions of
>> Cayenne, since there was only a few things you could change (data
>> source factory and adapter I believe). But now something more
>> powerful and clean is desirable.
>>
>> Just some raw thoughts.
>>
>> Andrus
>
>
This archive was generated by hypermail 2.0.0 : Tue Jun 02 2009 - 16:04:12 EDT