MAKE IT EASIER TO DONATE COMPONENTS & CODE I think this is a great idea but I don't think it needs to be that complicated. To me the problem is there is no central repository for module jars so I end up adding a bunch of repositories to my pom file. All that's needed is a way to submit a repository url to a build process that just creates jars for each project. Then you just add that repository to your pom file and you are good to go. It could be as simple as a Jenkins install that just builds jars from svn or git and places the jars in a common location. You could have both snapshots and releases. The build process could also build a documentation site that describes all the modules so you have one place to find everything.
MOVE TOWARDS GREATER CLIENT-SIDE FOCUS There are really two paths here, progressive enhancement and something more like GWT. When I'm building public websites I usually pick progressive enhancement. It took me a while but I finally figured out mixins are the way to do this. I could never get the hang of Prototype but with JQuery it is pretty easy to build sites this way. The only real problem is you can't pass a javascript function back thru an AJAX request because JSON does not allow functions. The second problem is it seems pretty easy to end up with a big mess after doing a bunch of zone updates to the same page but that's just the nature of doing things this way. Since I've heading down this path I'd say Tapestry is one of the best frameworks for building this kind of site. For internal application type sites I've always used GWT with Tapestry. It's nice using Java on both sides and with Eclipse you can debug both the client and the server at the same time. The problem is it's a bit difficult to integrate the two and I've never be completely happy with what I've come up with. My other complaint about GWT is the widgets are not very polished and it takes a lot of work to get them to look nice. I think the challenge here is deciding what Tapestry wants to be. I can understand wanting to be JavaScript framework agnostic but I think this causes two problems. 1. You end up with the lowest common denominator of functionality 2. You have to port every component to every framework or run mixed frameworks The problem with picking one is you limit the audience to developers that like Tapestry and whatever JavaScript framework you pick. Not an easy choice IS TAPESTRY JUST TOO WIERD/ESOTERIC/ENLIGHTENED FOR SOME/MANY JAVA DEVELOPERS? With Tapestry 5 I think it's finally approaching simple things are simple, difficult things are only slightly harder. Personally I think implementing the shared component library would go a long way toward solving this complaint because it would provide examples of how to solve problems and working code to solve them. The Tapestry-Hibernate module is great because it just works and I don't have to figure out how to integrate hibernate with Tapestry. It has some shortcomings but it's simple and it works for most use cases. I suspect a big part of the learning curve is the lack of Tapestry-Auth. Almost every app needs something like that and implementing one that really works is difficult so the first thing that happens is you get stuck and give up. Some suggestions: 1. It would be great if BeanEdit/PageActivation etc could just work with an Interface because I think this would make building libraries easier. I could have a User Interface and implement it in Hibernate or JPA. Then it could also implement what's needed by a Tapestry-Auth module and they could all work together. Currently you can't do this easily. Hopefully this would lead to a set of modules that could interoperate and give developers a big head start when building apps. A long time ago I used ACS ( now openacs.org ). It was helpful to be able to just pickup a forum module rather than implementing one. Since they shared common interfaces the forum module would just work with the permission module. 2. I know I created a heated discussion with my desire for a Tapestry object I could inject and have access to multiple services but I still think it would be useful. It would be nice if you bind an entire module with something like binder.bindModule(module.class) and then in your page just say @Inject private Module module; I think this fits nicely with the first idea and I think it would make things easier for new comers because it clearly defines the API for a particular module. Thanks Barry --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
