Il 29/12/2009 21:32, Alex Kotchnev ha scritto: > chenillekit-access, and a bunch more). As much as people have a tendency to > complain that spring security is too complicated, it seems that any other > solution (e.g. based on T5 IoC) that attempts to provide the same level of > flexibility and generality will eventually end up with similar complexity ( > and will most likely never have the mind & market share of spring security). > Thus, it seems to me that the effort to provide a "new" framework to do all > of this is somewhat futile.
Actually, maybe there is a need for TWO different solutions: 1) A quite basic module, or even a well-documented demo, that just takes into account the most common requirements and uses a set of sensible defaults. This basic "package" should not have to be extensible or flexible. It should just have to be usable and understandable. It would be mostly used to study this problem and to see how to solve it in a Tapestry-like way. It would also be used as a quick&dirty solution for the most basic applications. IMHO, this solution should be developed with Tapestry annotations (see: http://tapestryjava.blogspot.com/2009/12/securing-tapestry-pages-with.html) and used as a demo of such programming technique, as well. 2) An enterprise-level module, like Spring Security. This solution should have to be flexible and extendible. It should be able to deal with LDAP, OpenID, JASIG CAS and other providers. It would be used for complex, enterprise-level apps. > An alternative approach (which seems to be quite successful in Grails > land) seems to be to provide integration & simplification w/ existing > security frameworks that already have all of the flexibility (and > complexity) that you talk about . For example. in Grails using the spring > security plugin comes down to installing the plugin and annotating your > controllers w/ Roles - it certainly reduces the number of available options > (thus making it less flexible) but the ease of getting started with it is > quite attractive . This would a very good solution for this problem and I vote for it. Despite this, it would be very little "tapestrystic" (it rhimes with "pythonistic")... I mean: it would miss the apportunity to contribute in making a more componentized, elegant working environment for all of us. > If the desire is to provide a pure T5 based solution, > why not take one of the existing security modules (e.g. chenillekit-access) > and analyze its approach and improve it instead of starting from scratch > (and use the forum as an opportunity to improve & extend the same existing > component) ? This approach is exactly what I would expect for the "enterprise-level module" I described above (case 2). It could/should be something like ACEGI or Swarm/Wasp and it should be very standardized, quite extensible/flexible and very well tested. It could be based on annotations or on other techniques, depending on the judgment of the developing community. Most likely, it would deserve a separated project. JM2C -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ "Life is a sexually transmitted disease, and it's 100% fatal." -- Unknown
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
