Il 24/12/2009 19:50, Howard Lewis Ship ha scritto: > I'm also a bit surprised at how eager people are to make use of > cumbersome solutions like Spring Security to accomplish simple tasks > such > as protecting pages. The Spring Security logic is path-based, > requiring an awkward mapping from paths to Tapestry pages. When I > need to implement that > kind of security, I define annotations that I can place on pages and > provide a filter that checks for the annotation on the page ... and > I've seen multiple clients > do the same thing.
This is a very good example of what is probably missing in Tapestry, at least from the point of view of a new user. Is this technique documented somewhere? Is this demonstrated by some existing archetype or demo app? Is this part of any Maven archetype or of any "canonical" way of developing applications with Tapestry. Is this approach "advertised" somewhere on the Tapestry web site? As a newbie, to discover/design this approach by myself I first have to study (Java and) Tapestry quite in deep and to understand it quite well. As a programmer, it is my usual job to study and understand new technologies and new tools but... as a "smart" programmer I also decided to use a framework like Tapestry just to save some time and some effort... There is a evident contradiction... :-) If Tapestry does not offer anything for my Authentication/Authorization needs, I will just look somewhere else, for example at Spring's site (ACEGI/Spring security). I will not reinvent the n-th wheel by myself. If Tapestry wants to be a "package of ready-to-use solutions" for the typical webapp developer, the solutions it provides have to be advertised, documented, demonstrated and made readibly usable by the new users, in particular the ones who have little or any experience with Java. BEWARE: I'm not saying YOU did not enough or that you did the wrong thing with Tapestry. I'm just telling you what is missing in T5 from my POV. Tapestry IS a wonderful piece of code and I do like it a lot. > Ideally there would be a single solution for this, > but I've found that page security is just not a one-size-fits-all > solution. Maybe a Tapestry 5 component/module would be a good general-purpose solution for this Authentication/Authorization common need. Maybe even a HowTo or a demo would be enough. At least, they could be a solution for 80% of the applications (the ones that uses the approach proposed by ACEGI/Spring Security, BTW). Maybe Tapestry does not need the dozens of components that are available for other frameworks, like Wicket, but it surely need some ready-to-use, standard solutions for a few very diffused, very standard needs like authentication and access control. > In other words, jumping over backwards for integrations with > technologies is often not the best approach. Yes, it would be nice to > have a checkbox "compatible with Spring Security" but I'd rather talk > about how easy it is to create your own custom extensions that work > precisely as you need. Even better, it would be fantastic to have a Maven archetype switch to enable the access control subsystem generation. Even better again, this could/should be supplied by derived works, like Tynamo (and it will, as long as I know). This would keep T5 as simple as possible while still supplying the user with a rich feature set. Tynamo and AppFuse are extremely important for Tapestry for many reasons and one of those reasons is "standardization". As a new user, I expect to find a canonical way to develop Tapestry/Tynamo applications and a canonical set of tools. This because I do not want, and cannot, spend a few weeks trying to discover the right tools and the right design patterns to be used for the task at hand by myself. As a quite typical new user, I need /guidance/ as well, not just a toolbox. > We've had this discussion at Formos; it was often easier to create a > totally custom solution in Tapestry than it was to take an > off-the-shelf solution that did 80% of what was needed and customize > it the last 20% of the way. That is surely true but the people who can understand and use this "from-scratch" approach maybe is not the kind of people who would use Tapestry. As a Python programmer, I can usually avoid to use code written by others and I can develop everything from scratch. This often keeps me away from Django or Pylons, even if they do supply most of required tools for the task at hand (together with a long list of ties...). If I had this same dominance of the Java technology, maybe I would write everything from scratch and I would not use Tapestry at all. I'm not saying that I want to use Tapestry to cope with my ignorance of Java, of course, but I do think I have the right to not be a Java ninja just to use a framework. ;-) I'm not saying that Tapestry is hard to understand and use, either. I'm just saying that many of its gems are still hidden in a jungle of code and documentation and needs to be unveiled. Beside this, take into account the fact that custom solutions are not always the best solutions. When you have to deal with many programmers (and maybe a high turnover) and/or many projects, you can become eager for standardization: a standard set of tools and a standard set of patterns used by all of your developers for all of your projects. Standardization means manageability and, when you have a tested, bug-free, commmunity-agreed code base, it also means rationality and reliability. This kind of standardization is what drove me to Tapestry and Trails (now Tynamo) in first place. Anyway, these are JM2C. Have some nice Christmas's holydays and a happy new year. -- Alessandro Bottoni Website: http://www.alessandrobottoni.it/ "Prediction is very difficult, especially about the future." -- Niels Bohr
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
