> There's also JavaConfig and use of annotations instead of XML, but > Tapestry-IoC still looks better to me. And Spring doesn't have distributed > configuration.
At the time I had a look at Spring it didn't have this ;-) > What I meant is that it is hard to find your >> way around the IoC concepts neccessary to master tapestry.. > > What concepts exactly? Starting in the frontend, there are concepts like the static structure, dynamic behaviour, the Environment and the Assets which are hard to get. Thats what I remind of fighting with some months ago. Also the lag of some functionality: select models out of beans (there is a wiki entry, why not include it into core?!), file system assets, etc. in 5.2 I am currenty fighting how to white list my resources... some default examples to allow pictures, css, etc would be nice. (has been some time I looked, maybe its now there). In the backend, it gets more complicated: contributing services, decorating services, overriding services... and most important: what services to override to solve my problem - how are they playing together. It is really MUCH to learn. I agree that its very very powerful once you managed to get over the initial learning curve. But this curve is _very_ steep. Available books help (my luck to live in germany), but they do not cover more detailed things like what I meantioned. >> Some people say it is over engineered - I don't think so. But maybe >> its exposing too much of its excellence to the user, forcing us to be >> as excellent as the developers. > > Please give us some examples. What examples do you want to hear? When I first looked at the tapestry code I did not understand anything.. it took a lot of time to get into parts of the architecture, and it will take a lot more to get the whole picture. >> Which brings me to another point: It >> is hard to contribute to tapestry, because you need a very high >> skillset to join the effort. It's _way_ easier to contribute to wicket >> or struts2. Result is, of course, that their codebase is not nearly as >> good as tapestry's. > > You can also contribute by writing libraries. ;) You should know I've tried ;-) BTW the libraries are spread all over the web (google code, kenai, github, tap360..). A central plugin would be great. Tap360's intention was good, but hosted commercially does not help to gain trust. Also Howard left the company, and some plugins left. Maybe a good structured wiki page with prominent link on the homepage would be enough. > Please give us some examples of hard-to-build modules. tapestry-cdi, tapestry-jpa2, tapestry-persistence in general (with transactions ;). Also, the available examples are hard to understand.. take tapestry-spring. It's poorly commented/documented and IMHO hard to understand what is going on. Sure, its very little code - but maybe that is why it is so hard :) > This point was discussed a lot and > I have a component that uses a very nice jQuery color picker and it works. I know - but the component library uses prototype, and its not documented that integrating jquery is easy. There is no jquery module, etc. > From a quick read (I'm busy writing a Tapestry course now), it seems that > YAML is a CSS framework. Yep - and also it defines common template structure for forms, regions, etc. > The thread is here: > http://old.nabble.com/Customize-markup-of-client-side-validation-to26668520s302.html#a26668520 > There was a solution proposed (your own ValidationDecorator). Have you had > problems with this approach? Yes.. I had, but will try again the next days. The point is: A custom ValidationDecorator is not documented anywhere. Also it seems a bit overcomplicated to just implement some custom markup. > The documentation has been improved by Howard and you can see its progress > here: http://tapestry.formos.com/nightly/tapestry5/ Good to hear! One wish: Could you explain RegexAuthorizer and WhitelistAuthorizer in more detail, maybe with some common examples? >> (and comes with warp-persist, >> offering JPA and db4o integrations - transactions as well). > > In this case, it seems to me it's a matter of money. Many people at Google > work on it in their paid time, while almost everyone working on Tapestry > work in their free time. Thats an explanation - but does not help. > I'm sorry, but your examples weren't enough for me to understand. > One counter-example: in my Ars Machina Project, I have authentication and > authorization packages. I only need to add annotations to my page classes to > inform if it needs a logged user and/or what roles the need use to be able > to use that page. I have an access logger package that works just by adding > it to the classpath. Very good example: Security is another thing I had expected to just work out of the box in a web framework like tapestry. It does not, and is not that easy for a new user to come up with a solution (and to understand the concepts behind the explanations in the wiki). Like said before, tapestry is very powerful - but you need to invent a lot of stuff yourself. And then this isn't something easy (as a newbie). Another argument: If it is that easy to build modules, where is the transaction module you want that badly? It shouldn't be too complicated, a matter of decorating annotated services. Or.. maybe tapestry-ioc gets in your way somehow? Maybe its hard to integrate with tapestry-hibernate ... or maybe its hard to come up with a solution that will be useable by other persistence modules as well. However, it seems to be not that easy :) > The markup is responsibility of each component. You can write a mixin to > change the generated markup or write your own components. Mixins are no nice solution for this usecase. And writing my own components just to change some structure? That's not exactly the flexibility I would expect. Piero --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
