You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Howard M. Lewis Ship (Reopened) (JIRA)" <ji...@apache.org> on 2011/09/29 00:51:45 UTC
[jira] [Reopened] (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 ]
Howard M. Lewis Ship reopened TAP5-212:
---------------------------------------
Assignee: Howard M. Lewis Ship
> 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
> Assignee: Howard M. Lewis Ship
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira