You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Massimo Lusetti (JIRA)" <ji...@apache.org> on 2011/08/12 00:22:27 UTC

[jira] [Closed] (TAP5-212) Remove usage of Strings as service id's

     [ https://issues.apache.org/jira/browse/TAP5-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Massimo Lusetti closed TAP5-212.
--------------------------------

       Resolution: Won't Fix
    Fix Version/s: 5.3

Please open a new one for 5.3 if this still applicable

> Remove usage of Strings as service id's 
> ----------------------------------------
>
>                 Key: TAP5-212
>                 URL: https://issues.apache.org/jira/browse/TAP5-212
>             Project: Tapestry 5
>          Issue Type: Wish
>    Affects Versions: 5.0.15
>            Reporter: Davor Hrg
>             Fix For: 5.3
>
>
> Since @Marker annotations were added and multiple markers support too, all is a step closer to removing strings as service ids.
> on march 10 HW asked for simplifying tapestry by removing @Contribute (mail with subject: "Simplify Tapestry IoC?")
> but back then @contribute used String for service id and switching to a naming convention was a step forward, I believe.
> I'll argue this ticket with an assumption:
> Module is written and changed far less often than tapestry pages.
> While there is definitive benefit from conventions in tapestry core,
> for tapestry-ioc might be more suitable for  closer integration with type safety and refactoring.
> I will elaborate this based on contribute convention in tapestry module
> currently you write this to add TypeCoercers:
> public void contributeTypeCoercer(){...}
> my proposal would be almost the same as before removing @Contribute:
> @Contribute(TypeCoercer.class)
> public void addCoercers(){...}
> In a situation where modulesare autoloading, and cases when missing dependancy means only
> fewer functionalities, ClassDefNotFound exceptions coluld be intercepted to alow continuing startup.
>  
> I'm unaware of how strongly are service ids integrated into the framework and if this is a feasible proposal.
> Just feels like a logical step forward after @Marker annotations.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira