PRADO is a PHP framework expressly inspired by Tapestry. As you might expect, all I've had a chance to do is glance over the documentation, but it looks very nice, and their site is very professional and slick.
I suspect the relationship between PRADO and Tapestry is the same as between Tapestry and WebObjects ... the precursor "proves" the space is viable, but I doubt the implementation is all that similar, given the different languages involved.
Still, best of luck ... but don't expect any framework, on any platform, to keep up with Tapestry 5!
11 comments:
I have built some nice professional sites using Tapestry. I use Hivemind for all my server side dependency injection.
However for my latest project I am using Ruby on Rails for the web UI, connecting to a Java backend. It's a bit of a pain to expose the necessary services, but it's kind of a good pain because it makes you think about what the services should be.
And with the immediacy and dynamic-ness of RoR and the compact syntax of Ruby (like Python), it's actually hard for me to imagine going back to anything that I need to compile, use template syntax, type cast, generate wrapper classes.
So this sounds like a statement but it's also a question. Have you used RoR and do you have any doubts that a compiled statically typed language is the right approach for user interface development?
I used Prado for several projects at work, since it's first version. It's a good framework, but not really a Tapestry clone. It has borrowed several ideas, from Tapestry but also from .net, or even Delphi. The more surprising is that the result is rather nice and coherent.
For instance, page templates are more similar to JSF ones, with components embedded as special tags, and you can also embbed script like in JSP.
Prado is easy to learn as long as you not have to build some complex components. But with some work I could get a good toolkit of technical components, which I extend in an distinct HTML-looking version for each project, and then making web pages with the right look is very quick.
It has also a nice documentation, and don't try to hide what should be the best documentated part of each even-driven framework, the page life cycle : http://www.pradosoft.com/demos/quickstart/?page=Fundamentals.Pages
With that framework you can nearly forget that you are working in PHP... until you look at the performances : reading and parsing more than 50 files for each request has some effect...
Nice to see that my yesterday mail to you resulted in a corresponding entry in your blog ;-) I'll definitely try PRADO to see if it's able to bring Tapestry (-practices) to the PHP world.
File IO are very expensive in PHP. File IO problems can be fairly easily over come using two forms of caching. Both are very simple to setup.
1) Install APC byte code cache, this caches the php script as byte code in memory.
2) Install the distributed memcache server, and enable caching in Prado to use the memcache with 1 line configuation.
The cache 2) aleviates Prado from going to the disk to fetch the page template and avoids parsing as well.
have you try to use wedge (http://wedge.sourceforge.net/)? This could be better than Tapestry since the pages are all POJO
kgilpin,
I'm sorry..your doing what!!!??
How, pray tell, are you hooking up rails to a java backend?
And there is also a better Tapestry called Wicket(http://wicket.sourceforge.net/)
which Tapestry 5 is now trying to catch up.
Wicket has a nice community and a few nice ideas, but it does not compare to what I have planned for Tapestry 5. I believe Java is going to thrive at the high end and performance is going to be one of the differentiators from Ruby on Rails. In addition, the Wicket model can't address the kind of short-cycle development issues that will be part of Tapestry 5. I think Wicket is fairly broken in that it stores the component model inside the HttpSession. This has been a critical flaw for JSF as well, where they've realized that they don't have a proper approach to handling true scalability. Wicket is a neater, cleaner version of Tapestry 1.0 or maybe 2.0. I've said in the past that I found it quite unambitious for starting from scratch. I'm now working on Tapestry 5 which is quite ambitious.
Howard,
Have you noticed Wicket is going to become an Apache project soon? If it's as bad as you say surely apache would'nt have considered it.
I think the Wicket team are doing a great job and have a compelling framework.
With the direction you have chosen of making radical changes to any major Tapestry release and not being backward compatible, one doesn't need to look in a crystal ball to be able to predict that Tapestry would loose more user base than gain by the time release 5 comes out. And where would they all go? To a framework that has already stolen a good number of Tapestry users- Wicket.
The reason Wicket is being considered an apache project is because apache finally realized the mistake they made promoting tapestry as the next java webframework.
Its really sad to see these kinds of comments from wicket users, it is not the kind of community I was helping to build. If you are going to write comments like these at least have the balls to sign them with your name.
Post a Comment