|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 78
Messages: 78
Messages: 78
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Tapestry 5.0.1 Preview Release Now Available
Apache Tapestry Release 5.0.1, a preview release with limited functionality, is now available from the Tapestry 5 Project Page. This preview (or "alpha") release contains limited functionality.
Tapestry 5 is a totally new code base for the groundbreaking Tapestry framework.
Tapestry 5 features many improvements over Tapestry 4, including:- Component classes no longer extend from base classes
- Component classes are no longer abstract
- Component configuration is based on Java annotations, not external XML files
- Changes to page and component classes are picked up immediately
- URLs are shorter, "prettier", and case-insensitive
- Blazing Speed: Code paths have been simplified and runtime reflection is all but eliminated
- Simplfied coding model, based on convention over configuration principles
- Built-in BeanEditForm component for building simple create/update UIs
- Many, many, many other improvements too numerous to mention.
A series of screencasts introduce the new features of the framework. A new introductory tutorial (PDF) has been created as well.
Tapestry 5 is a work in progress, but already well suited to developing real applications. This initial preview release is intended to solicit feedback towards ongoing development and to prepare existing Tapestry developers for a future transition.
|
|
|
Message #226830
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I think Tapestry 5 is going to be a winner
I have been a Tapestry user since version 3. Version 3 was good, but 4 was much better, and Version 5 looks like it will be even better. It glad to see the POJO w/annotations approach embraced, and the fact that the app classes can be reloaded dynamically without restarting the app server will be very nice.
I had to choose a web presentation layer and it came down to JSF or Tapestry. I chose Tapestry because I liked its component approach better, and it was less "taggy." You could actually look at the html template and it looked like html, rather than namespaced-qualified xml. The learning curve for Tapestry 3 was pretty high. It took awhile for me to get it. 4 was easier, and it looks like 5 will be even easier.
I don't know exactly why Tapestry hasn't been a huge hit. It seems like there are more and more users, and that there are some big name implementers, but I don't understand why it hasn't taken off more. Some people have told me that they would rather stick to standards rather than implementation, yet these same people use Spring and Hibernate. Maybe it was the learning curve of Tapestry, or maybe that UI is just a hard thing to do well and make easy.
There are a lot of other web presentation frameworks (like Wicket, go Wicket!) which are also good. I think it's a good thing that there are so many good options. Which ever makes my life easier as a developer and maintainer is probably the one that will get my vote. And for Tapestry 5, this seems to be the angle that HLS has taken.
|
|
|
Message #226836
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Looks good, but ...
This looks very nice indeed and IMHO Tapestry 5 is an evolutionary step ahead, when compared with it's predecessors like Tapestry 3 and 4.
On the other hand, I also like to mention that all these so called "new things" already exist in other frameworks such as Wicket.
My other concern is compatibility. It would be darn painful task if you choose the path of migrating existing Tapestry 3 or 4 app to 5.
IMHO Tapestry 5 is a radical change from Tapestry 3 and 4 and thinks it needed not be even labeled Tapestry. These compatibility issues existed as well between version 3 and 4.
My question has always been, why should any major release of Tapestry be so radically different than it's predecessors that migration becomes almost an impossible task?
Regards
|
|
|
Message #226841
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Looks good, but ...
..My question has always been, why should any major release of Tapestry be so radically different than it's predecessors that migration becomes almost an impossible task?
Regards
Though Howard has wisely stayed away from making any promises I've already stated on the users list many times that I'll be writing an upgrade runtime layer to work between ONE previous version of Tapestry and T5. The specific version hasn't been decided yet.
He's already purposefully made this possible with a few key concepts so there should be at least one happy group of tapestry users provided with a nice upgrade path.
|
|
|
Message #226842
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why not used more?
I don't know exactly why Tapestry hasn't been a huge hit. It seems like there are more and more users, and that there are some big name implementers, but I don't understand why it hasn't taken off more. Some people have told me that they would rather stick to standards rather than implementation, yet these same people use Spring and Hibernate. Maybe it was the learning curve of Tapestry, or maybe that UI is just a hard thing to do well and make easy.
Or maybe it's that:
- There are no standards or plans to standardize. Successful non-standards are the exceptions, not the rule (and Hibernate will give way to JPA as it matures)
- Backwards Compatibility - More people use JSP than any other Java view technology. Standardization and backwards compatibility are the big reasons why. Tapestry constantly throwing so much away doesn't help them at all.
- Goofy Project Management - Why is an alpha of Tapestry 5 called "5.0.1"?!?
|
|
|
Message #226846
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
Ok, I'm going to have to call "bullshit" on this one.
-) Where do you think the JSF "spec" came from ? Not thin air.
-) JSP sucks, why would we want to support it?
-) I believe the 5.0.1 version is an indication of the correct version number. It started as 5.0.0 and he decided to not make any announcements until 5.0.1. What's so confusing about that?
Besides, you are really losing focus of the point. Among many other extremely cool features you can develop your Tapestry application "without reloading your app when you make code changes".
That's f-ing amazing and beautiful. Congrats to Howard on such awesome work. You rule. ;)
Or maybe it's that:
- There are no standards or plans to standardize. Successful non-standards are the exceptions, not the rule (and Hibernate will give way to JPA as it matures)
- Backwards Compatibility - More people use JSP than any other Java view technology. Standardization and backwards compatibility are the big reasons why. Tapestry constantly throwing so much away doesn't help them at all.
- Goofy Project Management - Why is an alpha of Tapestry 5 called "5.0.1"?!?
|
|
|
Message #226849
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
Wow, if the fact that it's not a JSR, not backward compatible, and has a version number that you don't like are your biggest objections, I'm gonna guess you'll actually love Tapestry, since you don't have any real technical objections to it.
I guess Sun should stop development of all Java APIs as well, since most shops use J2EE 1.3 or 1.4 at most.
|
|
|
Message #226852
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I don't care much about migration
Maybe I am in the minority here, but if a different framework does something much better than the current framework I am using, then there is a good chance I will switch (as long as it is "much better"). In fact, I would rather Tapesty 5 be totally different and totally better than previous versions, rather than try to preserve backward functionality. Might as well drop the old baggage. I'll rewrite a layer for the best solution when it makes sense. This applies to jumping frameworks, not just different versions of the same framework. So I'm not concerned about version compatibility at all. Although I realize other people might have different priorities.
|
|
|
Message #226854
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
Among many other extremely cool features you can develop your Tapestry application "without reloading your app when you make code changes".
Jesse,
To me this is nothing new because other frameworks like Wicket does this already.
I'm only sad for the other group of people using other versions of Tapestry who would be left out on the migration path.
I would reiterate that Tapestry 5 is so radically different from its predecessors that it doesn't even deserve the name Tapestry. Had you done this, all these migrations issues wouldn't prop up. I wonder why the Apache group sits back and watch all these craziness going on. It only gives them a bad name.
Jan
|
|
|
Message #226861
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
Congrats to Howard on such awesome work. You rule. ;)>
Jesse,
Users and investors don't care whether Howard is awesome, rules or is genius. They rather want value for money. If after every major release they have to throw 10 times more money than previously just because a developer wants to benefit from the new functionalities introduced in the latest release, then for them its no party.
Starting afresh with new ideas is easier than making that new ideas also backward compatible. That is the real challenge. And for me until Howard takes that challenge head on he doesn't deserve to be labeled awesome or genius or rules.
My .02 cent
|
|
|
Message #226862
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry's fate already sealed???
I'm not sure I see much point in Tapestry anymore - unfortunately. The combination of JSF + Facelets + Seam seems to give the best of all worlds:
*Config through annotations (Seam)
*Templates that can use standard html tags so as not to break web designer's display (Facelets)
*Super easy to create components based on existing templates/pages (Facelets)
*Backing beans/controller/actions (whatever you wanna call them) that use generic POJO model i.e. don't need to extend anything to work. (Standard JSF)
*Ever-increasing list of commercial/open-source component libs
The only current downside (and I don't see it as being much of one myself) is that you have to integrate these 3 main technologies yourself currently.
Howard certainly blazed a trail for doing a lot of things right in a time when there wasn't much choice, but it looks to me that now Tapestry's just having to play catch-up in terms of simplification. The learning curve was just too high for Tapestry in the past, as a result of its architecture. Maybe there's still a chance if a plethora of components can barrage the Java space and compel people, but I don't really see that happening.
|
|
|
Message #226864
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry's fate already sealed???
I think you left out the part where JSF has got to be one of the worst java web frameworks on the market.
Just because your p.o.s. has more commercial support it doesn't mean it's going to win. EJB2 had more commercial support too. I think we all know how that went.
..Maybe there's still a chance if a plethora of components can barrage the Java space and compel people, but I don't really see that happening.
|
|
|
Message #226869
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry's fate already sealed???
I'm not talking just in terms of JSF mind you. I'm talking in terms of JSF + Facelets + Seam. That combination collectively makes for a more fair comparison with Tapestry IMO. Facelets + Seam help to smooth out the rough edges of plain JSF. I'm not interested in talking about JSF by itself.
|
|
|
Message #226870
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry's fate already sealed???
I'm not sure I see much point in Tapestry anymore - unfortunately. The combination of JSF + Facelets + Seam seems to give the best of all worlds:
*Config through annotations (Seam)
*Templates that can use standard html tags so as not to break web designer's display (Facelets)
*Super easy to create components based on existing templates/pages (Facelets)
*Backing beans/controller/actions (whatever you wanna call them) that use generic POJO model i.e. don't need to extend anything to work. (Standard JSF)
*Ever-increasing list of commercial/open-source component libs
The only current downside (and I don't see it as being much of one myself) is that you have to integrate these 3 main technologies yourself currently.
Howard certainly blazed a trail for doing a lot of things right in a time when there wasn't much choice, but it looks to me that now Tapestry's just having to play catch-up in terms of simplification. The learning curve was just too high for Tapestry in the past, as a result of its architecture. Maybe there's still a chance if a plethora of components can barrage the Java space and compel people, but I don't really see that happening.
Not catch-up, but a significant leap-frog. Tapestry is going places none of the other frameworks can go. The next batch of screencasts and updates to the tutorial should start to really demonstrate the difference.
In addition, Tapestry 5 performance is quite excellent, superior to Tapestry 4 (which was already better than, or at least competitive with, JSF and Wicket ... you know how benchmarks are). In any case, performance is excellent ... through a combination of simplifications, use of concurrence, and elimination of runtime reflection.
It's not a case of "JSF can do what Tapestry does", we're all building on top of Java and HTTP, and its GET and POST in and HTML out. The devil's in the details, and Tapestry lets you get the maximum end result with the minimum amount of work. Things just work, with zero, or minimal, configuration and minimal (or zero) repetition.
When I see JSF today I still see Tapestry 2.2 (in 2002). You just can't turn a Camel (an animal designed by comittee) into a Thoroughbred.
|
|
|
Message #226873
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
so when's v6 going to be released
If history is any indication, Tapestry 6 should be out in about little less than two years.
|
|
|
Message #226878
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tapestry Advantages
Tapestry has a few advantages that are very critical for writing solid applications:
- Ability for compile-time verification. For example, Tapestry requires you to define the parameters your component is going to take, the types of the parameters, and whether each is required or not. This allows the correctness of your application to be verified at compile-time.
Surprisingly, most other frameworks (such as Facelets or Wicket) did NOT support this feature last time I checked. The correctness of your application could therefore only be verified at runtime through rather extensive testing (which is rarely done).
- Tapestry does support dynamic component tree, but its structure is static by default. Besides further allowing for more compile-time verification, this approach also allows for much smaller server and/or client state.
All of this is packaged in an very easy to use fashion (see the links in the article) that is useful for a small development as well. It's a win-win.
|
|
|
Message #226879
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: so when's v6 going to be released
If history is any indication, Tapestry 6 should be out in about little less than two years.
Maybe you should wait until v21 because then Howard might be on pension and would have implemented all his radical and kinky ideas. You're then assured of no more migration headache :-)
|
|
|
Message #226882
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5.0.1 Preview Release Now Available
Congratulations! Tapestry 5 looks awesome - I'm definitely going to look into it. IMHO this version could be good enough to last for a couple of years, so the best way to go forward would be:
a) (Re)build the Tapestry community around it.
b) Ensure T5 is properly supported.
c) Build (productivity/IDE) tools for it.
[d) Support portlet development]
|
|
|
Message #226890
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rich duck
Although I realize other people might have different priorities.
Can we agree with him ? Anyway, assuming this your statement is true:
They rather want value for money
So suppose applications based on former Tapestry versions are as much difficult to maintain as, for example ...errr... Struts based web applications are. Any enhancement or even usual maintenance to these application costs lots of money since the code is usually simply a mess.
Suddenly that mad open source programmer called Howard cames with the last version of his great web application framework called Tapestry. Howard lives in http://en.wikipedia.org/wiki/Duckburg.
Well, my point is, even http://en.wikipedia.org/wiki/Scrooge_McDuck could be convinced (by a proper person) to use Tapestry 5 since the code resulting from using last version looks clearly much smaller and easier to read, maintain and test than the previous one. Btw, did you tried it ?
Assuming the decision to upgrade or not is up to Mr Scrooge - who knows more than any other how to calculate risk versus opportunity, a core discipline for any capitalist - even if he realizes he will save just exactly 1 cent in development spending within the next 2 or three years, he will decide to upgrade.
Sure, is always possible that Howard "mad duck" will present another totally new version at that time but who cares ? Scrooge McDuck knows he could probably save another cent or may be even more with Tapestry 6...
Users and investors can do all sort of things, including having good decisions (at least sometimes...)
Have fun,
Rodolfo
|
|
|
Message #226888
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
Or maybe it's that:
- There are no standards or plans to standardize. Successful non-standards are the exceptions, not the rule (and Hibernate will give way to JPA as it matures)
Man, it has nothing to do with standard. Was JDO not a 'standard'?
It is about marketing. How can Mr Lewis Ship have the marketing dollar of Sum/IBM/Oracle/JBoss?
|
|
|
Message #226891
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
I think it is all about building the community around it. Take Spring for example - I don't think they have the marketing dollars all the big companies have, but they have a solid community behind them.
|
|
|
Message #226892
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I don't care much about migration
Maybe I am in the minority here, but if a different framework does something much better than the current framework I am using, then there is a good chance I will switch (as long as it is "much better"). In fact, I would rather Tapesty 5 be totally different and totally better than previous versions, rather than try to preserve backward functionality. Might as well drop the old baggage. I'll rewrite a layer for the best solution when it makes sense. This applies to jumping frameworks, not just different versions of the same framework. So I'm not concerned about version compatibility at all. Although I realize other people might have different priorities.
Good to hear some sensible talk on this thread (it's been much more like Slashdot). This is also the feedback I've gotten from the majority of my clients who have actually built and deployed T3 and T4 applications.
The talk of Tapestry 6 is ridiculous ... I'm never going through this again, and the design of Tapestry 5 exists to prevent the need for incompatible changes when adding features.
|
|
|
Message #226895
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
Jesse,
Users and investors don't care whether Howard is awesome, rules or is genius. They rather want value for money. If after every major release they have to throw 10 times more money than previously just because a developer wants to benefit from the new functionalities introduced in the latest release, then for them its no party.
Starting afresh with new ideas is easier than making that new ideas also backward compatible. That is the real challenge. And for me until Howard takes that challenge head on he doesn't deserve to be labeled awesome or genius or rules.
My .02 cent
I agree with the core point. Investment protection is critical for enterprise adoption. CIO's are being asked to do more with less money. Building a framework that allows developers to upgrade the framework without having to do major surgery would be a big plus. Productivity and performance are great, but it doesn't do me a lot of good if it takes a lot of effort.
|
|
|
Message #226898
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
Productivity and performance are great, but it doesn't do me a lot of good if it takes a lot of effort.
I just re-read that and it sounds stupid. The point is that if there is a mountain of existing code, upgrading the framework to take advantage of productivity or performance gains would be too expensive to seriously consider.
|
|
|
Message #226899
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Looks good, but ...
I also like to mention that all these so called "new things" already exist in other frameworks such as Wicket.
This is untrue. Wicket doesn't have:
1) Client-side storage of component state/tree for scalability (Wicket has to use a session).
2) Auto class reloading for great developer productivity (see WICKET-126).
3) Unit testing of components by asserting against the DOM tree output by the component (Wicket allows you to assert against the properties of the components only).
|
|
|
Message #226900
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
I would reiterate that Tapestry 5 is so radically different from its predecessors that it doesn't even deserve the name Tapestry. Had you done this, all these migrations issues wouldn't prop up. I wonder why the Apache group sits back and watch all these craziness going on. It only gives them a bad name.
Jan
It is still called Tapestry because the design principles behind have never changed a bit: Simplicity, Consistency, Feedback, Efficiency.
In fact, although Howard will likely disagree with it, I find most concepts in Tapestry haven't changed from Tapestry 4 and Tapestry 3. Just the actual ways of doing things have changed.
|
|
|
Message #226901
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5.0.1 Preview Release Now Available
Not sure exactly why people are smacking Tapestry around so hard. It is, after all, free to use or not use. Some people seem to feel a sense of entitlement, as if every open source project out there should be implemented exactly as they see fit. Sheesh....
That said, I have mixed emotions about the next version of Tapestry. The upgrade path from 3.x to 4 was difficult enough. Was it worth it? Sure. Would I like to budget the time to go through it again? Not so sure. I migrated several projects from 3.x to 4.0 free of charge for my client simply because I knew there were things that I just couldn't implement without a lot of heartache in 3.x. But would I want to take that burden on again? This kind of upgrade path, throwing everything out the window, is something you should not have to do so often. It is a significant cost that takes a while to amortize and see the benefits of. I'm also concerned about throwing out Hivemind. Not that I was such a huge fan of it in the first place, as I use Spring in my Tapestry projects, but now it's a whole other thing to start integrating Spring with and learn about.
Maybe the results will be worth the pain of the upgrade. I'm sure that 5.0 will be better than 4.0. I just think it's a bit difficult to be going through this kind of pain twice in such a short period of time and that it will make people think twice about using Tapestry. Which would be a shame, because I personally love what I've seen so far and would hate to see a community of people driven away because of practicality.
|
|
|
Message #226902
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5.0.1 Preview Release Now Available
Oh and by the way, I've been able to see the results of my code changes immediately at runtime with both Tapestry 3.x and 4.x for the past two years, thanks to MyEclipse. Not criticizing Tapestry 5, but just letting people know that it's not a feature that a framework necessarily has to provide.
|
|
|
Message #226911
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
BTW, I reckon 'JCP' should really be named more appropriately as 'JVP', i.e Java Vendor Process.
|
|
|
Message #226913
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry Advantages
Tapestry has a few advantages that are very critical for writing solid applications:
- Ability for compile-time verification. For example, Tapestry requires you to define the parameters your component is going to take, the types of the parameters, and whether each is required or not. This allows the correctness of your application to be verified at compile-time.
Surprisingly, most other frameworks (such as Facelets or Wicket) did NOT support this feature last time I checked.
Indeed. I often wished we could do such things in wicket. Imagine how cool it would be to do something like
class UserPanel extends Panel { public Userpanel(String id, User user) {...} }
and pass in that required strongly typed parameter to that panel component. But instead we are forced to create components with default constructors and initialize them later because we pool them and so cannot pass in any state in the constructor like normal java objects.
Oh wait, did I get wicket and tapestry mixed up?!? :)
|
|
|
Message #226916
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Looks good, but ...
Wicket doesn't have:
1) Client-side storage of component state/tree for scalability (Wicket has to use a session).
True, we have discussed this many times and decided that this was not very valuable. There are a lot of discussions on our mailing list if anyone is interested in our reasoning. Of course feel free to disagree. At the end its all about managing priorities for limited resources.
2) Auto class reloading for great developer productivity (see WICKET-126).
Our auto class reloading suffers from the same shortcoming as yours. When you add a new field to a component it fails. No matter how many dead chickens you wave in front of the screen your computer cannot figure out what the value of that field should be in the point of your component's lifecycle you are at now. Always initializing it to null might work for some components, but not for all, and if you guess wrong your component will act weird.
3) Unit testing of components by asserting against the DOM tree output by the component (Wicket allows you to assert against the properties of the components only).
Wicket allows you to get the rendered output string, which is trivial to parse into dom.
|
|
|
Message #226917
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why not used more?
Spring is not a JCP 'standard'. Now you are contradicting yourself.
My point was on marketing not on standards.
|
|
|
Message #226918
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry's fate already sealed???
superior to Tapestry 4 (which was already better than, or at least competitive with, JSF and Wicket ... you know how benchmarks are).
Competitive is the best word when you compare to Wicket, as in fact our benchmarks between Tapestry 4 and Wicket 1.3, which are put in a project available for everyone to check out, shows that Wicket is marginally faster (about 17%). Not that it matters that much, as CPU taken by the web layer is probably least likely the bottleneck when it comes to scaling (in fact, there is no single one, it all depends...).
|
|
|
Message #226919
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5.0.1 Preview Release Now Available
Not sure exactly why people are smacking Tapestry around so hard. It is, after all, free to use or not use.
Exactly. Writing a framework like Tapestry and doing a rewrite after being active on for years takes quite a bit of courage and persistence. Great job Howard, I hope you and Tapestry's users will benefit greatly from it.
|
|
|
Message #226920
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5.0.1 Preview Release Now Available
I'm sure that 5.0 will be better than 4.0. I just think it's a bit difficult to be going through this kind of pain twice in such a short period of time and that it will make people think twice about using Tapestry.
Sometimes good is good enough and you can postpone the better until the time is better :)
|
|
|
Message #226922
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Autoreloading
Igor,
Actually, you can add or remove fields, methods or whatever from a Tapestry page (or component) and it still just works. Tapestry reloads the class and, since Tapestry components serialize their state transparently and externally, the "new" components just connects up to the "old" components data. So apparently, I did a good job with the the sacrificial chickens.
|
|
|
Message #226927
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Autoreloading
Igor,
Actually, you can add or remove fields, methods or whatever from a Tapestry page (or component) and it still just works. Tapestry reloads the class and, since Tapestry components serialize their state transparently and externally, the "new" components just connects up to the "old" components data. So apparently, I did a good job with the the sacrificial chickens.
Perhaps you did not get my usecase, so please tell me if I am wrong:
Lets say I write a simple counter component. It has an int, a link that increments, and a label that shows it. I deploy it in my app, and get it up to count of 10. Then I add a date field that I update every time the link is clicked in my link. I also add a label that checks if the int is >1 and then takes the date, does a tostring() on it to display the value. (Its a pretty reasonable assumption to use int>1 rather then date!=null because after all the assumption about my internal state is that the date is always set when the int is incremented). But when tapestry reloads my class and applies the changes I will get an NPE when I next access the page because the newly added date field is initialized to null I imagine.
Removing fields is of course trivial. But you can also run into trouble when renaming fields, unless your dead chicken voodoo can keep track of that as well :)
Btw, Howard, kudos on having the balls to start fresh. I know there is a lot of pressure not to do that, but sometimes that is the only way to truly evolve something. T5 looks like a monumental improvement over T4.
|
|
|
Message #226926
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Autoreloading
Igor,
Actually, you can add or remove fields, methods or whatever from a Tapestry page (or component) and it still just works. Tapestry reloads the class and, since Tapestry components serialize their state transparently and externally, the "new" components just connects up to the "old" components data. So apparently, I did a good job with the the sacrificial chickens.
Yeah, but pages are not the only classes in application. What about domain objects? The "component data"?
|
|
|
Message #226929
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Looks good, but ...
Wicket allows you to get the rendered output string, which is trivial to parse into dom.
True, but it reflects that the design decision is sub-optimal and is now causing the programmer to do the work that should have been done by the framework.
|
|
|
Message #226932
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Looks good, but ...
Wicket allows you to get the rendered output string, which is trivial to parse into dom.
True, but it reflects that the design decision is sub-optimal and is now causing the programmer to do the work that should have been done by the framework.
Does it reflect a sub-optimal design? Wicket has been around for a good while and our users always rave about how cool/easy unit testing support is compared to other tools theve used in the past (not that it is perfect of course). Interestingly enough we have never had a request from anyone to allow them access to dom, perhaps they find testing with strings easier.
We are very user-driven when it comes to new features, so we tend not to build something we do not think will be used - it keeps the bloat down. Had someone requested access to dom we would happily provide it.
But please, do not put silly items on a feature matrix you are going to use to promote a product.
|
|
|
Message #226939
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Looks good, but ...
Does it reflect a sub-optimal design? Wicket has been around for a good while and our users always rave about how cool/easy unit testing support is compared to other tools theve used in the past (not that it is perfect of course). Interestingly enough we have never had a request from anyone to allow them access to dom, perhaps they find testing with strings easier.
It takes diligent and capable programmers to create what users request for, but it takes great programmers to conceive what is not requested for, but what is once made available, will make everyone's life a lot easier.
We are very user-driven when it comes to new features, so we tend not to build something we do not think will be used - it keeps the bloat down. Had someone requested access to dom we would happily provide it.
Not being requested != Won't be used. Rod Johnson didn't create Spring because users were queuing up requesting for a IoC container. Howard didn't create Tapestry because users were queuing up requesting for a component-based framework.
But please, do not put silly items on a feature matrix you are going to use to promote a product.
I think we should discuss a feature by its own merit, regardless whether users are requesting for it or not. If it has merits, it makes sense to put it into a feature matrix as it helps potential users to choose.
|
|
|
Message #226945
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I don't care much about migration
Good to hear some sensible talk on this thread (it's been much more like Slashdot).
Howard,
You call this comment sensible because it supports the radical decisions you've made for Tapestry.
I find this comment made by Igor Vaynberg, a Wicket developer, on this thread rather sensible. I quote:
We are very user-driven when it comes to new features
Is that the secret of Wicket's success? I hope you one day come to realize this as well. Maybe by then all your users have run away like rats.
|
|
|
Message #226948
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Looks good, but ...
Does it reflect a sub-optimal design? Wicket has been around for a good while and our users always rave about how cool/easy unit testing support is compared to other tools theve used in the past (not that it is perfect of course). Interestingly enough we have never had a request from anyone to allow them access to dom, perhaps they find testing with strings easier.
It takes diligent and capable programmers to create what users request for, but it takes great programmers to conceive what is not requested for, but what is once made available, will make everyone's life a lot easier.
We are very user-driven when it comes to new features, so we tend not to build something we do not think will be used - it keeps the bloat down. Had someone requested access to dom we would happily provide it.
Not being requested != Won't be used. Rod Johnson didn't create Spring because users were queuing up requesting for a IoC container. Howard didn't create Tapestry because users were queuing up requesting for a component-based framework.
But please, do not put silly items on a feature matrix you are going to use to promote a product.
I think we should discuss a feature by its own merit, regardless whether users are requesting for it or not. If it has merits, it makes sense to put it into a feature matrix as it helps potential users to choose.
Maybe for you parsing a string into a dom tree is a feat that requires greatness. For me it takes about five minutes and half as many lines of code.
|
|
|
Message #226949
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry Advantages
Indeed. I often wished we could do such things in wicket. Imagine how cool it would be to do something like
class UserPanel extends Panel { public Userpanel(String id, User user) {...} }
and pass in that required strongly typed parameter to that panel component. But instead we are forced to create components with default constructors and initialize them later because we pool them and so cannot pass in any state in the constructor like normal java objects.
Oh wait, did I get wicket and tapestry mixed up?!? :)
In Wicket, it's like:
Foo foo = new Foo("some input");
Bar output = foo.calc();
In Tapestry, it's like:
void f(Foo foo) {
Bar output = foo.calc("some input");
}
Which way is better? The former is treating the Foo object as the output itself and thus it is only used once. The latter is treating a Foo object as a processor that generates output for some given input.
I think both are valid ways.
|
|
|
Message #226951
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Looks good, but ...
Maybe for you parsing a string into a dom tree is a feat that requires greatness. For me it takes about five minutes and half as many lines of code.
I thought it was something very obvious. But after learning that no Wicket users has found a need for it, I thought it might be a feat :-)
Again, the issue is not how much work it takes to implement it, but the capacity to design features that work at the right level of abstraction.
|
|
|
Message #226954
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry Advantages
In Wicket, it's like:
Foo foo = new Foo("some input");
Bar output = foo.calc();
In Tapestry, it's like:
void f(Foo foo) {
Bar output = foo.calc("some input");
}
Which way is better? The former is treating the Foo object as the output itself and thus it is only used once. The latter is treating a Foo object as a processor that generates output for some given input.
I think both are valid ways.
They might both be valid in the sense they produce the same output, but they are certainly not equivalent. Constructors have semantics that no other methods have - after all they are there for a reason.
The question to ask is _if_ you had access to constructors which way would you go? Should you be able to construct the instance of Foo() without the string you pass in calc()? How many times should you be able to specify that string? If you are passing in a couple of properties when do you validate (do you have some special method to validate you call once youve set all the necessary setters like spring's IInitializingBean?)
This is just one example where the programming model is different between tapestry and wicket.
Of course the advantage of tapestry's more limited programming model is that it gets away with maintaining less state.
|
|
|
Message #226984
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I really don't understand
Like I said earlier, I've been a Tapestry user for awhile. But I have no allegiance to the product. The developers of it don't know me and I don't know them. When a new version of the framework comes out I evaluate it and see if it has anything I need or something that is much better. If not, then I don't upgrade. I haven't gone to Tapestry 4.1, for example, because there's nothing in it I need or want. Same goes for other frameworks (of various layers). I've still got some ap running on JDK 1.3 because I don't need to upgrade them.
The market is open for anyone to write whatever they want, however they want. No one is forced to use it. People put forth all sorts of libraries and frameworks all the time, addressing different issues and satisfying different tastes. Some do a porr job at the problem they are trying to address, but so what? Then don't use it. But don't bash it either.
I like Wicket, but the users are irritating. It has become a turn-off to me. It's like they define Wicket based on it's relationship to Tapestry. That being said, if the next release of Wicket is much better than what I am currently using or could use, I would still switch. But I doubt I would be part of its community.
I don't understand the hostility to Tapestry. If it were a piece of junk, johnny-come-lately, written by a bunch of arrogant wanna-bes, then let it be so. Who cares? Don't use it. If you prefer a different approach then use something else. Tapestry is not "the right way" to do web presentation. It's one way that some people choose. Next year, there could be a totally new way to do web presentation (in fact, I hope that is the case). For what I do, Tapestry is the best thing. There are several other layers that I deal with where I pick the best thing for me and have to re-evaluate all the time and I switch them periodicaly. But Tapestry is really the only one where there is a vocal contingent of non-users trying to bash it. Very strange. And I don't understand why. But it is getting really old, and I am just a tapestry user. If you don't like Tapestry, don't use it. If you think things should be done a different way, then do it, and make a framework so much better that people will adopt your framework based on its own merits, not on how bad Tapestry is.
|
|
|
Message #226987
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
+1
I don't use Tapestry and I am currently eyeballing a few items with GWT and JSF/Icesoft leading the proof of concept stage pack, but I my curiosity was piqued with this announcement.
I say all comers should throw their hats in and let the market decide. I *would* like to hear about why someone likes or dislikes a product because that's one way I determine if I should give it a closer look. If the reasons are those I agree with, one way or the other, and that person appears to have similar beliefs to my own, that saves me the problem of trying something I may not like or missing something that would work well for me.
|
|
|
Message #226992
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
It's like they define Wicket based on it's relationship to Tapestry.
Yes, that is *very* irritating to both Tapestry's and Wicket's development team. If there are any frameworks I'd like people to compare T or W with, it's the model 2 frameworks, as both T and W provide a better alternative.
It would be great if threads like this would be kept clean. That said, if I see bs statements, I'll be happy to react to them, no matter what thread their in.
|
|
|
Message #226997
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
I won't apologize for the Wicket user community. In fact, I think we really get the short end of the stick here. Everything was going great in the discussion above until someone posted this little piece of disinformation about Wicket:
"Ability for compile-time verification. For example, Tapestry requires you to define the parameters your component is going to take, the types of the parameters, and whether each is required or not. This allows the correctness of your application to be verified at compile-time.
Surprisingly, most other frameworks (such as Facelets or Wicket) did NOT support this feature last time I checked. The correctness of your application could therefore only be verified at runtime through rather extensive testing (which is rarely done)."
This irritated Igor and it irritates me reading it because it's quite clear to me that whoever wrote it has never actually even looked at Wicket before (Wicket has supported this critical "feature" since inception). Hey, at least I read the book on Tapestry twice before I gave up and started writing Wicket.
I don't hate Howard or Tapestry, but it seems like every time anyone discusses Wicket, it's seen as a Tapestry knock-off. That is incredibly annoying because the design decisions in Wicket are very different and lead to a framework that, as you say, stands on its own merits. That is, if anyone bothers to fucking look at it when the Tapestry user crowd runs around bad-mouthing it as a Tapestry knock-off without ever having looked at it in the first place! I've said it before and I'll say it again: the only thing Wicket "took" from Tapestry was that I noticed what a good idea "jwcid" was (although we ultimately decided wicket:id was a lot more readable and XHTML compliant).
The other totally unnecessary comment in this thread that annoyed me was the post that dissed Wicket design for not creating a DOM. It seems to me that while this design decision has a 5 line fix in Wicket that nobody has requested so far, this is probably the reason Tapestry is 17% slower than Wicket in our benchmark. Further, it implies that Wicket didn't make a lot of smart design decisions, which - having spent a huge amount of time on the design - I really resent. Particularly when you present an example of "poor design" this trivial (and IMO, debatable if not wrong). If you want to look at some design decisions in Wicket worth talking about, how about: swing-like programming model, no code in markup (not even EL expressions), memory-efficient stateful component model, crosscutting component-level security strategies, markup inheritance, trivial component definitions using Java extends keyword, jarrable component packages, detachable models, transparent back-button support, and so on.
I mean, it's just infuriating to hear Tapestry users discuss their own propaganda version of what Wicket is. In fact, if Tapestry users would simply stop talking about Wicket entirely, I for one would not post on these discussions at all. Particularly since I don't find Tapestry much worth talking about.
I totally agree with you that Wicket should be adopted based on its own merits (given an actual level playing field where others are not egoistically subtracting from it all the time). And I think there's a lot of evidence that is happening on its own.
Finally, you should not imagine that the Wicket community's annoyance and reaction to Tapestry-spread FUD is a reflection of the Wicket community. I've found it to be very helpful and supportive. If we've got a few zealots, I think they've just found what they are looking for and I'm not their keeper.
|
|
|
Message #226996
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I don't care much about migration
You really need to calm down. If you don't like Tapestry or its design and project leadership, fine. We get it. Point taken. At this point, the thread would be better served with actual productive feedback based on your use of it rather than bitter attacks on it with needlessly hyperbolic statements. This isn't slashdot or some gamer forum.
|
|
|
Message #227005
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My Two Cents - A User Perspective
It looks like there are a lot of debates on why someone will (or will not) use Tapestry 5.0 and why it will (or will not) succeed, I am going to chime in from a user perspective. My two cents worth.
My first exposure to Tapestry is 3.0. It is a great web framework. After working with JSPs, Struts, WebWork2, I was finally convinced Tapestry's approach was the way to go. However, the lack of good documentation, a web forum, and that it has a huge learning curve to begin with, it "scare" a lot of people off. I was one of those people in the beginning. I only became a user when I finally decided I REALLY want to learn (and invest the time) in it.
Why is Spring and Hibernate a great success? Because I can quickly learn the basic concepts (the "what") and why it will benefit me (the "why") in less than half an hour from a very well-written and comprehensive reference documentation. With Tapestry 3, I literally have to make a serious effort to figure out how it works and what I need to do. Documentation was spotty and I have to dig up pieces of information from various blogs and sites. I ended up buying Howard's book (and eventually Kent's book), but one should not have to buy a book to understand the basic concepts and workings of an open source framework project. It is kind of like shopping for a product, you only get 15 minutes to show your potential buyers whether they want to learn more about it (and eventually buy into it). Most people is NOT going to have a large amount of time in learning the basic "what" and "why" of your product.
Secondly, I invested a LOT of time making Tapestry 3.0 work with other parts of my application. As an architect, I decided to go with Tapestry, Spring, Hibernate, and Acegi (very common pieces). Once again, there was no standard or easy way to get Tapestry to work with all these pieces. I had to really spend the time (my company's time) to figure out how to integrate Tapestry with these projects. When 4.0 came out (with Hivemind) and there was still no clear way as to how it can integrate with Spring or Acegi (or other IOCs), I was not about to jump through hoops again, so I stuck with Tapestry 3.0. I give hearing people saying "Just use Hivemind, you don't need Spring anymore". That's not a good response. For Tapestry to take off, the project needs to recognize that it will have to be able to easily collobrate with other frameworks. Take a look at Spring, one of the reasons for its big success is it does a lot of the integration plumbing for you (integration with Hibernate, JDO, Quartz, etc). Until Howard and his team recognize this and do something about it, it is going to be a hindrance for adoption.
I haven't followed Tapestry 4 or 5, but quickly taking a look at it on the web site, I still don't think Howard and his team gets it. The documentation is still non-existent (a 25 page PDF with a fancy cover). No forum (yes, there is a mailing list but I cannot search it). My hope is to see Tapestry team focus on the following with T5:
- Comprehensive and well-written documentation (don't have to be fancy) with every component thoroughly described with examples.
- A forum so people can search and look for help and answers.
- A standard and easy way to integrate with other frameworks (Spring, Acegi, etc).
Until then, I think Tapestry will continue to be a one man show (at least the perception of it) instead of a true vibrant community project.
Ben Wong
|
|
|
Message #227007
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
I like Wicket, but the users are irritating.
I posted a blog item about this. In the process, I looked up Jan De Jonge and found that not only he caused flamewars at two other occasions, but also that to my knowledge he's not part of Wicket's community (whatever vague the concept of an open source community is anyway). This is in line with other degenerated threads which were also started by people without any clear involvement in the community.
|
|
|
Message #227009
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I mostly agree with parent
Why is Spring and Hibernate a great success? Because I can quickly learn the basic concepts (the "what") and why it will benefit me (the "why") in less than half an hour from a very well-written and comprehensive reference documentation. With Tapestry 3, I literally have to make a serious effort to figure out how it works and what I need to do.
Definitely good documentation can make or break a good product. But for me, sometimes I need to read a book to really "get it." Like for spring, I didn't really understand what was so great about IoC until I read enough about it that I had one of those paradigm shifts. In fact, sometimes I hear people saying why product X or approach Y is so good, but I admit I don't understand why (aspect-oriented programming is my most recent paradigm shift). So sometimes there's buzz about something and I often don't understand why and it take more than a few minutes to get me on board. Maybe I am slow, but that's how it is for me.
So if Tapestry 5 were so different that for people to really understand why it is so much better, it might take time for developers to learn why. This makes good documentation all the more important. Sometime you have to teach developers new concepts in order for them to understand why the new product is better.
|
|
|
Message #227011
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I mostly agree with parent
Why is Spring and Hibernate a great success? Because I can quickly learn the basic concepts (the "what") and why it will benefit me (the "why") in less than half an hour from a very well-written and comprehensive reference documentation. With Tapestry 3, I literally have to make a serious effort to figure out how it works and what I need to do.
Definitely good documentation can make or break a good product. But for me, sometimes I need to read a book to really "get it." Like for spring, I didn't really understand what was so great about IoC until I read enough about it that I had one of those paradigm shifts. In fact, sometimes I hear people saying why product X or approach Y is so good, but I admit I don't understand why (aspect-oriented programming is my most recent paradigm shift). So sometimes there's buzz about something and I often don't understand why and it take more than a few minutes to get me on board. Maybe I am slow, but that's how it is for me.
So if Tapestry 5 were so different that for people to really understand why it is so much better, it might take time for developers to learn why. This makes good documentation all the more important. Sometime you have to teach developers new concepts in order for them to understand why the new product is better.
I would agree that a book is good to get the complete picture, but I agree with Ben that the technology should be approachable in 30mins or less.
I try Spring back on '05 with the intent of using just to replace our inhouse factories, but the AOP and Hibernate integration was so easy an natural that this stuff got added also.
In addition, Spring has that awesome "Introduction to the Spring Framework" article posted here that I recommend to new comers. IMO, if after reading that, a person doesn't see the value, believe they never will. That being said, Spring's documentation, IMO, is the best I've ever seen in any OSS, and their forums, exceptional.
Even Hibernate can be up in running in a very short amount of time.
Unfortunately, I find Tapestry a little troubling(if curious), in that two major releases resulted in two major shifts. Spring has been very good about backwards compatibility and I would not want to be on the receiving end of a major rewrite to access new features.
|
|
|
Message #227012
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: My Two Cents - A User Perspective
No forum (yes, there is a mailing list but I cannot search it).
Of course you can search, just look it up on gmane.org. Gmane will allow you to search it or to use the list as a news group - which is pretty close to a forum. Alternatively add it to nabble.com if its not there already - that will allow you to use it as a web forum and search it as well.
|
|
|
Message #227014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I mostly agree with parent
In addition, Spring has that awesome "Introduction to the Spring Framework" article posted here that I recommend to new comers. IMO, if after reading that, a person doesn't see the value, believe they never will.
Oh, man, then a bunch of us slow guys would never have a chance. I see your point, though. but I still haven't read probably the majority of spring's documentation. Maybe it's just that they have documentation that works for whatever level the user desires. In fact, don't they claim something like "use as much as you want?"
Perhaps a lot of this has been a lesson on constructing open source solutions: building the community may be just as important as the product, and that includes good documentation, integration options, forum, etc. Hmm, maybe there's money in "open source solution community building." I imagine a lot of open source leads wouldn't mean out-sourcing the community building and leaving them to focus more on the technology.
|
|
|
Message #227015
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I mostly agree with parent
Unfortunately, I find Tapestry a little troubling(if curious), in that two major releases resulted in two major shifts. Spring has been very good about backwards compatibility and I would not want to be on the receiving end of a major rewrite to access new features.
First, why is it such a big problem to evolve your code and break backwards compatibility? The old versions are supported and very stable arent they? So why would you want to upgrade your old project? The new features are not possible without api breaks, so do you expect no one to ever work on new ideas?
Second, I am really tired of everyone bringing up spring as an example when comparing api evolution to other frameworks. I am an extensive user of spring, and a committer for wicket. And I can tell you (yes this will probably start another flamewar) that spring's code is mostly far simpler then wicket's or tapestry's. Spring, after all, is not a component UI framework. It has very wide breadths, but not much depth. It is this depth in UI frameworks that leads to tight coupling (which is unavoidable and not undesirable to you spring fanboys) that ultimately result in wanting to break API. So try not to compare apples to oranges. Compare spring api evolution to picocontainer, plexus, or hivemind if you want.
|
|
|
Message #227019
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I mostly agree with parent
In addition, Spring has that awesome "Introduction to the Spring Framework" article posted here that I recommend to new comers. IMO, if after reading that, a person doesn't see the value, believe they never will.
Oh, man, then a bunch of us slow guys would never have a chance. I see your point, though. but I still haven't read probably the majority of spring's documentation. Maybe it's just that they have documentation that works for whatever level the user desires. In fact, don't they claim something like "use as much as you want?"
Perhaps a lot of this has been a lesson on constructing open source solutions: building the community may be just as important as the product, and that includes good documentation, integration options, forum, etc. Hmm, maybe there's money in "open source solution community building." I imagine a lot of open source leads wouldn't mean out-sourcing the community building and leaving them to focus more on the technology.
Don't take offense! ;-) I just thought the article was the great intro.
It discussed philosophy. If you don't agree, move on.
It talked about what it integrated with. If you don't use any of that stuff move on.
It listed what it did. If you weren't interested, move on.
If you agree, then hold on! Heck, I even found value in what Spring integrated with. I figured, these are sharp guys. If they like something, say, Quartz, let me give it a look. So far, this has worked out well.
The Dependency injection just sort of "spoke" to me as did the AOP. That stuff seemed to capture complaints that I've had for on the OO front for some time. In fact, I already had my own Dynamic Proxies in place before Spring and just replaced my stuff with theirs.
I still get a lot of value from this group and these dicussions. Pretty much all the current tech that we deployed was discovered here!
|
|
|
Message #227036
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I'm niether a Wicket or Tapestry user
In the process, I looked up Jan De Jonge and found that not only he caused flamewars at two other occasions, but also that to my knowledge he's not part of Wicket's community (whatever vague the concept of an open source community is anyway). This is in line with other degenerated threads which were also started by people without any clear involvement in the community.
Eelco and all others,
For the records I want to make it crystal clear that I niether belong to the Tapestry nor Wicket community. My colleagues and I are developing an in-house web framework. We think we could learn from Wicket and Tapestry's experience and come out with something very beautiful. Because of this I follow these 2 frameworks very closely. I don't and have NEVER used any of these frameworks except some little playing with both.
Just for the record.
Jan de Jonge
|
|
|
Message #227044
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I'm niether a Wicket or Tapestry user
In the process, I looked up Jan De Jonge and found that not only he caused flamewars at two other occasions, but also that to my knowledge he's not part of Wicket's community (whatever vague the concept of an open source community is anyway). This is in line with other degenerated threads which were also started by people without any clear involvement in the community.
Eelco and all others,
For the records I want to make it crystal clear that I niether belong to the Tapestry nor Wicket community. My colleagues and I are developing an in-house web framework. We think we could learn from Wicket and Tapestry's experience and come out with something very beautiful. Because of this I follow these 2 frameworks very closely. I don't and have NEVER used any of these frameworks except some little playing with both.
Just for the record.
Jan de Jonge
Thanks for clearing that up Jan.
|
|
|
Message #227047
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
I've said it before and I'll say it again: the only thing Wicket "took" from Tapestry was that I noticed what a good idea "jwcid" was (although we ultimately decided wicket:id was a lot more readable and XHTML compliant).
I don't know how others may see it, but I find the names and concepts like RequestCycle, Border the same as in Tapestry.
The other totally unnecessary comment in this thread that annoyed me was the post that dissed Wicket design for not creating a DOM.
You got it backwards: I am advocating that the tester and the components should work at the level of DOM on day one, not generating a DOM from bytes. That's what I consider a poor design decision.
It seems to me that while this design decision has a 5 line fix in Wicket that nobody has requested so far, this is probably the reason Tapestry is 17% slower than Wicket in our benchmark.
Untrue. To fix it, your mock container must stop dealing with bytes and work with DOM. This requires much more work than 5 lines.
This statement reflects your lack of understanding on T5. When unit testing in T5 there is no bytes generated. Just DOM. It is a lot faster than generating the bytes and then parsing a DOM out of it (now, do you understand why I consider it a poor design decision?).
I very much agree with Igor that we should not post silly items on feature matrix. I'd say the same thing for benchmarks. We all understand Wicket trades more session use for less state saving and restoring. This leads to lesser demand on CPU and network traffic but more on memory and session replication (affects scalability).
As both you and I resent FUD, I'd suggest that you put this kind of benchmark in a clear context (as Eelco Hillenius has done) whenever you claim Wicket is faster than Tapestry, as others have expressed the same concern in your blog.
Further, it implies that Wicket didn't make a lot of smart design decisions, which - having spent a huge amount of time on the design - I really resent.
I was referring to that single design decision, not the whole Wicket.
|
|
|
Message #227050
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I mostly agree with parent
Unfortunately, I find Tapestry a little troubling(if curious), in that two major releases resulted in two major shifts. Spring has been very good about backwards compatibility and I would not want to be on the receiving end of a major rewrite to access new features.
First, why is it such a big problem to evolve your code and break backwards compatibility? The old versions are supported and very stable arent they? So why would you want to upgrade your old project? The new features are not possible without api breaks, so do you expect no one to ever work on new ideas?
Second, I am really tired of everyone bringing up spring as an example when comparing api evolution to other frameworks. I am an extensive user of spring, and a committer for wicket. And I can tell you (yes this will probably start another flamewar) that spring's code is mostly far simpler then wicket's or tapestry's. Spring, after all, is not a component UI framework. It has very wide breadths, but not much depth. It is this depth in UI frameworks that leads to tight coupling (which is unavoidable and not undesirable to you spring fanboys) that ultimately result in wanting to break API. So try not to compare apples to oranges. Compare spring api evolution to picocontainer, plexus, or hivemind if you want.
Look, I believe that I can reasonably compare Tapestry 3 to 4 to 5. 3 major releases and 3 major breaks.
Plenty of people, myself included, have issues with that. If your excuse is that Spring, which does far more, is simpler and thus can support previous versions and Tapestry cannot...well...clearly Tapestry is not the tool for me.
Your kneejerk reaction not withstanding.
I would argue that this is a pretty significant barrier of entry. I wouldn't have the confidence to risk my reputation(or my company's) based on this history.
|
|
|
Message #227055
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
I don't know how others may see it, but I find the names and concepts like RequestCycle, Border the same as in Tapestry.
And yet I came to those conclusions independent of Tapestry. If you go back and look at the source code of Wicket 0.9a, I initially decided to avoid having a container object for request-related objects. It was only after a considerable amount of work in a completely different direction that I decided I needed a container like JSF and Tapestry. I decided RequestCycle was the best name for it not because Tapestry used that name, but because it actually accurately names the object. Imagine that! And the idea of a Border is something that Tapestry actually "stole" from Swing (which I worked on). Furthermore, Wicket programmers don't really use borders anymore because Wicket supports direct object oriented markup inheritance. This whole idea that Wicket is a Tapestry clone is purely in your head and I wish you'd stop repeating it!
|
|
|
Message #227056
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
...Furthermore, Wicket programmers don't really use borders anymore because Wicket supports direct object oriented markup inheritance. This whole idea that Wicket is a Tapestry clone is purely in your head and I wish you'd stop repeating it!
Blah blah blah Chris....Who cares? Go to a sticky wicket thread. Your babble is annoying.
|
|
|
Message #227063
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry 5.0.1 Preview Release Now Available
Congradulation's Howard good to see you still pushing the state of the art.
regards Malcolm Edgar
|
|
|
Message #227064
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
And yet I came to those conclusions independent of Tapestry. If you go back and look at the source code of Wicket 0.9a, I initially decided to avoid having a container object for request-related objects. It was only after a considerable amount of work in a completely different direction that I decided I needed a container like JSF and Tapestry. I decided RequestCycle was the best name for it not because Tapestry used that name, but because it actually accurately names the object. Imagine that!
When you were trying to find a name for it, did you already know about the RequestCycle in Tapestry?
Here are some things in Wicket are really similar or revised versions of those in Tapestry: the <wicket:remove> tag, IComponentResolver.
And the idea of a Border is something that Tapestry actually "stole" from Swing (which I worked on).
I am not sure if I am understanding this. The Border class in Swing is just a box decorating a panel. The major twist in the Border concept in Tapestry (and Wicket) is that it renders its body somewhere in its template.
|
|
|
Message #227071
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
And yet I came to those conclusions independent of Tapestry. If you go back and look at the source code of Wicket 0.9a, I initially decided to avoid having a container object for request-related objects. It was only after a considerable amount of work in a completely different direction that I decided I needed a container like JSF and Tapestry. I decided RequestCycle was the best name for it not because Tapestry used that name, but because it actually accurately names the object. Imagine that!
When you were trying to find a name for it, did you already know about the RequestCycle in Tapestry?
Here are some things in Wicket are really similar or revised versions of those in Tapestry: the <wicket:remove> tag, IComponentResolver.
And the idea of a Border is something that Tapestry actually "stole" from Swing (which I worked on).
I am not sure if I am understanding this. The Border class in Swing is just a box decorating a panel. The major twist in the Border concept in Tapestry (and Wicket) is that it renders its body somewhere in its template.
Hello, I am learning nothing about either Tapestry or Wicket from reading posts like this...
|
|
|
Message #227073
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TApestry 5 contrib packages?
Does anybody have an idea (perhaps Howard does) when the components from the contrib package are going to be available for Tapestry 5? I'm particularly interested in Table component.
|
|
|
Message #227080
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
And yet I came to those conclusions independent of Tapestry. If you go back and look at the source code of Wicket 0.9a, I initially decided to avoid having a container object for request-related objects. It was only after a considerable amount of work in a completely different direction that I decided I needed a container like JSF and Tapestry. I decided RequestCycle was the best name for it not because Tapestry used that name, but because it actually accurately names the object. Imagine that!
When you were trying to find a name for it, did you already know about the RequestCycle in Tapestry?
Here are some things in Wicket are really similar or revised versions of those in Tapestry: the <wicket:remove> tag, IComponentResolver.
And the idea of a Border is something that Tapestry actually "stole" from Swing (which I worked on).
I am not sure if I am understanding this. The Border class in Swing is just a box decorating a panel. The major twist in the Border concept in Tapestry (and Wicket) is that it renders its body somewhere in its template.
Kent,
Don't be afraid, the investment you've made (or going to make) in upgrading your Tapestry book to v5 is not (yet) futile. From the way you aggressively attack any comment against Tapestry I smell some FUD on you.
|
|
|
Message #227084
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I mostly agree with parent
Unfortunately, I find Tapestry a little troubling(if curious), in that two major releases resulted in two major shifts. Spring has been very good about backwards compatibility and I would not want to be on the receiving end of a major rewrite to access new features.
First, why is it such a big problem to evolve your code and break backwards compatibility? The old versions are supported and very stable arent they? So why would you want to upgrade your old project? The new features are not possible without api breaks, so do you expect no one to ever work on new ideas?
Second, I am really tired of everyone bringing up spring as an example when comparing api evolution to other frameworks. I am an extensive user of spring, and a committer for wicket. And I can tell you (yes this will probably start another flamewar) that spring's code is mostly far simpler then wicket's or tapestry's. Spring, after all, is not a component UI framework. It has very wide breadths, but not much depth. It is this depth in UI frameworks that leads to tight coupling (which is unavoidable and not undesirable to you spring fanboys) that ultimately result in wanting to break API. So try not to compare apples to oranges. Compare spring api evolution to picocontainer, plexus, or hivemind if you want.
One more thing, according to what I read, *this* version is supposed to prevent future backwards compatability issues, so it seems that it is more an issue of design and implementation than your belief that Tapestry is somehow more complex.
|
|
|
Message #227085
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TApestry 5 contrib packages?
Does anybody have an idea (perhaps Howard does) when the components from the contrib package are going to be available for Tapestry 5? I'm particularly interested in Table component.
Working on the Grid (a streamlined Table) right now.
Thinking about the new JavaScript approach, and then we'll recreate the Palette (probably with drag & drop) and all the rest.
|
|
|
Message #227086
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: I really don't understand
And yet I came to those conclusions independent of Tapestry. If you go back and look at the source code of Wicket 0.9a, I initially decided to avoid having a container object for request-related objects. It was only after a considerable amount of work in a completely different direction that I decided I needed a container like JSF and Tapestry. I decided RequestCycle was the best name for it not because Tapestry used that name, but because it actually accurately names the object. Imagine that!
When you were trying to find a name for it, did you already know about the RequestCycle in Tapestry?
Here are some things in Wicket are really similar or revised versions of those in Tapestry: the <wicket:remove> tag, IComponentResolver.
And the idea of a Border is something that Tapestry actually "stole" from Swing (which I worked on).
I am not sure if I am understanding this. The Border class in Swing is just a box decorating a panel. The major twist in the Border concept in Tapestry (and Wicket) is that it renders its body somewhere in its template.
And these trivial and superficial commonalities for obvious concepts represent a "cloning" of Tapestry? A couple of small naming coincidences for broadly used and quite obvious concepts? (BTW, I don't even know what IComponentResolver does in Tapestry)
I mean, "Wicket is a clone of Tapestry" is such a wonderful piece of criticism to receive from someone who didn't even bother to learn that Wicket components are simple Java objects with constructors! Yes, type safety in web frameworks all an invention of Tapestry! Or is Tapestry now "cloning" Wicket?
The problem I have is not that Tapestry was not "there first" or that Wicket owes /nothing/ to Tapestry. Wicket was not created in a vacuum and I don't mind owing something to predecessor frameworks. But I do have a real problem with the use of the word "clone"
CLONE (N) - (2) A person or thing regarded as identical to another. (3) A microcomputer designed to simulate exactly the operation of another, typically more expensive, model.
with respect to Wicket because it is DISRESPECTFUL FUD. Wicket has a very different design (which the Tapestry crowd criticizes when it's convenient and bashes as cloning when its not) and calling Wicket a "clone" is leading people to think that Wicket is literally a copy or fork of Tapestry when actually all of the really key design decisions (managed vs. unmanaged, unstateful vs. stateful, xml vs. java, ognl vs. pure html templates, binding files vs. java constructors, and so on) couldn't really be MORE different. The real losers here, in case you've forgotten them entirely, are the FRAMEWORK USERS out there who are going to be completely misled.
|
|
|
Message #227109
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TApestry 5 contrib packages?
Thanks or the prompt answer, Howard :)
I am glad that the work has already started. So, are we talking about a few days, a week, a month? I am not asking for a specific release date, but when are you expecting that these components will be available (approximately, of course)?
Thanks for the excellent framework, I almost cannot wait to switch to T5, the things that I've seen looks promising :)
|
|
|
Message #227142
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Clone or not
Jonathan,
I dont think this issue is worth even a fraction of the enthusiasm you seem to put into it. Anyone who has had a superficial look at both frameworks has most likely found that they both have significant merits, and that there are obvious differences. The similarities can easily be explained by the fact that they solve the same problem in the same (event-driven, object-oriented) way. And if any framework deserves recognition as the forefather of this approach, it is venerable WebObjects from Apple (formerly NeXT).
Christian
|
|
|
Message #227176
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tapestry's fate already sealed???
Actually combination of the JSF + Faceless + Seam is not equal with Tapestry, you can't compare oranges and apples, they overlap indeed, but not fully there are some parts where Tapestry fail (obviously Hivemind integration, which is quite a good decision in my opinion because not everyone is using Hibernate, and Web framework should do a Web job :) ) but there are some places where JSF + ... fail.
Basically we are using Tapestry and JSF simultaneously on different project at the same time and same developers are working on Tap and on JSF.
What we can't really understand is how minority of people (Howard and team) can be so _much_ smarter than respected group of brilliant minds, of let me name them expects(!) - JCP expert group. There are so much tiny details that made a life of Tap project simpler than the same things in JSF project.
Our congratulation Howard! We are very exited by your work!
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
