A glimpse of Wicket 1.4 and Tapestry 5

Home

News: A glimpse of Wicket 1.4 and Tapestry 5

  1. A glimpse of Wicket 1.4 and Tapestry 5 (47 messages)

    It has been a long time since Struts first showed up and filled in the Java web framework space. Many people nowadays are still using Struts which mainly because of legacy and investments reasons. But more people are moving away towards component based frameworks these days. JSF has got to be the most popular component framework out there, considering it is supported by many vendors and being itself as a standard from JCP. I’m not going to talk about JSF nor the up and coming release of JSF 2.0, instead I’m going to write about the other two popular component based web framework fostered by Apache: Wicket and Tapestry 5 In the near future there will be two interesting component framework that will be released by Apache Foundation: Wicket 1.4 and Tapestry 5 which I will elaborate in a very short few moment. Alot of people out there are asking, which one is better out of these two? First of all, we need to be on the same platform before continuing any further. This blog entry is not intended to be a web framework bashing discussion, but just to give insights for people who are curious about the difference between these two frameworks. The features that I will discuss will only be limited to the usage of the two frameworks. Build Tool This might not be important for some people, but you might take it into consideration. Both frameworks uses maven as its build tool. Maven really helps your development stage especially when getting the latest release of the framework. This is extremely important considering both frameworks are in heavy development and they have SNAPSHOTS on the maven repository. Okay now that you know that both frameworks uses maven as its build tool, let’s get deeper and see how do we use these frameworks. Configuration Both frameworks believes that configurations should take small portion in xml, infact web.xml is the only xml file you will require to write down your configurations. You won’t find any other xml configuration for setting which page to render after one action is called, etc. Both frameworks took the same philosophy that web framework should be responsible for generating the URL and knowing which page to be rendered afterwards, instead of throwing the responsibility to the developers by telling them to configure it themselves on the xml configuration. Read the rest here: http://joshuajava.wordpress.com/2008/09/11/a-glimpse-of-wicket-14-and-tapestry-5/

    Threaded Messages (47)

  2. I think Joshua did a good job comparing the two frameworks although this isn't a very in depth analyses as they both are very complete and also complex frameworks. I'd just like to point out a feature that he left out and that's extensibility. Although both frameworks make it quite easy to extend framework features i think Tapestry really has the edge in that department. Because it uses it's own IOC container it makes configuring / extending almost every aspect of the framework really easy.
  3. Re: A glimpse of Wicket 1.4 and Tapestry 5[ Go to top ]

    I'd just like to point out a feature that he left out and that's extensibility. Although both frameworks make it quite easy to extend framework features i think Tapestry really has the edge in that department.
    I'd disagree. I won't disagree with your assertion that Tapestry is easily extensible (I wouldn't know). I'd just like to point out that Wicket is really, really simple to extend, create components etc. Creating your own panels, ajaxified components etc couldn't be easier. Also Wicket's separation of concerns into Components, Behaviors etc makes it really easy to compose new things, add new functionality to existing etc. The fact that it is all done in pure java code rather than having to learn new markup languages, config formats etc only eases it further. I think the amount of third party Components and frameworks that build on top of Wicket goes to show just how extensible it is. I think which framework is "more extensible" probably boils down to which one you are more familiar with.
  4. Re: A glimpse of Wicket 1.4 and Tapestry 5[ Go to top ]

    Wille, when i talk about extensibility i'm not talking about the creating pages or components. I'm talking extending the framework itself. Because the framework itself is built using an IOC container it's very easy to extend /configure / replace almost every aspect of it. So if you desire you change the way Tapestry works in a very simple and easy way. As we know every application has different requirements and it's impossible for a framework to predict them all. So it's really important for a framework no impose as little as possible on the developer.
  5. Wille,
    when i talk about extensibility i'm not talking about the creating pages or components. I'm talking extending the framework itself. Because the framework itself is built using an IOC container it's very easy to extend /configure / replace almost every aspect of it. So if you desire you change the way Tapestry works in a very simple and easy way.

    As we know every application has different requirements and it's impossible for a framework to predict them all. So it's really important for a framework no impose as little as possible on the developer.
    Wicket is very extensible here as well. Most things can be changed by simply overriding a factory method in the application, and if you want, you can go as far as to change how the whole framework works, including how it parses tags etc.
  6. I think Joshua did a good job comparing the two frameworks although this isn't a very in depth analyses as they both are very complete and also complex frameworks.

    I'd just like to point out a feature that he left out and that's extensibility. Although both frameworks make it quite easy to extend framework features i think Tapestry really has the edge in that department. Because it uses it's own IOC container it makes configuring / extending almost every aspect of the framework really easy.
    Hi Hugo Thanks for the positive response. You're right that it's not deep enough because it was intended for beginner who haven't used both wicket and tapestry before. As the title says, just a glimpse to get the idea about the usage of both Wicket and Tapestry. :-)
  7. Difference between these frameworks[ Go to top ]

    There is one difference between these two frameworks that influenced me to choose Wicket for a particular project. Please let me know if I am missing something in the following assessment. I have a project that has a requirement to allow clients to override and extend pages and/or individual components on a page. With Wicket, this is relatively easy since you handle all of the component creation yourself. You can simply use a factory to create all of your components and pages and then allow the client to extend that factory where necessary. I found no easy way to do this in Tapestry 5, since it creates and manages component objects for you. It did not appear as if the strategy for creating components for injection into a page was easily customized. Am I missing something? (The component field in my page class is typed MyPanel, but my client wants to extend it and inject MyExtendedPanel instead. Can I give him the ability to do this?) Two great frameworks, one subtle difference that can be very important in unusual cases.
  8. Re: Difference between these frameworks[ Go to top ]

    Matt, it does seem that that type on functionally might be more difficult to achieve with Tapestry because of it's more static nature. Still, and this is just from the top of my head, i think you might be able to implement such a solution using the block concept in Tapestry. But the bottom line is, yes i think in your case wicket might fit your needs better than Tapestry. Isn't choice great? :o)
  9. Geez, Another Stupid thread comparing Wicket and Tapestry. Cant we get along?, Cant compare apple to oranges, you will start a flamewar with this thread, really!. It is pointless to still compare Wicket and Tapestry, period. Note: I'm fan of Tapestry but the world is not just turned now into component based it is going more forward to the RIA era. Better lets talk about JavaFX, Flex/Flash and Silverlight, how it compare?, The Wicket vs Tapestry is getting too old. The web.xml configuration, who cares? really, I just care the framework, the container should do the configuration trick and not put me to do more job to configure the container. Regards.
  10. Another thing the JEE spec for version 6 should put JavaFX as the view component instead of JSF, Nobody likes that thing(JSF) even at version 2, If Sun is betting in the RIA space should promote JavaFX as a view component for the JEE 6 spec. Because I see very strong competition from Flex on this field and Silverlight it is entering very strong too. For example my JavaFX applet doesnt work in Firefox 3 in my intel mac but Silverlight 2 it is right now working good in Firefox 3 in my intel mac, dam. Sun should put more resource to get JavaFX working on all platforms and browsers and integrate it with JEE spec for the view part and drop JSF because the thing still stinks even just change it cloths, it have to be replaced completely for something newer and more capable technology and I think JavaFX could be that. Im agree for some projects we still need Wicket, Tapestry, Spring MVC and Struts but please stop the Wicket vs Tapestry its pointless. Reagrds.
  11. "Im agree for some projects we still need Wicket, Tapestry, Spring MVC and Struts but please stop the Wicket vs Tapestry its pointless." So because you're only interested in Flex and Silverlight it's a pointless discussion? I hate to tell you this but there's armies of Java developers out there who don't use Flex or Silverlight at all. In addition, I won't even allow Flash or Silverlight to run in my browser because websites built with that technology almost universally suck (*hugs noscript*).
  12. Another thing the JEE spec for version 6 should put JavaFX as the view component instead of JSF, Nobody likes that thing(JSF) even at version 2, If Sun is betting in the RIA space should promote JavaFX as a view component for the JEE 6 spec. Because I see very strong competition from Flex on this field and Silverlight it is entering very strong too.

    For example my JavaFX applet doesnt work in Firefox 3 in my intel mac but Silverlight 2 it is right now working good in Firefox 3 in my intel mac, dam. Sun should put more resource to get JavaFX working on all platforms and browsers and integrate it with JEE spec for the view part and drop JSF because the thing still stinks even just change it cloths, it have to be replaced completely for something newer and more capable technology and I think JavaFX could be that.

    Im agree for some projects we still need Wicket, Tapestry, Spring MVC and Struts but please stop the Wicket vs Tapestry its pointless.

    Reagrds.
    No-one started flaming here. The Server Side is for technical discussions, which is exactly what this is. As long as such discussions are based on facts and clear reasoning, you can't have enough of them :-) If you want an article on JavaFX, why not write one? This article just points to a blog, and it could point to yours in the same fashion.
  13. You are right, Thanks Eelco.
  14. Nobody likes that thing(JSF) even at version 2
    It's funny how this type of hyperbole is common on non-JSF web framework threads, but you don't often see Wicket or Tapestry bashing on JSF threads. Do you have an inferiority complex or something? I just came back from JSFOne, and I assure you, quite a few people like that JSF thing.
  15. but you don't often see Wicket or Tapestry bashing on JSF threads.
    That's right. Even on JSF threads there is only JSF bashing, while praising an alternative framework there was labelled noise by some people who are obsessed with "standard" and refuse to learn from others.
  16. @Ian the more soon JSF die the better for the Java enterprise, I see JSF as the analog of the EJB2 era. We don't need JSF even at the JEE 6 spec, There is lots of options to use for webb application development, component based, Action based, RIA or not RIA as Wicket,Tapestry, ZK, GWT, or even Spring MVC is much better solution than JSF. Everything that SUN cook and go wild it sucks, I really hope JavaFX succeed but I doubt it. JSF it is a cheap copy of ASP.net, I liked SUN in the nineties and I thank them for Java but after Java has not been innovation from them only failing projects. JSF spec is driven by the JCP, cool there are some interesting things in there but I don't believe in committees, I believe in the Open source Model as all the frameworks I commented in here, Opensource rocks. Regards.
  17. Nobody likes that thing(JSF) even at version 2

    It's funny how this type of hyperbole is common on non-JSF web framework threads, but you don't often see Wicket or Tapestry bashing on JSF threads.

    Do you have an inferiority complex or something?

    I just came back from JSFOne, and I assure you, quite a few people like that JSF thing.
    Funny thing on the original comment is, that JSF2 is not even finalized nor are the specs, probably the original poster has not even read the parts of the specs which have been released yet ;-)
  18. @Warner Punz, I have read the spec of JSF2 and let me tell you it is a Fiasco, Why after 4 years they get JSF how should be and I'll tell you still not that great the JSF2 spec. Why the JCP need to define a web layer as JSF?, I don't want it, The web layer is already define agnostic as the JSP/Sevlets spec so the Web frameworks authors develop and the Java community have choices as Wicket , Tapestry, Spring MVC, ZK, GWT etc etc etc etc. They are doing great defining the App server spec, But why I will drink the kool-aid of JSF, JPA or even EJB, Me I want to use Hibernate, Spring and Tapestry. Not their standard, I don't see this time JEE as standard, I see it as a big FAIL. Note: EJB 3.1 looks interesting and maybe it have a future, but JSF2 it is the same beast but with the glove. Regards.
  19. @Warner Punz, I have read the spec of JSF2 and let me tell you it is a Fiasco
    ROTFL. It was out Early Draft Review 1 of JSF2.0. There, they didn't address the most import issues of JSF1.x, and they are still working on them: -new component model -composition capabilities -annotations -conventions over configurations -new scopes -nice support for GET etc, etc... How can be a fiasco?
  20. How is a fiasco you ask?, After 4 years they got how JSF supposed should be. It is a joke really what they are doing, I better ROTFL for that. I can get all that wonderful features you are listing NOW with Tapestry or Wicket. So my question is why I need JSF? because is a standard c'mon we all know it is a FAIL a Marketing from SUN from the past to compete with ASP.net. Really ask 100 java developers maybe the 5% think JSF is ok but the other 95% think JSF sucks. Regards,
  21. How is a fiasco you ask?, After 4 years they got how JSF supposed should be. It is a joke really what they are doing, I better ROTFL for that.

    I can get all that wonderful features you are listing NOW with Tapestry or Wicket. So my question is why I need JSF? because is a standard c'mon we all know it is a FAIL a Marketing from SUN from the past to compete with ASP.net. Really ask 100 java developers maybe the 5% think JSF is ok but the other 95% think JSF sucks.

    Regards,
    I see that, in your opinion, JSF2.0 is a fiasco whatever they are going to implement. That's quite ridicolous. You don't know what they are implementing and you don't know how they are implementing many of its feautre, but it's a fiasco. ROTFL again. Then JSF can't be a fiasco: it has the most powerfull echosystem around it (component libraries, framework, etc). So maybe not everything was wrong, starting from the idea of being a standard.
  22. Well, Good luck, I hope JSF2 success because it is part of the Java ecosystem but as JavaFX and everything come from SUN I doubt it will get adopted as supposed to be. I'm tired of this standard terms and committees, I better I retired of this forum because is pointless to talk or "bash" a technology that it doesn't bring NOTHING only brings pain in the neck. Peace.
  23. So my question is why I need JSF? because is a standard c'mon we all know it is a FAIL a Marketing from SUN from the past to compete with ASP.net. Really ask 100 java developers maybe the 5% think JSF is ok but the other 95% think JSF sucks.

    Regards,
    This is the type of specious thinking that I was referring to in my first comment, alpha. Where did you get those statistics? Do you sincerely expect us to believe them? Again, nobody is bashing Wicket or Tapestry here, I'm just asking why do you feel the need to attack JSF. It's humorous actually, how you continue to bash JSF even after someone points it out to you. Any framework is subject to criticism, and good frameworks evolve over time to address limitations pointed out by users. It's one thing to attack a framework that has failed to mature at version 6.0, but even at version 2.0 JSF is still young. It is precisely because JSF is a standard and was designed by an expert group in the JCP that it will continue to improve over time in a consistent way that meets the needs of a large developer community across many industry sectors. Please refrain from bashing other frameworks to try to make your framework look good. This is juvenile behavior and makes you look silly for trying to defend your purchase.
  24. @Warner Punz, I have read the spec of JSF2 and let me tell you it is a Fiasco
    Well there only has been a first version which adressed a few things, the big issues have not been touched. Ok lets sum things up the first public review version just mainly touched, the ajax paths, which looked pretty sane to me, the basically defined standardized (W3C) compliant namespaces on how to handle ajax on the server side. They introduced build stages (which rails also has) which means you can define development, production and the rest of the system adheres pretty much to it. They also introduced a resource format which is rather similar to mechanisms spring has, Weblets do, or Shale remoting does, it looks like they took the best concepts. Can you elaborate more what in the currently publicly released spec is so bad? As someone else said the biggest points have not been specified the http get support, simplified component model etc... That will come with future spec previews!
  25. Geez, Another Stupid thread comparing Wicket and Tapestry.
    Cant we get along?, Cant compare apple to oranges, you will start a flamewar with this thread, really!
    Apples to oranges? If the article were comparing MySQL to Wicket, or Hadoop to Tapestry, I could see your point... As is, I don't see a problem with this sort of comparison. Flamewar? The article is very mild. In fact, looking over the comments, the only one which even registers on the flame-o-meter at all is yours (viz. "stupid" above). Er, and my comment, now that I've responded to yours ;-)
  26. @Daniel Gredler my comment was for the author of the article I dont even know why are you responding this to me, maybe you are flaming on more the thread?, And I see a problem in this comparison cause always this comparison ends with trolls and hurting the Tapestry and Wicket communities in here on The Serverside, Dont you read often the ServerSide?. @Mark Stock Im interested in JavaFX, not Flex or Silverlight. Those compete with JavaFX and I would like to discuss how stack JavaFX against to the other technologies and try to help to improve the Java platform and JavaFX, you didnt read all my comments?.
  27. Geez, Another Stupid thread comparing Wicket and Tapestry.

    Cant we get along?, Cant compare apple to oranges, you will start a flamewar with this thread, really!.

    It is pointless to still compare Wicket and Tapestry, period.
    I have no intention to start a flamewar. Just to give a brief insights for those who are curious about the difference of T5 and Wicket. From the overview, we can conclude that T5 suited for those who like declarative programming model, while Wicket provides an imperative programming model. :-)
  28. but the world is not just turned now into component based it is going more forward to the RIA era. Better lets talk about JavaFX, Flex/Flash and Silverlight, how it compare?, The Wicket vs Tapestry is getting too old.
    +1
  29. "In addition, I won't even allow Flash or Silverlight to run in my browser because websites built with that technology almost universally suck (*hugs noscript*)." Everybody will agree that rich platforms make our web-apps look nicer, and usually run smoother. If you visit flex app's that 'suck' it's because of poor development, because I can say from first hand experience it's a great platform. However, my reply to the original quote is, you can't universally develop in these platforms. You would be disadvantaged to develop any e-commerce applications on a platform that requires a browser plug-in. Although Flash player has a ~90% adoption rate, and there is no reason to think Silverlight wont achieve that also, it prevents a lot of people from using their office or school computers from making purchases, because desktop support generally block browser plug-ins. We only develop in Flex for registered users of our service, and we get dozens of support calls each week from people who can't see the application or log in. 9 times out of 10, that is because they are either college students in a computer lab, or sitting at their work computer. (The tenth time, somebody is using Opera on an iPhone or still using WebTV)
  30. @Michael Pasacrita actually you brought something interesting, It is still working the Action based and Component based frameworks for that market you are describing. So for controlled environments do you think is better to use for a web app a traditional web framework or go straight to the RIA approach?. For not controlled environment as you describe I'm agree is difficult because the plugin architecture nature as you said is problematic with the users. Regards.
  31. Or maybe use an Ajax based framework as ZK, GWT or Echo for a not controlled environment web app.
  32. "Everybody will agree that rich platforms make our web-apps look nicer, and usually run smoother." I completely disagree. The people who create these sites are generally so impressed with their cleverness that I spend most of my time trying to figure out their UI (which varies wildly from site to site) and waiting for their lame animations to complete. The completely distract me from what I'm trying to do (which is either get information or buy something). The only time I want to see animation is when I'm watching a cartoon or when I explicitly indicate that I would like to see an animation of some "thing" in operation to get a better idea of how it works. Otherwise, it has no place other than to annoy and waste bandwidth. The DVD makers uses these same rich interfaces which serve only to waste my time. Why do I need a rich interface to say that the movie should play or to see the special features? Blu-ray is following in DVD's footsteps. HDDVD was great because they had a simple consistent menu that was fast and didn't waste time with lots of useless animations. Finally, I have yet to use a Flash site where I felt that the RIA that was used actually enhanced my experience. If you'd like to give me examples of sites where they actually do provide something that I cannot get via good ol' HTML, DHTML, or AJAX, then please let me know. However, I seriously doubt you can. Anyway, sorry for sidetracking the discussion.
  33. "Everybody will agree that rich platforms make our web-apps look nicer, and usually run smoother." -Myself "I completely disagree. The people who create these sites are generally so impressed with their cleverness that I spend most of my time trying to figure out their UI (which varies wildly from site to site) and waiting for their lame animations to complete." -Marc Stock This is bad development, not the fault of the platform. Graphical widget overuse can occur with AJAX frameworks, such as Backbase, echo2, DOJO, or GWT also. I'm also not solely advocating the Flex platform, I'm advocating RIA frameworks in general. I do feel that Flex development time is much shorter than several of these other options. Without these RIA platforms, it is now impractical to build components with functionality such as sortable/resizable data-grids, drag and drop components, and other gems these frameworks afford us, into a DHTML page. As technology advances, so do requirements. The expectations of what we should do are often confused with what we can do, and the KISS principal goes out the door. That doesn't mean the RIA framework is a bad thing.
  34. I do feel that Flex development time is much shorter than several of these other options
    No way. I've been using Wicket and Flex side-by-side for a while now, and I don't find Flex to be a huge boost in productivity. Some things can be done quickly, especially with the Flex Eclipse editor, which works very well, but for a whole range of things, especially when working with a complex data model, I find Wicket easier and quicker to work with.
    Without these RIA platforms, it is now impractical to build components with functionality such as sortable/resizable data-grids, drag and drop components, and other gems these frameworks afford us, into a DHTML page.
    Yeah, things like dragging and dropping is why we're using Flex alongside Wicket (and I wonder why more people can't do this rather than always have to make everything the ultimate framework battle). Personally, I could see us use YUI instead as well, but it is nice to use a framework with strong tooling and static typing, so I'd probably still prefer Flex for such fancy things.
  35. Agree completely![ Go to top ]

    "Everybody will agree that rich platforms make our web-apps look nicer, and usually run smoother."

    I completely disagree. The people who create these sites are generally so impressed with their cleverness that I spend most of my time trying to figure out their UI (which varies wildly from site to site) and waiting for their lame animations to complete. The completely distract me from what I'm trying to do (which is either get information or buy something). The only time I want to see animation is when I'm watching a cartoon or when I explicitly indicate that I would like to see an animation of some "thing" in operation to get a better idea of how it works. Otherwise, it has no place other than to annoy and waste bandwidth. The DVD makers uses these same rich interfaces which serve only to waste my time. Why do I need a rich interface to say that the movie should play or to see the special features? Blu-ray is following in DVD's footsteps. HDDVD was great because they had a simple consistent menu that was fast and didn't waste time with lots of useless animations.

    Finally, I have yet to use a Flash site where I felt that the RIA that was used actually enhanced my experience. If you'd like to give me examples of sites where they actually do provide something that I cannot get via good ol' HTML, DHTML, or AJAX, then please let me know. However, I seriously doubt you can.

    Anyway, sorry for sidetracking the discussion.
    Thats exactly how I feel about Flash web sites. Even more annoying are their increased load times. Worse are the web sites that use flash to implement their menus, can't even navigate the damn thing with no Flash...
  36. Re: Agree completely![ Go to top ]



    Thats exactly how I feel about Flash web sites. Even more annoying are their increased load times. Worse are the web sites that use flash to implement their menus, can't even navigate the damn thing with no Flash... Problem with dhtml is that first of all people still demand that IE6 is supported which means you have to prepare for hell because you have to support standards compliants browsers as well besides that utter gutter which never should have seen the light of say, and you add a load of complexity outside of still having to support ie6. Flash is the easy escape route for many, it simply works as advertised without having to go through i6/dhtml/incompatible dom hell.
  37. Re: Agree completely![ Go to top ]



    Thats exactly how I feel about Flash web sites. Even more annoying are their increased load times. Worse are the web sites that use flash to implement their menus, can't even navigate the damn thing with no Flash...


    Problem with dhtml is that first of all people still demand that IE6 is supported which means you have to prepare for hell because you have to support standards compliants browsers as well besides that utter gutter which never should have seen the light of say, and you add a load of complexity outside of still having to support ie6.

    Flash is the easy escape route for many, it simply works as advertised without having to go through i6/dhtml/incompatible dom hell. You are 100% right: for the developer this is a good solution. For the user it could be inconvenient.
  38. Re: A glimpse of Wicket 1.4 and Tapestry 5[ Go to top ]

    Our company decided to use Tapestry 5 more than a year ago. I had used Wicket previous to that and found Tapestry quite hard to work with. The team managed to get the application finished and deployed, but maintaining the site feels difficult. Maybe we just don't 'get' Tapestry 5? In the beginning there was no ajax support built-in, so we rolled our own, and had to deal with all the different browsers etc. Then along came Zones, and tried to use them as it was the Tapestry way, but they are very limited. Only allowing one 'Zone' to be updated. The structure of our pages already needed several 'Zones' to be updated with a single request. This was all hard to test. A several months ago we had another web application project come up, which would reuse some of the functionality of the original site. We had a rough estimate of how long it would take us with Tapestry 5, sharing existing components etc (2 months, though that might have been optimistic). We decided to give Wicket a go for a week to see what the team thought of the framework. Of our team of 4 people only I had used Wicket before. We had been pushing Test Driven Development for a while, and made the most of it with WicketTester. By the end of the week the team really started to enjoy Wicket, and we decided to push on. The ability to 'test' ajax (well, being able to test that the correct behaviour in terms of a panel or model being updated) excited everyone. We finished the project on time and with something like 740 tests covering 96% of the code. We could happily refactor the code with confidence. We could even test that the resource keys were all defined, by making our JUnit tests fail. We only needed to write some custom javascript for one component, everything else was provided out of the box by Wicket. In terms of project layout it was nice having the markup in the same folder as the java class in Wicket. The Tapestry project has the .tml in the resources, which means you have to navigate down another folder structure unless you use something like Loom in Eclipse to switch to it for you. The Tapestry separation of xyz.pages and xyz.components is also a bit annoying. We had panels in Wicket that we use with an Account, so it was quite nice having the Account properties, pages and panels in the same package. In Tapestry you have the xyz.pages.account.EditAccount page, but the related components would live in xyz.components.account.AccountDetails for example. We really liked how the IDE would help in Wicket with overriding methods or even finding the type of Link or panel you want to use. Tapestry's use of annotations really makes creating pages/components feel like a you are mixing unicorns and fairies together. Find the right combination of @Inject, @Persist and @Component and the page will spring into life. It can catch you out too. We fell into a trap in Tapestry where we declared something like private List myList=new ArrayList() If you do this in Tapestry 5, the page is pooled and this field is shared with everyone. So you have to remember to only declare your variable, but you shouldn't assign it inline. It feels like you have to keep lazily initialising fields or checking for null or only initialise them in a method with @SetupRender or @PrepareForm or @OnActivate or something. In Wicket, you can initialise your variables in the constructor or inline and forget about it. Tapestry 5 seemed to let us down in refactoring. There are 2 ways of creating/using a component. You can call them directly in the template eg Which is great except when you want to find out which pages are using your component called 'mycomponent'. so refactoring 'mycomponent', you might add a new required parameter and hope your tests exercise this component and tell you it fails. The other way including a reference to it in your Java code eg @Component(id="mycomponent", parameters = { "thing1=someThing", "thing2=${someThingElse}" }) private MyComponent abc in tml:
    If you remember to do this you will at least get a but of help from the IDE that this page references MyComponent, but the parameters are still a bunch of strings so no help there if you need to change the type of your parameters. In Wicket this would be handled as a change to the constructor for your panel or page. I think I have typed enough for the moment, time to get some fresh air. I think those are the main things that struck us in developing with the different frameworks. We are now in the process of trying to mix Wicket/Tapestry so we can migrate the main site to Wicket... page by page. So bow down to the new framework to rule them all: Wapestry... or Twicket... or Wickestry
  39. @Jason Lea, Very good analysis of both frameworks, I just don't like something about Wicket it is that I have to watch out always the hierarchy of components in the HTML, I had many problem with it. I think as the author of this thread or Eelco said Tapestry is a declarative model and Wicket is imperative model, It seems you and your team are more comfortable with the Imperative model so Wicket is for you. Regards.
  40. @Jason Lea, Very good analysis of both frameworks, I just don't like something about Wicket it is that I have to watch out always the hierarchy of components in the HTML, I had many problem with it.

    I think as the author of this thread or Eelco said Tapestry is a declarative model and Wicket is imperative model, It seems you and your team are more comfortable with the Imperative model so Wicket is for you.

    Regards.
    If you're brave, give Lift a look, which is a framework that builds on Scala. It combines the ideas of many frameworks, including Wicket and Tapestry, and Scala lets you program in a more declarative fashion, while still being statically typed. If I had more time, I'd check it out (though I'd take a look at Wicket and Scala together as well).
  41. Scala looks interesting language last time I checked it, it was like 2 years ago. But there is bad press around that people say it is a difficult language I'm not sure I have to try again Scala to get conclusion's but I think Wicket with Scala could be a good solution. Thanks for the info, I will check it out.
  42. Eelco check this link http://marcus-schulte.blogspot.com/2007/06/tapestry-components-in-scala.html The guy did an exercise in Scala with Tapestry and it looks easy enough it remember me Groovy, Also Groovy is great scripting language. Do you think I could use Wicket with Groovy?. Regards.
  43. Eelco never mind I found it, Geez, Im fan of Groovy builders and there is a module WicketBuilder in the Wicket Stuff that is awesome!, I have to try this. This is the link http://wicketstuff.org/confluence/display/STUFFWIKI/WicketBuilder Wicket people should make more press about this because it is really cool stuff. Imagine this with GORM integrated as a full stack it can compete with Grails, And its component based instead of an action based. Regards.
  44. Imagine this with GORM integrated as a full stack it can compete with Grails, And its component based instead of an action based.
    Grails ships with Wicket support. Even more to choose from :-)
  45. Scala looks interesting language last time I checked it, it was like 2 years ago. But there is bad press around that people say it is a difficult language
    Scala is a mixed paradigm language that lets you tackle the same problems in different ways. Choice is good when you're experienced and disciplined, but can easily lead to hard-to-maintain code (as the conceptual surface area is larger). Same goes for the fact that you can create DSLs with it's language constructs; that opens the door for very elegant constructs, but also potentially to a mess when not used with constrain. Scala is probably not the best choice for all projects. But personally I feel that it is the better alternative to many of the dynamic languages people are getting into.
  46. @Any @framework that @requires lots of @annotations doesn't get my @vote... call me a rebel but it's POJOs or nothing for me. I've been using Wicket for @2 @years now and have never once needed to @use @a flaming @annotation and loving it!!! A few years so when I decided to abandon JSP/struts I started looking for many different Java UI technologies: I evaluated *everything* at the time with an open mind, including JSF, Tapestry, Wicket, Echo, Webtools(spl?). I didn't bother with any tools built using non statically typed languages (I like to discover as many bugs as possible at compile time rather than leaving it to my customers to discover many bugs - as full coverage testing is the holy grail of the delusional!! =] ) It was a while back now but memories are: Tapestry - found it a bit painful and couldn't get it working the way I liked. JSF - it seems too awkward and 'stuck in the past'. Like they were trying to appease the JSP/struts junkies but trying to present a new component based world - at the same time. Wicket - as a keen OOer since 1989 Wicket's OO approach really grabbed my attention - it even extended to providing markup inheritance. Via the IComponentResolver interface I can even leave much of the 'page assembly' to the markup creators/designers. That seriously rocks! Generating standard HTML pages pages rendered by wicket are great for SEO (unlike Flash, Silverlight, JavaFX) Echo - Excellent framework for admin screens. You feel like you're writing a Swing app instead of a web app. No SEO possible in Echo screens but as we use them for admin screens where only authenticated access is permitted we don't want those pages indexed by search engines anyway. In the end we chose a combination of Echo/Wicket. Echo for the authenticated administration screens and Wicket for the public facing, main pages of the site.
  47. Re: A glimpse of Wicket 1.4 and Tapestry 5[ Go to top ]

    Jason, Thanks for your detailed comments on your experiences with both of these frameworks. It's great to hear from impartial users with experiences of both! We are currently a Tap4 shop but I've looked with interest at both Tap5 and Wicket for new projects. Regards John Hurst Wellington, New Zealand
  48. A fundamental difference[ Go to top ]

    I have experience with Wicket but little with Tapestry though I have seriously considered its features. (I heard about Tapestry well before Wicket. Then it was Tapestry 4. I tried to study how to use it but found it too hard. Later Wicket features impressed me. http://wicket.apache.org/features.html I tried it. Thanks to "Wicket in Action" and the community and others, I picked it up rather smoothly. This year I tried to look at Tapestry 5 again. Anyway both are great as they help to address the very key issue of re-using dynamic web pages which IMHO is difficult with jsp) I think the following point is worth mentioning. http://chillenious.wordpress.com/2008/06/04/wicket-and-tapestry-compared/ "One big difference ....... is the fact that Tapestry’s component tree is static, whereas Wicket’s is dynamic...." This point is also explained in http://tapestry.apache.org/tapestry5/ from Tapestry's perspective. My modest experience with Wicket is that Wicket does not run noticeably slower. Also Wicket has measures to optimize the holding of session data, like LoadableDetachableModel which implements IModel. I found Wicket's approach (and all the stuff) more attractive. I was migrating part of the existing project to Wicket and new things will begin with it.