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 - 12:01:32 EDT