Home

News: Apache Wicket 1.3 released

  1. Apache Wicket 1.3 released (70 messages)

    Starting the new year with a bang, the Wicket Team has released Apache Wicket 1.3. With this release comes a lot of great successes, but most of all the team wanted to express their wishes to everyone for a happy new year. Apache Wicket is one of the fastest growing Java open source component based web frameworks, based on mailing-list traffic. With a focus on producing valid html and a logical separation between design and code. Within minutes you can start to enjoy throwing out tag soup, complex components and high maintenance overhead for a simple POJO + html data model. Take a look at some of the following highlights or skip to the bottom and get started now.
    • Last JDK-1.4 release (next release will be Java 5 based)
    • First Apache release: renamed packages to org.apache.wicket
    • Simplified several core APIs
    • Now works with zero-config behind a proxy server using relative URLs
    • Added Google Guice support
    • Use your Wicket pages directly in a portal without changing a line of code (JSR-168/JSR-286 support)
    • Switched logging API from commons-logging to slf4j
    • Integrate velocity templates as panels in your pages
    • YUI-calendar and Joda time based date picker (wicket-datetime)
    • Adds new javascript dependencies to the page header using an Ajax request - for example, if a component is replaced on the client via Ajax, and the replacement requires script.aculo.us, script.aculo.us and any other required dependencies will be downloaded at need.
    • Improved, more robust header contributions
    • Scale to extremely large numbers of users with stateless pages and components
    • Improved AjaxTree/AjaxTreeTable
    • Hybrid URL encoding to make search engines and your users happy
    • Create form panels and use them anywhere without worrying about the nesting of form tags
    • Minimized session use by storing component hierarchy in file system (DiskPageStore)
    Get started today by checking out the following examples or follow the download link directly at the bottom.Best wishes from the Wicket Team and a prosperous 2008!

    Threaded Messages (70)

  2. Re: Apache Wicket 1.3 released[ Go to top ]

    Hi, What differences or advantages does this framework has over JSF?
  3. What differences or advantages does this framework has over JSF?
    JSF is based on JSR 127. Wicket is written by some smart developers...
  4. Non snarky response please.
  5. Non snarky response please.
    http://www.google.com/search?q=wicket%20vs%20jsf Congratz to the Wicket team. Wicket is truly an inspiring Java web framework.
  6. Non snarky response please.
    What's snarky about my comment?
  7. Wicket versus JSF versus ...[ Go to top ]

    This is such a broad question that you can make a study out of it. I suggest looking at the Comparing Web Frameworks presentation done by Matt Raible at JavaZone'07. Other links: There is enough material out there in old TSS threads comparing Wicket versus JSF. But could google for those links yourself. As TSS is a forum, some discussion is also needed. I'll take the bait :) As for differences (opinionated, so assume some bias), I think the biggest differences are: the configuration requirements, the templating language and in the ability to create and reuse custom components. Configuration of Wicket is done in Java or using a single property for sensible defaults. Navigation between pages is done in Java. JSF requires quite some XML to glue things together (faces-config.xml), navigation is done using strings that need to be configured in faces-config.xml). Wicket uses plain HTML as the templating language (with additional components that allow the inclusion of Velocity or WebMacro templates in your pages), whereas JSF is a mix/match of JSP, JSF tags and JSF EL. Support for plain HTML templates in JSF needs an additional library. Creating custom components using JSF is something that requires a special role (just as the EJB composer, deployer, etc): it is not for the faint of heart. Creating custom components in Wicket is not rocket science: use the extends keyword (public class MyComponent extends Label). Using the component is as simple as adding a new instance of the component: add(new MyComponent("someid")); Packaging the custom components for reuse in a different project? Put all necessary resources (html, javascript, css, images) in a JAR file and place it on the classpath of the other project. Then use as you would normally do. Less dramatic, but still noteworthy is the ability to test your GUI. WicketTester provides a really good way to unit test your Wicket application and test all your components in isolation. Unit test support for JSF is just starting to develop (in my understanding). There are more differences, but these are the biggest that come to my mind. But there are also similarities: both are component based, both provide the means to build Ajax applications without having to learn JavaScript, and both have passionate developers and teams working to further the technology. In my opinion Wicket delivers a development experience right now that JSF has promised for a long time, and still hasn't delivered.
  8. diferences and pros......[ Go to top ]

    there r a lot of differences,some of them r 1-True component model with no exposure to the servlet api 2-Wicket development is all in java ,no xml descriptors(java developer friendly) with all the refactoring capabilities empowering u to enhance ur design 3-There is no logic in the view markup,u even cannot put it there 4-U can develop the view using any WYSIWYG html editor and the result is the final valid wicket markup(designer friendly) 5-True event model very similar to swing's 6-The easiest framework to develop custom component with(the framework encourage u to do much every thing as a custom component and it is VERY EASY) 7-out of the box ajax support with several built in components to use and to subclass 8-Wicket use the new java keyword to instanciate pages(unmanaged framework)very natural to developers, no dependency on a factory or ioc container(the tapestry way)although naturally integrated with other frameworks and ioc containers 9- Page composition is superb and built in (no external lib as facelets) and really is very powerfull,with at least thre techniqus(inheritance,borders,fragments) 10-Pages and views can b statless or statfull 11-built to scale as it is really cluster ready with builtin terracotta support or custom solution can be easily developed 12-Easy and bookmarkable url with the mounted page 13-REST solutions can be easily developed(read above point) 14-Table ,tree and other data aware components use java model similar to swing or jface 15-these models r statfull with proxy backing to reduce to a huge extent the memory consumed by each session there ra lot of amazing other features,although i focused on diferences from JSF BUT u cannot realise the real power of wicket unless u use it and see how pleasure it is
  9. Re: diferences and pros......[ Go to top ]

    u cannot realise the real power of wicket unless u use it and see how pleasure it is
    And how easy it is to forget all the benefits you get from using a framework you truly enjoy. I still remember the day when I had to go back to a Maverick based MVC application and do some maintenance on the pages. It is only then that you appreciate the benefits of Wicket (in this particular case: making a change required updates to 4 files). Thanks for your list!
  10. Congratulations![ Go to top ]

    Congratulations Eelco, Al, and team! Now hurry up and get that book finished ;)
  11. Why YUI and scriptaculous[ Go to top ]

    The date picker is based on YUI and i see the mention about scriptaculous. Does Wicket need more than one javascript library ? regards Ashok
  12. Re: Why YUI and scriptaculous[ Go to top ]

    The date picker is based on YUI and i see the mention about scriptaculous. Does Wicket need more than one javascript library?
    In principle Wicket doesn't need any library other than what is in core. Instead of creating our own DatePicker component, we looked in the open source marketplace, looked at the various licenses of the JavaScript DatePickers and picked the YUI DatePicker as the best option. So if you use the date picker, it will use the YUI javascript libraries necessary to support the javascript control. But that is all we use from the YUI libraries (currently). There are lots of really good javascript libraries available: mootools, scriptaculous, YUI, jquery, rico, prototype, dojo toolkit, etc. Instead of inventing our own library, and instead of prescribing our preferences (not that we are in alignment about that, mind you), we allow people that have a preference to add supporting component libraries for these excellent JavaScript libraries. Wicket's header contributions enable the use of these tools remarkably well: adding a TinyMCE panel using Ajax to an already rendered page works automatically. The javascript support libraries are available from our sibling project, Wicket Stuff. So there is scriptaculous support, YUI support, dojo support, mootools support, etc. So, no Wicket doesn't need more than one JavaScript library, but provides support for lots and lots of libraries. It is just what your application needs that is needed. If you want, you can write a whole application without ever hand coding one single line of javascript, and still have it do Ajax calls.
  13. Thank you very much for your work on one of the finest Java web frameworks ever. Once "Wicket in Action" is released, this will be, no doubt, Wicket's year. Regards, Daniel.
  14. Hi, Congratulations on the new release. I am looking for a good and simple tutorial to get started with Wicket 1.3. I checked the Wiki and there is a New User's/Getting Started Guide, but it reads "A little dated/incomplete...". I am looking for a document that explains the basics to get you going with Wicket 1.3. I have seem some examples but they are for older versions. Thanks.
  15. ... getting started[ Go to top ]

    for a document that explains the basics to get you going with Wicket 1.3.
    Thanks.
    Good question ... there is a lot of good documentation available, and it is gradually getting better organised. I would suggest you start off by downloading chapter 1 of Wicket In Action (http://www.manning.com/dashorst/) which is free. The four links under "Getting Started" at http://wicket.apache.org/ are very useful - "QuickStart" describes an easy (and good) way to set up a working, mini-Wicket application to get you coding in a few minutes. The "Components" and "Examples" sections are generally very instructive and clear. Then you probably go back to the wiki, for reference, at http://cwiki.apache.org/WICKET/reference-library.html . If you're anywhere near London, you can also come to our Wicket events where there are usually presentations on a broad range of subjects at all levels (http://www.jweekend.co.uk/dev/LWUGReg/). Another great strength of Wicket is the extraordinarily helpful mailing list - see for yourself here: http://www.nabble.com/Wicket---User-f25133.html . That should get you started. Regards - Cemal http://jWeekend.co.uk
  16. Re: ... getting started[ Go to top ]

    Hi Cemal, that is really good info. Thanks.
  17. Try my tutorial at http://www.agileskills2.org/EWDW/chapters1-3.pdf There are more documentation links at http://cwiki.apache.org/WICKET/documentation-index.html
  18. Hi Kent. I will get those free chapters. Thanks a lot.
  19. At first sight, Wicket 1.3 and Tapestry 5 are both - component-based - targets a HTML-based template. While Tapestry 5 use JDK 1.5 annotations, and Wicket 1.3 not, I am sure they share other points. Has any developper an experience to get a Tapestry/Wicket comparison ? Thanks.
  20. At first sight, Wicket 1.3 and Tapestry 5 are both
    - component-based
    - targets a HTML-based template.
    Well latest T5 snapshots aren't coupled with HTML, you could serve more generic XML content just fine as it was HTML. Have a nice day.
  21. Re: Apache Wicket 1.3 released[ Go to top ]

    Congratulations to the entire Wicket team on a superb framework. I migrated an application to Wicket exactly a year back and totally enjoyed it. It is running in production where I work - as well as in lots of places all over the world. I must say the Wicket mailing list support is awesome as well. Here's Looking forward to 2008: The Year Of Wicket :)
  22. Congratulations, sincerely! Wicket is a nice alternative to the JSF mammoth and the first framework introducing the pure HTML template approach. I learned with Wicket some key rules of how to develop a developer-friendly web framework (not a tool-oriented framework ). Jose M. Arranz Developer of ItsNat, Natural AJAX
  23. Re: Apache Wicket 1.3 released[ Go to top ]

    Congratulations to the Wicket team and community! Wicket is the first java web framework that made me enjoy doing web development again. Having the feeling to do clean object oriented code to develop a web app is a pleasure, and developing custom components (like I did for a jquery tab panel for example) is so easy that you can really decompose your application and encourage code reuse over the team. Thank you so much for such a great framework!
  24. Congrats[ Go to top ]

    Last 8 months ive done 2 months SEAM (gave up because of dissapointment) and the rest has been wicket. Implemented a small application. I must say im mighty impressed with what these fellows have done (not the docs though). Theres a reason why there are 1000s of web frameworks. Because none have been good enough. But everytime I've felt this "-Damn, another crippled framework", it ends up Im wrong. Wicket hasnt dissapointet me once in these months. Beeing consistent, structured and simple enough for me to reason myself to solutions to every problem. I dont wanna be a framework fanboy or start talking about a revolution - but I cannot really understand how a web framework could be that much better. I add a little but, because I havent seen it in production and under load yet. Thanx and good luck.
  25. To follow the Book Wicket in Action[ Go to top ]

    It is true that documentation is not the best part of Wicket. But the creators are writing "Wicket in action" for Manning. I am reading it in Early Access Program and this book explains everything. Now i can say I understand Wicket. This book will be a must-have for all developpers using Wicket. This book is the best news-to-come for Wicket .
  26. IDE Wicket Support[ Go to top ]

    None for Eclipse as far as I know, but I believe there is a reasonably mature plugin for NetBeans: https://nbwicketsupport.dev.java.net/
  27. Re: IDE Wicket Support[ Go to top ]

  28. WicketBench[ Go to top ]

    Unless it's changed significantly since I tried it a few months ago, IMHO WicketBench really wasn't helpful at all. In fact, since Wicket uses 99% straight HTML, I ended up using Dreamweaver and/or plain text editor to edit the pages for our Wicket project. Since almost everything in Wicket is done in Java, Eclipse code completion is pretty much all you need to get going.
  29. Re: WicketBench[ Go to top ]

    Wicket Bench opens all the related files together in one tabbed editor. This saves quite some extra editors. So you have in one editor the HTML, Java and resource bundles, and possibly even related javascript and css files. Furthermore it provides quick fixes for creating a Page and Panel class, which will create Java and HTML files directly, which is a (minor) timesaver. Finally it hooks into the refactorings for rename and move (iirc) so not only your class will be renamed or moved, but all related resources as well. If you get compile errors using the current version when creating a new page or panel, you should edit the templates (Preferences -> Wicket -> templates). It is only the default package name that is borked.
  30. Wicket Bench 0.5 released[ Go to top ]

    Wicket Bench just released version 0.5 of the Eclipse Wicket plugin: Wicket Bench List of features Update site
  31. Congrats to the Wicket team! Though, from time to time, I ask myself: Why are we still sticking to HTML? As a Java Developer, I see the future in frameworks such as ECHO2, ThinWire, JSeamless, GWT, etc. because I could do my work using 100% Java without worrying about the HTML/JavaScript/Flex code. Moreover, some of these frameworks could allow deploying the very same code as a desktopApp or webApp.
  32. Quite a narrow sweet spot[ Go to top ]

    I think Wicket is great for a low traffic HTML heavy website and/or you need to support low end browsers (without JS). However for Ajax style application it is not really suitable. Requests are synchronised on the page object so it is Sjax not Ajax and the dual HTML/component thing becomes a pain when you just want to throw panels, buttons around. I've also found that because they have gone for many large components rather than composing things of a few small building blocks it is a bit inconsistent and inflexible to work with. Wicket has a very helpful community so a good choice if you match their sweet spot.
  33. Re: Quite a narrow sweet spot[ Go to top ]

    Just curious x y, what's your framework of choice? I don't understand what you're talking about when you say it's a pain to throw panels and buttons around. I haven't found this to be difficult.
  34. Re: Quite a narrow sweet spot[ Go to top ]

    For web based applications I like GWT. Obviously it falls down if you need to support low end clients. Almost all the styling we do is in CSS so having to maintain the component tree in HTML _and_ in Java component tree is an overhead with little reward. So if I just want a div full of buttons I have to have an HTML fragment lying around rather than just setting the correct CSS style name that I was given by the HTML/CSS monkey. Talking of him he hates that Wicket needs to take over HTML ids (when using Ajax partial updates) as it makes his JavaScript slower only using class. Sorry about the x y thing. I tried to set my real name but after filling out lots of other stuff the update didn't work.
  35. Re: Quite a narrow sweet spot[ Go to top ]

    For web based applications I like GWT. Obviously it falls down if you need to support low end clients.

    Almost all the styling we do is in CSS so having to maintain the component tree in HTML _and_ in Java component tree is an overhead with little reward. So if I just want a div full of buttons I have to have an HTML fragment lying around rather than just setting the correct CSS style name that I was given by the HTML/CSS monkey.

    Talking of him he hates that Wicket needs to take over HTML ids (when using Ajax partial updates) as it makes his JavaScript slower only using class.

    Sorry about the x y thing. I tried to set my real name but after filling out lots of other stuff the update didn't work.
    Just because wicket sets element id for ajax updated elements (which is kinda necessary :), it doesn't mean it's impossible to use the element id to get to the element. You can either pass the generated id to javascript or even set your own (Component#setMarkupId).
  36. Re: Quite a narrow sweet spot[ Go to top ]

    Just because wicket sets element id for ajax updated elements (which is kinda necessary :), it doesn't mean it's impossible to use the element id to get to the element. You can either pass the generated id to javascript or even set your own (Component#setMarkupId).
    All true. We looked at these but in the end decided it was simpler (code and division of work) to either use a css class name or have a non-wicket div or span. The HTML monkey is just sulking about extra spans and divs ;) Cheers Sam
  37. Re: Quite a narrow sweet spot[ Go to top ]

    For web based applications I like GWT. Obviously it falls down if you need to support low end clients.

    Almost all the styling we do is in CSS so having to maintain the component tree in HTML _and_ in Java component tree is an overhead with little reward.
    Do you know what is "separation of concerns"? and decoupling? Independent concepts should be independently represented and should be combined only when needed B. Stroustrup about C++ templates. The reason that data structures and algorithms can work together seamlessly is ... that they do not know anything about each other. Alex Stepanov about Generic Programming. Replace: data structures => HTML layout algorithms => data model
  38. Re: Quite a narrow sweet spot[ Go to top ]

    Do you know what is "separation of concerns"? and decoupling?
    Have you seen http://www.csszengarden.com/ ? Ive found the seperation of concerns works very well with HTML/CSS developers and me if I produce a nice DOM tree with semantic CSS names and other meta data that the front end developer can work with. Obviously if IE6 implemented CSS properly it would be much nicer. As I said originally where the application is more HTML heavy then Wicket looks a lot better. I still find that having to match hierarchy between HTML and components is an overhead I could live without. It gets worse when using partial updates as Wicket takes over the id.
    data structures => HTML layout
    algorithms => data model
    Not sure I buy this analogy. I'm just working on a different split. I spit out a semantic HTML DOM tree (concern A) and another deleloper makes it pretty with CSS (concern B). I thought when CSS arrived we were all excitied because we could get rid of font tags etc. Then we were all pushing to avoid tables for layout etc so that we produced nice clean semantic HTML for screen readers etc... For what it is worth I find I can work well with just semantic CSS names and the guy that sits next to me being busy with JQuery and CSS. Cheers Sam
  39. Re: Quite a narrow sweet spot[ Go to top ]

    I think Wicket is great for a low traffic HTML heavy website and/or you need to support low end browsers (without JS).
    I've only used wicket a year ago for a very small proof of concept, so I'm not that versed, but I think the above quote is just something you throw around without any proof. Are you saying that wicket is not scalable?
    However for Ajax style application it is not really suitable. Requests are synchronised on the page object so it is Sjax not Ajax and the dual HTML/component thing becomes a pain when you just want to throw panels, buttons around.
    That's complete BS. Just like in JSF and any other component based frameworks, there are components that are AJAX enabled and some that are not. It's relatively simple to put together a wicket component that will not synchronize the whole page, so again, you have no clue what you're talking about. Ilya
  40. Re: Quite a narrow sweet spot[ Go to top ]

    I've only used wicket a year ago for a very small proof of concept, so I'm not that versed, but I think the above quote is just something you throw around without any proof. Are you saying that wicket is not scalable?
    No. I'm saying I think this is where its greatest strength lies. I'm sure it can scale however for my money I'd rather try and get something simpler to scale if it was a high traffic site. But as you say I'm clueless ;)
    It's relatively simple to put together a wicket component that will not synchronize the whole page, so again, you have no clue what you're talking about.
    As I said in my reply to Matej I'm sorry if my language was inaccurate I was thinking of the queue on the client side and the server side page lock. If you have a way around these it would be very helpful for my current project. Cheers Sam
  41. Re: Quite a narrow sweet spot[ Go to top ]

    I think Wicket is great for a low traffic HTML heavy website and/or you need to support low end browsers (without JS).

    However for Ajax style application it is not really suitable. Requests are synchronised on the page object so it is Sjax not Ajax and the dual HTML/component thing becomes a pain when you just want to throw panels, buttons around.
    Actually, Wicket is pretty scalable. Throwing around claims about Wicket not being able to handle high traffic without any actual numbers isn't very helpful. Not to mention that in real world the web framework is rarely the bottleneck. Ajax is asynchronous in Wicket, having it locked on page instance doesn't change this fact. The requests are asynchronous and the client is not blocked, although the ajax requests are ordered on client and put to queue(s). They have to be in order to ensure deterministic behavior. The serverside lock on page instance makes good sense, otherwise it would become a nightmare of concurrency bugs. In most of the model 2 applications I've seen noone even bothers to lock things in session... I've never had problem working with panel or other components, would you mind explaining where the pain is? Preferably on mailing list. Thanks.
  42. Re: Quite a narrow sweet spot[ Go to top ]

    Actually, Wicket is pretty scalable. Throwing around claims about Wicket not being able to handle high traffic without any actual numbers isn't very helpful. Not to mention that in real world the web framework is rarely the bottleneck.
    I don't think I said that. I just said I thought its sweet spot is in a particular area.
    Ajax is asynchronous in Wicket, having it locked on page instance doesn't change this fact. The requests are asynchronous and the client is not blocked, although the ajax requests are ordered on client and put to queue(s). They have to be in order to ensure deterministic behavior.

    The serverside lock on page instance makes good sense, otherwise it would become a nightmare of concurrency bugs.
    Sorry if I was not precise in my original statement. I was thinking of the queue on the client and the lock on the server side that you mention. I can totally see why it was done but it does seem like a serious limitation to me.
    I've never had problem working with panel or other components, would you mind explaining where the pain is?
    Ive found in HTML light web applications maintaining the HTML fragments seems redundant. I'd rather just manipulate components in Java and set the appopriate css class names. Cheers Sam
  43. Re: Quite a narrow sweet spot[ Go to top ]

    I was thinking of the queue on the client and the lock on the server side that you mention. I can totally see why it was done but it does seem like a serious limitation to me.
    Do you like multithread code? do you like coding locks by hand? Do you know the HTTP 1.1 only allows two concurrent (AJAX or not AJAX) requests per browser-server? No very much concurrency is allowed. Do you know a processor/core only can dispatch very very few threads concurrently? we are talking about web applications with several concurrent users, every user needs two or more threads? sure? Do you know servlet containers usually manage a pool of threads? if all threads are used your request must wait. Of course if you want to run a new concurrent task you can create a new thread.
  44. Re: Quite a narrow sweet spot[ Go to top ]

    Do you like multithread code? do you like coding locks by hand?
    Nope. It is a nightmare. Why can't a server handle more than one request per client without application specific multi-threading? Surely I can have a slow task be performed in one thread and do something for the user in another without hand coding any MT code?
    Do you know the HTTP 1.1 only allows two concurrent (AJAX or not AJAX) requests per browser-server?
    I thought it was a suggestion rather than a hard rule but still seems very handy to allow the user to use the UI incase another action is being slow.
    Do you know a processor/core only can dispatch very very few threads concurrently? we are talking about web applications with several concurrent users, every user needs two or more threads? sure?
    My main concern (about our large Wicket application) is now having the need to make sure all requests are handled very promptly. Obviously I would want to avoid this no matter what the architecture but now it is even more damaging as the whole UI is blocked meaning the user will probably start clicking more as they find everything "seems to have stopped working".
    Do you know servlet containers usually manage a pool of threads? if all threads are used your request must wait.
    also if I have a 100 free my poor Wicket user still can't use one. Cheers Sam
  45. As a Java Developer, I see the future in frameworks such as ECHO2, ThinWire, JSeamless, GWT, etc. because I could do my work using 100% Java without worrying about the HTML/JavaScript/Flex code.
    Fine, but it breaks the *web development culture*: the web developer/designer usually wants *full control* of the HTML layout. I invite you to read this article (disclaimer: is written by me, Wicket approach fits well with my thinking).
    Moreover, some of these frameworks could allow deploying the very same code as a desktopApp or webApp.
    Do you really need this strong feature? I think >90% of web applications have no code shared with desktop app, do you agree?
  46. Do you really need this strong feature? I think >90% of web applications have no code shared with desktop app, do you agree?
    Don't or shouldn't? I don't write web applictions. I write applications that might have as one of their UI's a browser UI.
  47. Do you really need this strong feature? I think >90% of web applications have no code shared with desktop app, do you agree?

    Don't or shouldn't?

    I don't write web applictions. I write applications that might have as one of their UI's a browser UI.
    Of course, almost any desktop application managing "business" data may have a browser GUI (I'm not talking about intensive graphics applications), before the web most of applications where fat client connected to databases, these days those applications have been *replaced* to web applications to avoid maintenance problems. Of course now we have Java Web Start etc but the web approach won. This "history" is a generalization many applications have two versions, desktop to internal use, web based for clients but to convert semi-automatically a desktop application UI part to the web (using a like-Swing web framework) is not a recommended approach if your user wants a "like a web site" application.
  48. Do you really need this strong feature? I think >90% of web applications have no code shared with desktop app, do you agree?

    Don't or shouldn't?

    I don't write web applictions. I write applications that might have as one of their UI's a browser UI.


    Of course, almost any desktop application managing "business" data may have a browser GUI (I'm not talking about intensive graphics applications), before the web most of applications where fat client connected to databases, these days those applications have been *replaced* to web applications to avoid maintenance problems. Of course now we have Java Web Start etc but the web approach won.

    This "history" is a generalization many applications have two versions, desktop to internal use, web based for clients but to convert semi-automatically a desktop application UI part to the web (using a like-Swing web framework) is not a recommended approach if your user wants a "like a web site" application.
    So are you now saying they do share code? :) Anyway, the "ease" of "web apps" is not maintenance. It is their deployment (which is not always easy). The majority of people have chosen html based browser UIs not for maintenance or deployment issues. They did it because they have the herd mentality. One of the factors in this is that people think you have to do web apps to do enterprise applications. Of course, this is not true. I highly doubt the web approach has "won". Most users don't like web applications. I have seen the tide turning back to more "desktop" applications. Those on the bandwagon dumped their desktop apps and went web without understanding what actually was good about them both and figuring out how meet both needs with both. They usually didn't keep both. And if they did, they didn't share anything, sadly. This is why i asked you the question. I think the "applications" could share a lot code and should. The main application I am currently involved in is a combination of a web enabled Eclipse RCP (for daily users), a Web UI (soon to be 3) for occasional users, and a non-ui-interface for system processes. I agree with your assessment about web sites and Swing like frameworks, for the most part. I suggest you go look at what Yoxos is doing. With "Web 2.0" the line is becoming more blurred. http://eclipsediscovery.yoxos.com/discovery/rap Anyway, apologies to the Wicket people for hijacking their thread.
  49. The majority of people have chosen html based browser UIs not for maintenance or deployment issues. They did it because they have the herd mentality.
    I disagree. Most developers I know would prefer to work on desktop(-like) applications rather than web applications. But companies often do prefer the easier (cheaper) maintenance/ deployment of web applications. For just about every project I've done the last few years a serious evaluation of desktop alternatives was done before going for a browser based solution. The latter always won because customers preferred it and techs like Java Webstart failed to be robust enought (there was always at least one test client with installation problems). Also, I think it is an urban myth that desktop applications are always cheaper to develop. Maybe something like Adobe Air will change this preference. Believe me, even though I've invested plenty of blood, sweat and tears into Wicket, I'd love to have a good alternative to web applications as they are today. My 2c
  50. I disagree. Most developers I know would prefer to work on desktop(-like) applications rather than web applications.
    Why is that? Also, when I said "herd mentality", i was talking more about "companies" and management, like you mention in you next statement.
    But companies often do prefer the easier (cheaper) maintenance/ deployment of web applications.
    This is a perceived value. And thus why i said "herd mentality". I am NOT saying that if you do web apps you are part of the "herd mentality". There are valid reasons for doing it and for using products like Wicket.
    For just about every project I've done the last few years a serious evaluation of desktop alternatives was done before going for a browser based solution.
    So, then how is the web app easier to maintain ?
    The latter always won because customers preferred it and techs like Java Webstart failed to be robust enought (there was always at least one test client with installation problems).
    Well, I have had the opposite experience. Web Start has it issues, but so do web apps and those are more difficult to solve.
    Also, I think it is an urban myth that desktop applications are always cheaper to develop.
    I would have to agree. If I said "always" then I retract that. The problem is that people say that about web apps. And that, definitely is a myth. There is way too much that goes into figuring out cost and ease. And what is true today might not be tomorrow.
    Maybe something like Adobe Air will change this preference. Believe me, even though I've invested plenty of blood, sweat and tears into Wicket, I'd love to have a good alternative to web applications as they are today.
    If you develop desktop apps that sometimes need to be web apps or the opposite, check out RAP. For web sites with application like functionality, I'll give Wicket a deeper look. We are about move to the next phase of our "solution" and this is the type of UI we will be adding.
  51. So, then how is the web app easier to maintain ?
    The latter always won because customers preferred it and techs like Java Webstart failed to be robust enought (there was always at least one test client with installation problems).

    Well, I have had the opposite experience. Web Start has it issues, but so do web apps and those are more difficult to solve.

    Regarding webapps, I'd like to know exactly what these difficulties are, and how a desktop app provides a better solution. I'll admit, I'm part of the "herd-mentality"... on just about every front I can imagine, webapps are easier: - Security - Languages - not just Java, but PHP, Ruby, CGI, .Net, whatever... maybe I'm out of touch, but it seems that desktop apps are limited to Java and M$ technology. - Portability - just about every major desktop has a browser. - Versioning Java Web Start addresses alot of these issues, but that's just for applications written in Java. I can think of a couple of advantages a desktop-app would have, mainly: - More responsive UI - Scalability AJAX/Web 2.0 has come a long way in addressing the former. Admittedtly, these are hacks, but frameworks like Wicket and GWT provide enough abstraction so Joe Developer won't have to worry about the hacks. Scalability is a real concern, but for most enterprise apps, the majority of processing needs to happen on the server-side anyway, so having a fat client provides marginal benefits. I'm not trying to undermine your points... I'd seriously like to know what the "pro-" arguments are in going with a thick-client solution (or more specifically, Java Web Start).
  52. So are you now saying they do share code? :)
    Sometimes, but not frequently :)
    Anyway, the "ease" of "web apps" is not maintenance. It is their deployment (which is not always easy).
    Your bank doesn't need to update your browser when their end user bank application changes, it would be nice but they don't want to fix my computer :) The end user doesn't need to install any software to manage his/her bank accounts. May be the deployment of a web application is a nightmare but is not the user problem.
    The majority of people have chosen html based browser UIs not for maintenance or deployment issues. They did it because they have the herd mentality.
    To the end user, web is easy, web is one stop, web is no installations, web is "one click", web is cool, web is "super", web is tons of beautiful (and hot) images... we, software developers, are slave of end users so we must deliver web... :)
    I highly doubt the web approach has "won". Most users don't like web applications.
    Today the web approach has won, may be someday... I'm not talking about the web technology is superior to any other. Web development is a hack, but is a hack so cool... and end users love this hack.
    I think the "applications" could share a lot code and should.
    I agree, this is possible, for instance Wicket's tree uses Swing's tree data model, my web framework, ItsNat, uses *ever* Swing data and selection models. Both frameworks use a component oriented background, this background is "compatible" with desktop development style. The problem is UI: web UI (technology and culture) is so different to desktop UI ... any attempt to bring the desktop UI to web is interesting but I think is a wrong option unless you are coding a quick port. Is my opinion and of course I'm biased but when I see the source code of a web page of such RIA desktop-like web frameworks I can't breath and my heart stops :)
  53. Re: Apache Wicket 1.3 released[ Go to top ]

    Is it a bit too old when 1.3 is only based on JDK 1.4 and next release is still based on 1.5 only?
  54. My two cents[ Go to top ]

    I've been using Wicket for a project at work and I have used struts/JSP in the past and here are my comments. 1. Overall, I like the approach and most of the design decisions. Since I am an OO programmer Wicket translates HTML and Javascript into something I am more comfortable with and I like that. 2. I love the uncluttered HTML and lack of XML configuration. This is one of the best things about Wicket. 3. I found it hard to program some of the things in Wicket. My application has a very complex UI. It was hard enough to get some of that stuff to work in HTML and then having to 'translate' it to Java/Wicket was frustrating at times. To be fair a lot of the frustrations were because HTML sucks and really not due to Wicket. What the Wicket team is doing is really difficult work as HTML/Javascript are so ill defined. However, I did manage to uncover some bugs in Wicket and working around them took some time. Many of these issues are fixed in 1.3 but it did not help me as I am still using 1.2 4. The support for Wicket on the forums is fantastic. The documentation is not too great but the team is very helpful 5. Wicket is a moving target at this time. It's not easy to upgrade from one version to another since there are many, many changes. I think that in the future Wicket will become more stable and easier to work with. It is possible to build production applications in Wicket now but it's still a little on the 'bleeding edge' 6. Overall I think with Wicket you have to write much more code more than with Struts/JSP. However, the Wicket code is much more maintainable and understandable. If you consider that an application usually spends only 10% of it's life cycle in development and 90% in maintainance then it's a fair trade off. 7. The AJAX support in Wicket is really nice. For example, it's fairly simple to update a button title without reloading the page. I believe that my experience with Wicket would have been smoother if I had started with 1.3 instead of 1.2. As a small example a small bug in 1.2 makes it impossible for me to reload a single cell in a table using AJAX. However, this has been fixed in 1.3. Congratulations to the Wicket team for a fine framework!
  55. Wicket 1.3 and Liferay Portal[ Go to top ]

    How easy is it to use Wicket 1.3 application as a portlet in Liferay Portal 4.xx? As anyone tried it yet?
  56. No portlet support[ Go to top ]

    I believe wicket does not have portlet support, so not usable in any Portal server. Maybe the wicket team is waiting for JCR-268 (next generation portlet spec) to be completed?
  57. Re: No portlet support[ Go to top ]

    I believe wicket does not have portlet support, so not usable in any Portal server.

    Maybe the wicket team is waiting for JCR-268 (next generation portlet spec) to be completed?
    Wicket does support portlets out of the box. In fact, one of the core developers (Ate) is also involved in various portlet initiatives and JSRs. See for instance http://www.slideshare.net/ate.douma/wicket-portlet-primer/
  58. Re: No portlet support[ Go to top ]

    I believe wicket does not have portlet support, so not usable in any Portal server.

    Maybe the wicket team is waiting for JCR-268 (next generation portlet spec) to be completed?


    Wicket does support portlets out of the box. In fact, one of the core developers (Ate) is also involved in various portlet initiatives and JSRs. See for instance http://www.slideshare.net/ate.douma/wicket-portlet-primer/
    Do however check out the various discussions on the mailing list (or ask if you run into trouble). On some portlet containers it should run smoothly, but others might require more work (Liferay for instance).
  59. Re: No portlet support[ Go to top ]

    I stand corrected. This just does goes to show I can never trust anything my colleagues tell me.
  60. Re: No portlet support[ Go to top ]

    well, almost anything :)
  61. Keep up the good work![ Go to top ]

    I second hoping that the core team remains humble and focused on developers feedback and not engage in excessive vanity (as tragically happened with some in Rails community --- I love Rails though). However, I also agree with their firmly responding to some of non-sensical and amaturish critiques. Thanks Wicket team for a truely elegant and sensible framework.
  62. Re: Keep up the good work![ Go to top ]

    I second hoping that the core team remains humble and focused on developers feedback and not engage in excessive vanity (as tragically happened with some in Rails community --- I love Rails though). However, I also agree with their firmly responding to some of non-sensical and amaturish critiques.

    Thanks Wicket team for a truely elegant and sensible framework.
    I imagine I come under the category of "non-sensical and amaturish critiques". Strangely the most venom came from people who admitted to "used wicket a year ago for a very small proof of concept" while Matej Knopp, who I think is a core Wicket developer, was very polite, well reasoned and informative. I've been coding web applications for about 10 years and using Wicket full time for about 5 months so thought I had something to contribute to the discussion. I like robust geeky discussion but I've not really enjoyed the response to my first post on theserverside. Anyway I honestly wish the Wicket team all the success in the world. I've found them all very polite and helpful. Cheers Sam
  63. wicket:id ?[ Go to top ]

    Why do you need to add everywhere in the HTML templates the wicket:id parameters? Wouldn't it be easier to maintain - for Html guys - to use the normal html "id"? Just like GWT ? (To me GWT and Tapestry are the closest framework to Wicket)
  64. Re: wicket:id ?[ Go to top ]

    It's the only way to bind the markup component with it's associated java component. Something similar to "bind" from jsf.
  65. Re: wicket:id ?[ Go to top ]

    Why do you need to add everywhere in the HTML templates the wicket:id parameters?
    Wouldn't it be easier to maintain - for Html guys - to use the normal html "id"?
    The semantics are slightly different as wicket:id only has to be unique relative to its parent. This means you can re-use HTML fragments without having to worry about ids clashing. Having said that it would be nice if an absolute id could be specified in the HTML to override the default behaviour.
    Just like GWT ?
    (To me GWT and Tapestry are the closest framework to Wicket)
    Obviously one of the big differences between GWT and Wicket is that in Wicket the component tree is held on the server side. Lots of pros and cons to this difference. One less obvious difference is that to improve scaling, I think, the components (and any other page state) is serialised. Needing to support serialisation is a bit of a pain but they provide some classes to support attaching/detaching the model etc. I think Wicket in full Ajax (partial updates) "mode" is very much like Echo. Cheers Sam
  66. Re: wicket:id ?[ Go to top ]

    Thank you for these answers. I did not think about the possible multiple wicket:id-s. But I definitively think this would be nice not to change anything on the HTML pages. So these pages can change easily and the java developper simply decorates the given work of the web guy. "the web developer/designer usually wants *full control* of the HTML layout.". Separation of concerns and Configuration over convention. Which is one of the mantra of wicket (and this is why i think Wicket is better than the other frameworks). Maybe adding a new signature to the Component where the String wicket:id is replaced by something like that object: new WicketId(String htmlId) (or a static factory WicketId.getHtmlId(String htmlId) ) - where the wicketId represents/creates a wicket:id. Moreover, most of the time the multiple wicket:id happens in components, not in the pages. In tr/td not in divs... And when you have multiple components with same wicketIds, you will certainly not have access to an html id. This could lead to java developpers not changing html pages at all. (There is other tags like wicket:remove but still I think one can find a workaround). Anyway maybe this is not the best place to continue the conversation? But this wicket:id-s somehow shows the other pain with wicket (sorry, guys): one have to code more. As said before, this code is easy to maintain so it may worth the price. But still..Binding the fields of an objet is a long and (most of all) uninteresting work. What about some more configuration over convention where you bind an object to an entire component (and its ids)?
  67. Re: wicket:id ?[ Go to top ]

    What about some more configuration over convention where you bind an object to an entire component (and its ids)?
    One word: CompoundPropertyModel. It allows you to bind bean properties based on component identifiers. Form form = new Form("form", new CompoundPropertyModel(person)); form.add(new TextField("name")); form.add(new TextField("address.street")); form.add(new TextField("address.zip")); form.add(new TextField("address.city")); There is one caveat: when you rename a property, for instance zip to zipcode, then you end up having to rename the textfield's id in both the Java code and markup. Convention over configuration does have its price. This is why framework builders really want to have a typesafe way to bind to bean properties.
  68. Wicket Web Beans[ Go to top ]

    Another option is to use the Wicket Web Beans components.
  69. Couple of reasons for wicket:id[ Go to top ]

    Hi, I think when Wicket started they also used normal id instead of wicket:id (not really sure about this). But there are a couple of pro's for using wicket:id. 1. Seperation. Designers like to have control over the ID for CSS etc. Then the developers have their own ID for developing. 2. Wicket:id allows duplicate names in the markup, normal id needs to be unique on a page (according to the standard). On a page with multible tables you might use the wicket:id="row" multiple times. 3. Working together with different frameworks the wicket:id also helps. I think some AJAX frameworks (like prototype/dojo etc?) use the id's, so its better to have wicket use something else so they don't collide. I hope this will help you understand the choice they made. It looked weird to me too at first, but you get accustomed to it pretty fast.
  70. Many Thanks[ Go to top ]

    No doubt, Wicket is the most sensible, most enjoyable and most friendly web framework. I only wish the core developers to stay humble and listen to the needs voiced out in the user land. We've all seen pride of success distroy people, work and future hopes. Pride damages the brain in a way the patient is not aware of. Thanks for the hard work.
  71. wicket is more complex and verbose than necessary