You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org> on 2007/03/09 20:48:10 UTC
[jira] Created: (TAPESTRY-1339) Rework Tapestry IoC to remove the
concept of module ids and qualified service ids
Rework Tapestry IoC to remove the concept of module ids and qualified service ids
---------------------------------------------------------------------------------
Key: TAPESTRY-1339
URL: https://issues.apache.org/jira/browse/TAPESTRY-1339
Project: Tapestry
Issue Type: Improvement
Components: tapestry-ioc
Affects Versions: 5.0
Reporter: Howard M. Lewis Ship
Assigned To: Howard M. Lewis Ship
As discussed on the mailing list, the cost/benefit ratio for qualified module ids is very high (in terms of adding complexity to the system) given that true name collisions are reasonably avoidable (in a system that will likely consist of between 5 and 10 modules for a particular application). Much of the documentation can be simplified greatly by treating service ids as (caselessly) unique, rather than qualified by a module id.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
[jira] Closed: (TAPESTRY-1339) Rework Tapestry IoC to remove the
concept of module ids and qualified service ids
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ https://issues.apache.org/jira/browse/TAPESTRY-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAPESTRY-1339.
------------------------------------------
Resolution: Fixed
Fix Version/s: 5.0.3
The one caveat I have with the application is really a Java language limitation: can't have multiple methods with the same name and same parameters return different types. So sometimes, you need to include the service id in the method name just to prevent collisions. Of course, with the new flat naming, you can easily break large modules into small pieces.
> Rework Tapestry IoC to remove the concept of module ids and qualified service ids
> ---------------------------------------------------------------------------------
>
> Key: TAPESTRY-1339
> URL: https://issues.apache.org/jira/browse/TAPESTRY-1339
> Project: Tapestry
> Issue Type: Improvement
> Components: tapestry-ioc
> Affects Versions: 5.0
> Reporter: Howard M. Lewis Ship
> Assigned To: Howard M. Lewis Ship
> Fix For: 5.0.3
>
>
> As discussed on the mailing list, the cost/benefit ratio for qualified module ids is very high (in terms of adding complexity to the system) given that true name collisions are reasonably avoidable (in a system that will likely consist of between 5 and 10 modules for a particular application). Much of the documentation can be simplified greatly by treating service ids as (caselessly) unique, rather than qualified by a module id.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org