tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Massimo Lusetti (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (TAP5-212) Remove usage of Strings as service id's
Date Thu, 11 Aug 2011 22:22:27 GMT

     [ 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

        

Mime
View raw message