Details
-
Wish
-
Status: Resolved
-
Major
-
Resolution: Won't Fix
-
5.0.15
-
None
-
None
-
None
Description
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.