Been rapidly reassembling Tapestry functionality inside the new Tapestry 5 code base.
A first pass at localization is now in place. It's missing a couple of key features and a bunch of bells and whistles, but the basics are in place.
I've also started implementing assets. Currently, only context assets are supported, but I'll be working on classpath assets next.
Both of these things were necessary detours before I could start work on form input validation in earnest.
The code is coming together rapidly and very nicely, very cleanly.
I've been stretching to meet "the principle of least surprise" ... just looking for ways that the framework can cleanly and easily do things automatically. For example, the @Inject annotation is very flexible; it takes into account the type of field when determining how to interpret its value. @InjectAsset would have been easier, but that's one more thing for people to remember.
Also, I'm working on an "automatic" Tapestry stylesheet. I want Tapestry apps to have a good, clean look automatically, by inheriting a base stylesheet from the application itself.
Interestingly, because of the way Tapestry 5 renders (to a simplified DOM), it won't be necessary to have Shell or Body components, as with Tapestry 4. There's a post-processing stage that will be able to navigate the DOM and make selected changes, somewhat like a limited version of SiteMesh. This stage will be able to do things like insert a stylesheet link into the <head>.
In fact, I think there will be significantly fewer components in Tapestry 5, especially because of mixins (which will allow existing components to be used in new ways, rather than forcing the creation of entirely new components).
Onward and upwards. Less is More
27 comments:
How the field validation and the validation error messages presentation will look like? One thing I miss in Tapestry is something like the <logic:errorsPresent> and <html:messages> tags of Struts.
I already imagine what kind of cool stuff it's possible to achieve intercepting the last stage of the processing DOM.
I've always advocated the use of some sort of DOM-like processing and it seems to me that Tapestry 5 implementation will be a great great great feature for the upcoming future.
Great Howard you sort out so well!
Hi Howard,
With all the sound bytes and hype surrounding Tapestry 5, I became curious and went to look some more into it. Surprise, surprise, Tapestry 5 seems to me to be a refactoring of Wicket. True or false?
One of the great things about the Tapestry community is that they are quite a bit more enlightened than uses in other communities. This isn't even my observation, it's an observation, its a meme started
by Matt Raible.
There are definately a few users in the Wicket community you could not say the same thing about, and I wish the Wicket project leaders would reign them in. There's a disturbing trend of Wicket users trying to start flame wars on the Tapestry mailing lists, or here on my blog. What purpose that serves is anyone's guess (it serves no purpose).
You have, of course, got some thing specific to backup these comments about "users in the Wicket community", haven't you... Please share...
I note with amusement that you seem to take the accusation of Tapestry being a refactoring of Wicket with somewhat less equanimity than was shown when you made the counter accusation... ;-)
Hi Mr. Lewis Ship,
Do you remember the comment you made about Wicket at theserverside, http://www.theserverside.com/news/thread.tss?thread_id=38407
Reading that comment and the last comment made by you here on your blog site I think you should count yourself as the sole unenlightened being in the Tapestry community.
Regards,
Emmanuel
"Wicket is an interesting refactoring of Tapestry that has a small, very vocal community built around it. However, if I was to fork the Tapestry community and create a new code base from scratch, you can guarantee that what I came up with would not be as unambitous as Wicket!"
To read more see http://www.theserverside.com/news/thread.tss?thread_id=38407
Yep, that was an awful thing to say ... awfully accurate. I did say it, I did mean, I do think it is true. My initial exposure to Wicket was "I used Tapestry, I didn't like X and Y, so I built Wicket that does those things differently." Just as Tapestry is not a code fork of WebObjects, but is a fork of the concept, so is Wicket a concept fork of Tapestry. Tapestry 5 is a concept fork of Tapesty 4. I still feel that Wicket is unambitous compared to what we are and will be accomplishing with Tapestry 5 in terms of invisibility of the framework (especially: no base classes, not magic abstracts, no XML) and super-high performance (no reflection, miserly use of the HttpSession) and clean URLs. But I don't go posting into the Wicket user mailing lists with notes saying things like:
To scare the sh*t out of you, I'll tell you the truth that Wicket is going
Apache. The guys are going for gold. Wicket is currently the sexiest and
hottest Java web framework. How about that?
And that's not the first posting along those lines. It reeks of child-like insecurity masked as aggresiveness and it is annoying.
do you have a link to the mailing list thread where the "To scare the sh*t out of you," message was?
Howard,
Nice to hear you finally admit that what you said about Wicket being a refactoring of Tapestry was awful. It's rather unfortunate you realized that only after someone made a similar remark against you.
Now to some technicalities. I disagree with you when you say Tapestry 5 is a fork concept of Tapestry 4. Being a user of both frameworks and having looked into Tapestry 5, I think it's a fork concept of Wicket 2.0 plus some refactoring of Tapestry 4. Unlike Tapestry 4, wicket knows no XML configs, no abstract classes sh*t, etc. This has been the core principle of Wicket since it's inception. So don't be shy to admit you're forking these concepts from Wicket. Nothing is wrong with that. Above all the Wicket guys have no patent on those brilliant ideas, so they won't even bother your lawyers.
I'm looking forward to a release announcement on theserverside when Tapestry 5 comes out. Then I'll challenge you there on several fronts technically.
I hope you'll have the b*lls to let this post come out of your moderation. After all, that's all what freedom of speech is about.
Regards,
Justice
First of all, freedom of speech is for public discourse. This is a private (non-govermental) blog.
It seems like the Wicket community loves to bitch and moan.
The difference between comparisons between Tapestry 2 and Wicket, and Wicket and Tapestry 5 is that I didn't spend time digging through the Wicket source code. The common ideals of Wicket and Tapestry 5 are commendable, but there also been my goal since before Tapestry 3 was final (no base classes, no abstract classes) Avoiding XML wasn't as obvious before Java annotations.
T4 uses LocalizedNameGenerator to figure out where to look for .properties. It would be nice if that class could be overridden in T5.
I organize templates and messages like this:
pages/en/SomePage.html
pages/fr/SomePage.html
messages/en/SomePage.properties
It would be nice if I could just override LocalizedNameGenerator to accomplish that.
Ah how cute the wicket users are!
Perhaps if they devoted more of their time/passion to "working on" wicket instead of defending it there would be less to be defensive about.
Wicket is nice but not even remotely comparable to Tapestry. Get over it. You don't have a champion in your current dev group that is better than Howard. Sorry. Truth isn't always nice but you guys need a serious reality check.
Surely the two communities can learn things from each other?
Tapestry pre-dates Wicket, and was almost certainly the best component framework around when Wicket was conceived. Wicket built on some of the concepts, reworked other things, and invented some new ways of doing stuff, exactly as one would expect. If you build a wheel, it has to be round - it's hardly surprising that two web component frameworks should have similar ways of doing many things.
I've tried both. Wicket was much easier to pick up and write good things with. Tapestry used to have a very, very steep learning curve and too much XML. I'm glad they've been fixing that and are fixing it more so for version 5.
You can't expect either framework to just stand still, and a part of that is borrowing the best ideas from wherever you can find them.
It's refreshing to see that Wicket's lack of XML is finally spreading elsewhere. Unfortunately, Tapestry seems to be sprinkling annotations everywhere instead. It's a bit less magical and annoying to edit, but still not as powerful as raw Java code, so Tapestry isn't really copying Wicket at all.
It's like the whole Java community has suddenly finally realised too much XML is bad, and has stopped believing all the rubbish that people spout about it. Unfortunately, they've mostly gone from the shiny XML bauble to the shiny annotations one.
I like Wicket because it doesn't have all this metadata nonsense - it's all just proper code, so you can override it, and inherit from it, and do all sorts of other things that metadata makes hard (<stares hard at the half-baked annotation implementation Sun spat out>), but which a real OO-language makes easy.
Well, I think we have all beaten this to a dead horse. I'm afraid the best advice I've gotten is to just delete troll comments rather than try to convert them to any kind of discource. And there is room for more gentility on both sides of this ... rant? discussion? Whatever it is.
and how about hivemind 1.2 or 2.0.
I like xml style congfig.
Hi Howard,
i've been learned tapestry since last 11 months. i'm so curious with tapestry 5. it looks have a different style from tapestry 4.x...and i love it. cos it will erase the xml that a little bit annoyed me. when the tapestry 5 will be released ?.
This type of petty discussion is why the Java open source community in general will keep chasing their tails. In order for these platforms to become competitive on a grand scale what is required is unity, co-operation, mutual learning and simplification (especially in configuration and deployment). Why don't you try working together rather than fighting.
A successful framework has to be simple above all. A developer doesn't want to spend endless hours fighting configuration and deployment issues, they would rather get on with coding. More cool features are not needed if the existing stuff is half baked. The Tapestry and Wicket developers should concentrate on getting this right instead of leaving the framework users to waste endless hours on mailing lists and searching through poor documentation. How many developers abandoned ship (no pun intended) because they just didn't have the time or patience to figure out how to do stuff that should be obvious... remember we didn't write these frameworks so we don't know them inside out, we also need to deliver the goods ON TIME at work. To use a framework effectively it has to be easy to set up and intuitive to use. this is the mark of quality that you're missing. Personally, I have a love hate relationship with Tapestry, I love what it could be and almost is, I hate the shaky foundations of the platform, it's lack of robustness, troublesome configuration and deployment. (Who of you have ever used ColdFusion? One of the oldest component frameworks with excellent documentation and its so simple to set up. Microsofts .Net is along similar lines). JSF with Netbeans is following their example, they all realized complexity is the enemy... while you guys as usual fight over which platform is technically superior in concept, well both of you have missed the point which is 'developer adoption' and usability, try and look at the big picture!!
Wicket has taken one approach to simplification. Tapestry 5 is taking a very different approach. Certainly the changes to T5 I'm pushing are all about simplification and developer productivity; I'm aiming to make Tapestry the most productive web development environment, without sacrificing runtime performance. I feel the wake up call was Ruby on Rails.
JSF and .NET as examples of frameworks that are easier? Funny. I guess it depends on what kind of developer you are and what you expect a framework to help you with. I actually worked on two .NET projects a while ago, and absolutely hated it. If you can follow the mold and work with existing components, and your pages don't get too crazy (as I found real complex pages always crashed my VS 2003) you'll get by - though that dragging and dropping isn't really my idea of how to build some solid software - but as soon as you want to step out and create custom components and patterns for things, you're in trouble and away is your productivity.
IMHO, Tapestry, Wicket and Echo attract more to the 'coder' crowd out there; people who are totally comfortable using bare IDEs and expect building software to be a serious task where quality may be about something more than pushing out a winning number screens a day.
Totally my 2c of course :)
Agreed Eelco. :)
Though the same could be said of a lot of javascript toolkits / other languages as well. I think the difference comes when you have to find out what the difference is between building an internal application with a few users vs an external public facing web app serving hundreds of thousands. ...Those tools just won't help you then.
"This type of petty discussion is why the Java open source community in general will keep chasing their tails. In order for these platforms to become competitive on a grand scale what is required is unity, co-operation, mutual learning and simplification (especially in configuration and deployment). Why don't you try working together rather than fighting."
While there is a lot of disagreement in Open Source, I think that's actually very healthy. I cannot imagine a reasonable unification of Tapestry and Wicket. In general, there's never going to be a Grand Unified Web Framework (or any other kind of framework) any more than there will ever be a unification of the Windows and OS/X user interfaces. Different approaches to problems appeal to different audiences. The only way you are going to get agreement on how to do anything is to have a governing structure that imposes a tyranny of one sort or another. Who wants that? -- Jonathan Locke
Hi Howard,
Please tell me how Tapestry is going to handle the HTTPS/HTTP within secured web applications.
Thanks & Cheers
Anh My
Given the emphasis on runtime performance in Tap5 and your knowledge of wicket's architecture, how do you think the two will compare in production environment?
Dose Tapestry5 use tags like <t:comp type="Checkbox".../> instead of <input type="checkbox" jwcid="@Checkbox".../>?
I don't want to see that changes.
I'm just about ready to support T4-style templates again. It's not hard to do, but its been low priority compared to all the important stuff.
Post a Comment