Daniel Fagerstrom wrote:
<snip/>
<scr:component name="myApp">
<scr:implementation
class="org.apache.cocoon.blocks.osgi.BlockServlet"/>
<scr:service>
<scr:provide interface="javax.servlet.Servlet"/>
</scr:service>
<scr:property name="path" value="/test2"/>
<scr:property name="attr" value="bar"/>
<scr:reference name="blockServlet"
interface="javax.servlet.Servlet"
target="(component.name=cocoon.servlet2)"/>
<scr:reference name="skin"
interface="myCompany.FancySkinServlet"
target="(component.name=fancy-skin)"/>
</scr:component>
The target could be overriden by the configuration service. Do we get
polymorphism this way based on the interface of references?
I think it should work, neat idea :)
Otherwise we have mainly discussed polymorphism at the "web service"
level. Where a blocks interface would describe what URI:s that the block
responds and what input and output the URI:s would be assumed to
produce. A formal contract could possibly be defined in terms of WSDL,
but the feeling when this was discussed long time ago, was that it was
better to have block contracts at the documentation level.
Following this I have not even thought about implementing any "type
checking" on the URL level.
So currently we have "untyped" polymorphism. A block can call any block
in any role as long as they are wired together.
Do you feel a need for stricter checking?
this makes the use of the deployer simpler as "auto-wiring" works for all cases
that don't want to change the default implementation
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
