You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Essl <ch...@yahoo.de> on 2003/09/04 18:36:45 UTC
[HiveMind] Why was overridable reomved from service?
As I see the option to override the contribution to a service was removed.
The cvs log just states that this was
a bad idea. Why was override a bad idea?.
I thing it was a good idea. Especially in an api which requires a service a
default working implementation could be defined (without requiring the user
to do anything). A user however could overwrite it (maybe using the default
implementation with differnt properties). I think this is what overridable
was thought for.
When overridable is not present I don't know a realy convient way with
which you could achieve this. Ie if you use extension-points, it is much
less convinient for the programmer (I guess you would always use more
classes / interfaces) and generally less flexible for the user.
Maybe you could tell me a way how to achive the same effect without
overridable.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
RE: [HiveMind] Why was overridable reomved from service?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> Thank you. This is realy the better aproach.
>
It's a bit longer winded, but more flexible (it allows access to the original service). In addition,
it represents doing more with existing code, rather than creating new code and new elements.
HiveMind is "feeding on itself" lately, with more features being implemented in terms of existing
services and features. That tells me I'm on the right track.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
Re: [HiveMind] Why was overridable reomved from service?
Posted by Christian Essl <ch...@yahoo.de>.
Thank you. This is realy the better aproach.
On Thu, 4 Sep 2003 14:55:55 -0400, Howard M. Lewis Ship
<hl...@comcast.net> wrote:
>
>> As I see the option to override the contribution to a service was
>> removed. The cvs log just states that this was
>> a bad idea. Why was override a bad idea?.
>
> It led to a lot of ambiguities as I was adding new service models. I
> found other, better ways to
> accomplish the same kind of thing.
>
>
> <service id="OriginalService" ....>
> </service>
>
> <extension point-id="hivemind.FactoryDefaults">
> <default symbol="ServiceToUse" value="mymodule.OriginalService"/>
> </extension>
>
> <service id="MyDependentService" ...>
> <invoke-factory service-id="hivemind.BuilderFactory">
> <construct ...>
> <set-service property="otherService" service-id="${ServiceToUse}"/>
> </construct>
> </invoke-factory>
> </service>
>
>
> Using symbols for indirection, MyDependentService will be linked to
> OriginalService.
> Now, in another module:
>
>
> <service id="ReplacementService" ...>
>
> <extension point-id="hivemind.ApplicationDefaults">
> <default symbol="ServiceToUse" value="newmodule.ReplacementService"/>
> </extension>
>
>
>
> ApplicationDefaults override FactoryDefaults. MyDependentService will
> now be linked to
> ReplacementService.
>
> The advantage to this system is that ReplacementService can gain access
> to OriginalService. This is
> important to me, because this is a very common pattern in Tapestry, where
> it is common to wrap the
> default service implementation with a thin wrapper that adds some special
> features. I want a
> graceful way to accomplish the same thing in HiveMind.
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
> http://jakarta.apache.org/commons/sandbox/hivemind/
> http://javatapestry.blogspot.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
RE: [HiveMind] Why was overridable reomved from service?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> As I see the option to override the contribution to a service
> was removed.
> The cvs log just states that this was
> a bad idea. Why was override a bad idea?.
It led to a lot of ambiguities as I was adding new service models. I found other, better ways to
accomplish the same kind of thing.
<service id="OriginalService" ....>
</service>
<extension point-id="hivemind.FactoryDefaults">
<default symbol="ServiceToUse" value="mymodule.OriginalService"/>
</extension>
<service id="MyDependentService" ...>
<invoke-factory service-id="hivemind.BuilderFactory">
<construct ...>
<set-service property="otherService" service-id="${ServiceToUse}"/>
</construct>
</invoke-factory>
</service>
Using symbols for indirection, MyDependentService will be linked to OriginalService.
Now, in another module:
<service id="ReplacementService" ...>
<extension point-id="hivemind.ApplicationDefaults">
<default symbol="ServiceToUse" value="newmodule.ReplacementService"/>
</extension>
ApplicationDefaults override FactoryDefaults. MyDependentService will now be linked to
ReplacementService.
The advantage to this system is that ReplacementService can gain access to OriginalService. This is
important to me, because this is a very common pattern in Tapestry, where it is common to wrap the
default service implementation with a thin wrapper that adds some special features. I want a
graceful way to accomplish the same thing in HiveMind.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com