Hi Howard, Some precisions. I think the term "security" that i've used can be misleading and maybe inappropriate here.
Actually, the purpose is to share an existing common complex business layer (BL) and to expose parts of it depending on the GUIs that uses it (admin, front, segmented by sector/business, ...). It can be useful for big projects, with lot of developers, to be sure that services are used in the dedicated context to help them in their development, frame the process and for a better maintenability without modifying the existant BL. In my mind, it's more a matter of "Is the service or method I'm using suits to the GUI i'm developing ?" (In the GUI developer point of view as a "service user", not mine as a "service provider"). In development mode, an error message can help him to know : "This service or method is not suitable for this GUI...". (a simple advisor in a module that we would provide for the concerned GUI) But, here , thanks to the easy tapestry extensibility, the developer can redeclare the service in its appModule and works around the rule (even unintentionally :)). So, providing a preventOverriding() method in the ServiceBinder class could be a plus in tapestry-ioc ? or, to a lesser extent, a preventAdvice() method (like the existing preventDecoration()) ? Just a suggestion. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Prevent-overriding-services-implementation-tp3415241p3424766.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
