Wicket 1.0, web framework, released

Discussions

News: Wicket 1.0, web framework, released

  1. Wicket 1.0, web framework, released (108 messages)

    The Wicket web framework team has released Wicket 1.0 as open source under the Apache Software License.

    Wicket is a component-oriented web framework which simplifies the creation of complex web user interfaces. The look and feel of Wicket web pages is defined in ordinary XHTML, which can be edited with standard Web tools such as DreamWeaver or Go Live. The pages are then made dynamic by associating Java components. Wicket components are extensible within the Java language, much like Swing components, and can be backed by POJO (Plain Old Java Object) model objects that can be persisted using an ORM tool, such as Hibernate or JDO. Wicket also enables developers to create and package advanced reusable Web components.

    Key features of Wicket include:
    • Swing-like OO Component Model
    • Ease of Development
    • Clear Seperation of Concerns
    • Reusable Components
    • Secure
    • Transparent, Scalable Clustering Support
    • Transparent Back Button Support
    • Simple, Flexible, Localizable Form Validation
    • Typesafe Sessions

    Threaded Messages (108)

  2. JSF done right?[ Go to top ]

    Looks like Tapestry with less XML :)
  3. yywf[ Go to top ]

    How many of these does the world need?
  4. yywf[ Go to top ]

    How many of these does the world need?

    Until someone gets it right?
  5. yywf[ Go to top ]

    lol, don't hold your breath. ;)
  6. yywf[ Go to top ]

    lol, don't hold your breath. ;)
    The download of Wicket takes at my company about 30 seconds... I can hold my breath for 45 seconds :-D

    Seriously, I don't think there will be ever the One that Fits Everybody web framework.

    I do think that Component Based frameworks (be it JSF, Tapestry or Wicket) are the future of (Java) web application development as they really make life much easier on the designers and developers.

    How easy is it to put 2 independently pageable and sortable tables on one page in a given model2 framework? Wicket source code: the table component and the corresponding page.
  7. yywf[ Go to top ]

    How many of these does the world need?

    They're cheap .. buy two ;-)

    Peace.
  8. yywf[ Go to top ]

    How many of these does the world need?

    <TranceMode>
    Wait untill ClickOnce comes and kills them all.
    Wait untill ClickOnce comes and...
    </TranceMode>
  9. Vs Tapestry[ Go to top ]

    The concepts and approach seem very similar to Tapestry. However, the concern would be that Tapestry has a larger developer community and HLS is a well known guy.
  10. Looks like[ Go to top ]

    Velocity in a more webcentric context to me....
    Actually not quite since velocity does not come with a component set.
    But kudos for doing this, if you do not have tools support a lean config file less approach always is better.
    That is one thing I liked about most velocity based approaches.
  11. Web framework overkill[ Go to top ]

    Yes we have that, my personal guess is, on the java side of things, in the end there will only 3 which will survive in the long term.
    JSF as being the offical standard with a huge component base and good tools, which will move somewhat slow but steady.
    Something in the middle, like Tapestry with medium tool support,

    and probably this framework, since it seems to target the problems for web only development without tools the right way, keep it small and simple.
    JSF is not too shabby, but you can see that it is more a generalized spec than a tight framework, basically everything is bound over xml files together, so that the tool vendors have an easier life.
    JSF with tools and a good component set is easy, JSF without tools and components you have to write yourself is hell, because you run into the everything being loosely coupled issue, which delivers on the other side a lot of flexibility which is important for enterprise development.

    This neat framework tries to solve the issue differently, keep everything webcentric, try to avoid xml bindings as much as possible, make the coders life easier even once he has to move away from plain web frontend coding.
    I think both approaches have its advantages and disadvantages. I am glad however to have another tool at the othe scale of complexity at my hands.
  12. usual questions..[ Go to top ]

    1. anyone using this in real (non-trivial) applications?
    2. how does it compare to tapestry in terms of application development time, run-time speed, learning curve, error handling?


    btw could it support ajax development or would that defeat the design goal of back-button functionality?
  13. usual questions..[ Go to top ]

    1. anyone using this in real (non-trivial) applications?

    Wicket is <em>the</em> Java web application framework we currently use at Topicus (the employer of 3 core developers). Several business applications are using Wicket already, one of which is in already in production at 2 large financial institutions.
    2. how does it compare to tapestry in terms of application development time, run-time speed, learning curve, error handling?

    I haven't done any (real) Tapestry development, but I did <em>try</em> to read 'Tapestry in Action' and found it rather complex. From what I've read in that book, and what I read on the mailinglist of Wicket, is that Wicket has a significant lower learning curve than Tapestry, and that the application development time is higher. Run-time speed comparisons haven't been made (as far as I can tell).
    btw could it support ajax development or would that defeat the design goal of back-button functionality?

    The current HEAD in CVS has basic support for AJAX working, but still needs a lot of polishing. AJAX, component contributed Javascript and CSS support is scheduled for 1.1
  14. usual questions..[ Go to top ]

    ... that the application development time is higher.
    Should be read as: "... that the application development time is shorter."

    I had 'application development speed' in mind when I wrote the reply.
  15. usual questions..[ Go to top ]

    I am really scared to hear 2 major financial institutions are using frameworks like this. No wonder we have a lot of identity theft and other problems.
  16. usual questions..[ Go to top ]

    I am really scared to hear 2 major financial institutions are using frameworks like this. No wonder we have a lot of identity theft and other problems.

    What a superbly informed opinion. You must be very omniscient to know that those identity thefts and other problems were related to using a Java web framework. Kudos! Everybody should be programming servlets again and we won't have any security related issues ever!

    Come on! What were you thinking when you typed this message. Web frameworks make it far more easy to design and develop secure applications than using JSP's and/or servlets. I have yet to see ONE news item pointing out that Struts, Tapestry, Wicket, JSF, Echo, WebWork, or any other web framework out there was the reason of any security related problem.
  17. Ajax in Wicket[ Go to top ]

    This looks like finally someone finally found the point in the middle ! Congratulations to all Developers.

    By the Way: Ajax would be great, when is 1.1 scheduled ?

    Have Fun !
    Jochen.
  18. Schedule for 1.1[ Go to top ]

    1.1 is scheduled somewhere late this summer (august, september). We are currently very busy preparing for JavaOne, 2 presentations featuring Wicket there:
     o session TS-8617 "POJO Web Development With Wicket" on Tuesday 06/28/2005 11:00 AM - 12:00 PM, Moscone Center N Mtg Rm121/122
     o session TS-7642 "Web Framework Smackdown" on Wednesday 06/29/2005, 04:00 PM - 05:00 PM, Moscone Center/Esplanade 307-310.

    The groundwork for 1.1 is mostly in place, but now the rough edges need to be taken care of. For a roadmap, please see our wiki.
  19. wicket rocks[ Go to top ]

    One advantage of wicket over tapestry is you can just read javadoc and understand how every component works. With tapestry you need to track down the input and output spec for each component. Wicket is actually a lot easier to use than tapestry. I know, because I started from scratch and wrote the same exact app in wicket and tapestry. It was a non-trival app.
  20. Portlets[ Go to top ]

    Is it portlet, JSR-168, friendly ?
    Is it easy to use with Spring framework ?
  21. Portlets[ Go to top ]

    There's work going on for Wicket 1.1 regarding portlets. Spring framework integration is available in 1.0, but that is not packaged as part of the core. See wicket-stuff for that.
  22. http://howardlewisship.com/blog/2005/06/wicket-10.html

    Interesting thoughts on Wicket...
  23. The original author of Wicket, Jonathan Locke, has responded to Howard Lewis Ship's blog.
  24. My response to HLS[ Go to top ]

    My response to Howard Lewis Ship's comments on Wicket:
     o Wicket doesn't target Tapestry, but MVC frameworks
     o Wicket rightly favors ease of development over upfront, framework imposed optimization
     o Let's grab a beer on/after JavaOne
  25. I've been very pleased[ Go to top ]

    I have used Wicket since last Fall for personal projects. I have 3 kids and a wife so my free-time is very limited. Given that, I had to be very picky about which framework I chose.

    I've been very impressed with how little hassle it has been to start creating powerful, reusable components and pages with Wicket even under rather severe time constraints. I was pleased with how little time I spent debugging. Things worked as I expected and the error messages were explicit enough to point me to the source of my error.

    I was also very impressed with the quality and attention of the developers on the mailing list. They have made a lot of really good refactoring decisions and I'm excited to see what comes out for version 1.1.

    (No, I wasn't paid to do this and no, I'm not a Wicket developer. I'm just completely sold on it :-)

    Jonathan
  26. I've been very pleased[ Go to top ]

    I too have a wife and kids and have a life, something that gets in the way poring over source and mauals to figure out how good a framework is. I have had "Tapestry In Action" for months but never got past Chapter 1.

    So I appreciate your comments; a couple of questions:

    a) Menu Tree -- can does the menu tree retain its state ( collapsed nodes , expanded node ) across requests.

    b) Javascripted components : Does this framework make it easy to work with Javascripted screens e.g RichtTextEditor, DIV elements that can be moved or hidden , handling mouseover events etc. Or doe it get in the way ?

    c) Memory : how much memory can it consume ?

    d) inter-operability with Existing Struts JSPs: Can a wicket application war also have struts ? E.g. I would like to add more functionality to an existing (stuts+jsp) application and I would like to use Wickets . Is this possible ? Can the session state information e,g. user login information be shared with Struts based components ?





    Thanks
  27. I've been very pleased[ Go to top ]

    I'm definitely not an expert here, but I'll give a try. Hopefully someone with real knowledge on the specifics will come and clean up after me. :-)
    a) Menu Tree -- can does the menu tree retain its state ( collapsed nodes , expanded node ) across requests.

    I haven't actually used the tree component, but if it works like everything else it would keep state.
      b) Javascripted components : Does this framework make it easy to work with Javascripted screens e.g RichtTextEditor, DIV elements that can be moved or hidden , handling mouseover events etc. Or doe it get in the way ?
    Javascript is supported because all it generates is HTML, but in version 1.1 components will be able to add Javascript dynamically to the page. (Did I get that right?) They are also working on supporting AJAX in 1.1 I believe.
    c) Memory : how much memory can it consume ?
    I think it really depends on how you setup your app. Future versions will have more options for reducing server-side state. See Jonathan Locke's response to HLS above.
    d) inter-operability with Existing Struts JSPs: Can a wicket application war also have struts ?
    I haven't had to do any integration with JSPs. I'm pretty sure this is possible based on the types of links it can generate and link to, but I should defer to someone else.
  28. I've been very pleased[ Go to top ]

    I too have a wife and kids and have a life, something that gets in the way poring over source and mauals to figure out how good a framework is.
    That is odd, an IT worker with a social life... Can't recall meeting one before ;-)
    a) Menu Tree -- can does the menu tree retain its state ( collapsed nodes , expanded node ) across requests.
    Yes it can. This live example does just this (it is not a Javascript tree, it does a server round trip each time you change a node. For Wicket 1.1 we are incorporating JavaScript support, allowing easy integration of for example http://www.treeview.net/.
    b) Javascripted components : Does this framework make it easy to work with Javascripted screens e.g RichtTextEditor, DIV elements that can be moved or hidden , handling mouseover events etc. Or doe it get in the way ?
    Wicket doesn't get in the way, but the current version has very limited JavaScript support. We are currently adding full blown JavaScript support into Wicket 1.1 (due late this summer), enabling JavaScript components like HtmlArea, Treeview, DateTime picker, etc. Also on the calendar is full support for AJAX.

    The Wicket team aims to make it very easy to integrate JavaScript and AJAX into your applications, just like we did for creating your own components, add back button support, enable clustering, etc.
    c) Memory : how much memory can it consume ?

    I suppose you mean 'serverside state' here. Though I don't have actual numbers, Wicket stores the component tree in the session (see Jonathan Locke's reply to Howard Lewis Ship's comments mentioned earlier). This means that Wicket will consume more memory. But it is tweakable, and in 1.1 we are implementing the means to go near zero serverside state. However, we will again try to make it as easy as possible to go from full serverside state to minimal serverside state.
    d) inter-operability with Existing Struts JSPs: Can a wicket application war also have struts ?

    I think this is possible, however we haven't built the support (yet). I can certainly see the business benefits for this. Until now we haven't had anybody asking for this :-).
  29. I've been very pleased[ Go to top ]

    I too have a wife and kids and have a life, something that gets in the way poring over source and mauals to figure out how good a framework is. I have had "Tapestry In Action" for months but never got past Chapter 1.

    I'd like to invite you to follow a 1-hour tutorial
    on Tapestry at http://www.agileskills2.org/EWDT. Hopefully
    it will get you started.
  30. I've been very pleased[ Go to top ]

    I think it's very telling of Tapestry in general that it takes more effort to describe even a simple program like "hello world" (and the complexity only increases as the problems get harder). Read the Hello World section of Chapter 1 in this tutorial, then compare to:

    http://wicket.sourceforge.net/ExampleHelloWorld.html
  31. I've been very pleased[ Go to top ]

    Note that the roughly 2 page Wicket "Hello World!" example covers the same ground as pages 13-23 of this Tapestry tutorial. Although the Wicket example is written in a terser style, I bet you still get the point. Why? It's simple. In any case, just read both and compare. Which framework do you feel is simpler?
  32. I've been very pleased[ Go to top ]

    I think it's very telling of Tapestry in general that it takes more effort to describe even a simple program like "hello world"

    I believe the statement above untrue. In general I don't see any difference in the concepts involved in the two tutorials. So I don't see the grounds on which how one can conclude Wicket is simpler than Tapestry. Maybe you could tell us the conceptual differences in your mind?

    The Tapestry one (mine) is longer because:
    1) it includes a screenshot for each step.
    2) it explains more necessary tasks during normal development (deployment and web-app management in Tomcat).
    3) it explains not only what to do but also how it works.

    That is, if it didn't include screenshots, ignored Tomcat and only showed what to do, then it would not be any longer than the Wicket version.
    (and the complexity only increases as the problems get harder).

    This is not true. A lot of fundamental concepts have been explained using this simple HelloWorld example. These concepts are important and will serve as a solid foundation for more complicated problems to be solved later. However, they won't been to be explained again then.
  33. I don't think that the requirement of how long a Hello World program is matters. A servlet printlining a Hello World message is shorter than both Wicket and Tapestry, will require less explanation but nobody in a right state of mind will ever consider using servlets for full blown web application development.

    Both Tapestry and Wicket have their merits. Tapestry has a long history and that is both an advantage and a disadvantage. An advantage as it has been pretty much proven itself and has a large installed userbase. A disadvantage as it has to maintain backwards compatibility and can't rollback choices made in the past easily (XML configuration to name one).

    Wicket also has its pros and cons: it is young, has a small userbase (though increasing very fast!), has yet to prove itself (though a few non-trivial applications are already live). But being young also means that you can learn from others and be able to go into alternate directions, avoiding the potholes and dead-ends other frameworks stepped into.

    There is no doubt in my mind that Wicket is far more easier to understand and learn than Tapestry. But that is OK, as Tapestry had to create (or invnent) component based development, and Wicket had to make it easier.

    I'm not alone in this opinion. Other users of Wicket have had the same experience, some of those already posted to this forum. On my blog, I have a http://blog.csdn.net/sunsnow8/archive/2005/01/17/255810.aspx&lp=zh_en">babelfish translation of some Chinese forum post</a> (poorly translated), stating (IMO) that the programmer needed to study the Tapestry in Action book in order to create his web application, as opposed to where such book was not necessary with Wicket. Other comments on this forum also suggest that Tapestry is more complex than Wicket.
  34. I don't think that the requirement of how long a Hello World program is matters.

    Agreed.
    A disadvantage as it has to maintain backwards compatibility and can't rollback choices made in the past easily (XML configuration to name one).

    I am not sure that XML configuration was a mistake.
    I'm not alone in this opinion. Other users of Wicket have had the same experience, some of those already posted to this forum. On my blog, I have a http://blog.csdn.net/sunsnow8/archive/2005/01/17/255810.aspx&lp=zh_en">babelfish translation of some Chinese forum post</a> (poorly translated), stating (IMO) that the programmer needed to study the Tapestry in Action book in order to create his web application, as opposed to where such book was not necessary with Wicket. Other comments on this forum also suggest that Tapestry is more complex than Wicket.

    It was due to the lack of easy-to-follow tutorials for Tapestry at that time. One shouldn't say X is easier than Y just because X has better introductory documentation now than Y in the past.

    I am hoping that someone would point out the technical differences between the two to show that why Tapestry is harder.
  35. Transparent Back Button Support

    Wicket supports configurable page version management. When users submit a form or follow a link from a page they accessed with the back button in their browser, Wicket is able to revert the page object to the state it was in when the page was originally rendered. This means you can write web applications that support the back button with very little work

    Wicket looks cool but I did not understand why this feature is necessary. Why don´t just apply a "redirect after post" pattern here ? IMHO it would be a much cleaner design.
  36. We already support redirect-after-post. What the back-button support does is version your components/model, giving you an automatic way of dealing with what would normally be stale data. If you enable this feature, as a Page's component hierarchy is mutated, Wicket keeps track of the changes. If the user goes back to an earlier version of the page and does a submit, they kindof go back in time in terms of the Wicket server-side state. This means that users can have more full use of the back button for undoing state changes without your having to deal with the underlying mess. We don't just allow you to go back (which is what redirect-after-post does), we actually help you revert the state to match the original state that rendered a page in the browser cache. This feature isn't for every page or every application, but it can be quite handy. I hope this explanation makes sense.
  37. Why don´t just apply a "redirect after post" pattern here ? IMHO it would be a much cleaner design.

    The feature you are looking at isn't related to the "redirect after post" pattern. The back button feature talks about the behavior of the web application when someone navigates through your application, and then presses the back button (several times), and then submits some data into your application.

    The browser doesn't tell your application that the back button has been pressed, so your application, should it have no back button support, will be in the state of the last page submitted to the application. So for instance, the browser submits the addition of a CD to a shopping cart, when your application thinks it should receive a shipping address.

    Now, as for the 'redirect after post' pattern, Wicket supports several flavors for doing page submits:
      o post and render in one pass (plain vanilla 'post' pattern)
      o post and render to buffer in one pass, redirect to buffered response (serverside behaves like plain vanilla 'post' pattern, but client side behavior seems like 'redirect after post'
      o post and redirect to render (the 'redirect after post pattern)

    The first variant is the most efficient one, as everything is done in one pass, but it suffers from the double submit problem, and your user gets the annoying 'POST' popup warning.
    The second strategy option handles both the action- and the render part of the request in one physical request, but instead of streaming the result to the browser directly, it is kept in memory, and a redirect is issue to get this buffered result (after which it is immediately removed). This option currently is the default render strategy, as it shields you from the double submit problem, while being more efficient and less error prone regarding to detachable models.
    The last strategy first handles the 'action' part of the request, which is either page construction (bookmarkable pages or the home page) or calling a IRequestListener handler, such as Link.onClick. When that part is done, a redirect is issued to the render part, which does all the rendering of the page and its components. Be aware that this may mean, depending on whether you access any models in the action part of the request, that attachement and detachement of some models is done twice for a request.
  38. Just a tip. To "disable" or "discourage" back button usage, we added the following javascript code in the pages:

    <SCRIPT language=JavaScript><!--
    window.history.forward(window.history.length);
    //-->
    </SCRIPT>

    In this way, when user clicks back button, he's "returned" to the page.

    Regards.
    Guillermo.
  39. Just a tip. To "disable" or "discourage" back button usage, we added the following javascript code in the pages:<SCRIPT language=JavaScript><!--window.history.forward(window.history.length);//--></SCRIPT>In this way, when user clicks back button, he's "returned" to the page.Regards.Guillermo.

    I find this approach to be one of the most confusing, backwards, user-deceiving interaction design strategies I've seen. I'm always baffled by sites that display a message like "Please click on link X to go back instead of using the back button". This seems to happen when programmers start designing Web pages.

    The Web is an interesting medium in that it has affinities with print and graphic design as well as with software engineering. For my part, I have a background in both Web design and Java so I try to stay true to the principles and best practices of both fields. This means designing my Web pages for usability and accessibility, and using patterns and agile methodologies when developing in Java.

    I think you have to ask yourself when assembling a Web-based UI for your application, which metaphor am I using for this user interface? For websites, the metaphor is usually a set of "pages" like you would find in a book or magazine. For these "information applications" it makes perfect sense to allow the user to hit the back button as much as they want, after all, why shouldn't you be able to flip back to the beginning of the magazine?

    If your metaphor is something else, like a multi-step wizard for capturing credit card, billing, and shipping information from a customer, then the default back button behaviour becomes problematic. The Post-Redirect-Get (or redirect-after-post if you prefer) pattern works well for me when used with an MVC framework because it allows the user to click the back button without resubmitting the same data twice and without getting the annoying POST prompt from the browser.

    Disabling the back button is a bad idea. It's hard to find a good argument why you would have to do this. Furthermore, Internet users today are already accustomed to browsing static websites that have full back button support, so you're only confusing them by doing this. Software should adapt itself to human factors, not the other way around.

    A good resource is Jakob Nielsen's site, http://www.useit.com.
  40. I think you have to ask yourself when assembling a Web-based UI for your application, which metaphor am I using for this user interface? For websites, the metaphor is usually a set of "pages" like you would find in a book or magazine. For these "information applications" it makes perfect sense to allow the user to hit the back button as much as they want, after all, why shouldn't you be able to flip back to the beginning of the magazine?

    If your metaphor is something else, like a multi-step wizard for capturing credit card, billing, and shipping information from a customer, then the default back button behaviour becomes problematic. The Post-Redirect-Get (or redirect-after-post if you prefer) pattern works well for me when used with an MVC framework because it allows the user to click the back button without resubmitting the same data twice and without getting the annoying POST prompt from the browser.

    Disabling the back button is a bad idea. It's hard to find a good argument why you would have to do this. Furthermore, Internet users today are already accustomed to browsing static websites that have full back button support, so you're only confusing them by doing this.
    I absolutely agree that if you developing hyperlinked document-oriented site, you need Back to work as usual. But let's take your second metaphor, for multi-step wizard. Wizard is a temporary object. What should happen to it when you finished with it? What should you see when you go back? Should you see wizard at all? Should you be able to go back panel by panel, despite that these panels belong to already disposed wizard? Check out this simple wizard. Would be great, if you opened it in new window.

    After you opened it in new window, Back and Forward buttons are not enabled yet. This seems logical, since there is no to go back yet. Try to log in with any username you like. You see an error message, but can you go back to previous page? With most browsers, you cannot, and Back button is still disabled. Click on "New User Signup" link. New panel is displayed, but Back button is not enabled. Please, finish the signup wizard. You can use wizard buttons to go to the next and previous panel. When you click "Done", your username is added to the accounts table, and you automatically log in. See the panel? It tell you that you logged in, and it allows you to log out. Check Back browser button? Is it enabled? It will not be, until you click "Goto homepage" link.

    This wizard is not simply a sequence of pages, which you can navigate back with browser Back button. The wizard is a stateful object with different views, but logically it is only one page: "Signup/Login page". If you are not logged it, you can log in or sign up. If you are logged in, you see login info, and can log out. But *logically it is one page*. You do not need to click back to see stale wizard pages.

    Let's see a simplified example, without signup wizard, just a login page. You can enter incorrect values several times, but it takes you *only one click on Back button* to leave this logical page. With many other web applications you would click Back as many times as you entered a wrong value. Now, log in. You see login info screen with logout button. This is *the same login page*, but now it represents your logged-in status and renders itself differently. Again, only one click on Back button is needed to leave this page.

    This is what I call an "web island". You can jump from island to island, using links. You can go back from island to island using Back button. But while you are on the island, the whole island is treated as one entity. Depending on its state, it can show you different pages, but logically this is still the same resource, and you cannot go "back" from one page of this resource to another. You can only go back from one resource to another resource.

    "Redirect after Post" or, as I prefer to call it now, "two-phase request processing" saves you from POSTDATA situations if you click Refresh. It also saves you from implicit double submit if you go back/forward. The "web island" is an improvement of two-phase request processing. The trick is using the same exact location, where you serve pages from. This makes browser think that it reloads the same page, and it does not add new entry to page history.

    The "web island" trick does not work on Opera, since Opera add *every* page to page history. In this case we fall back to regular two-phase processing, which is still not bad. It protects us from implicit resubmits, but we need to control explicit resubmit from a stale page, because Opera thinks that we really want to see that stale page.

    So, my idea of improving on web applications is to mix two approaches: (1) hypertext document style where each page is a resource, and can be navigated back, and (2) web island style, where one resource can render different pages depending on resource state. Or, and of course the state should be stored on the server. Server state and two-phase request processing is one of the reasons why I am falling in love with Wicket ;)
  41. Of course, if you /want/ to have your wizard support the back button, Wicket's version manager feature can make this really easy to do.

    In fact, wizards were one of the use cases that drove our selection of page version management as a solution to the back button problem. When you go back in a wizard of panels on a page, the whole component hierarchy gets undone. With the UndoVersionManager, the amount of additional state required to track component hierarchy and model changes is not as much as you might imagine (especially with detachable models).
  42. Of course, if you /want/ to have your wizard support the back button, Wicket's version manager feature can make this really easy to do.In fact, wizards were one of the use cases that drove our selection of page version management as a solution to the back button problem. When you go back in a wizard of panels on a page, the whole component hierarchy gets undone.
    Either I don't get it right, or your idea of keeping/restoring state is opposite to mine. Please correct me if I am wrong, but I read this as "go back in page history, load stale page, and modify server state according to stale page", that is, go back in time on server too.

    My idea, is that server always keeps *current* state. It does not matter what browser displays. If cache headers in response and cache settings in the browser are set so that browser shows stale page *without reloading it from server*, that is ok. But in this case when a user tries to resubmit stale page, we need to deal with it, because actual server state does not correspond anymore to page image.

    If cache headers are set no "no-cache, no-store" and browser reloads page even when a user goes back in page history, then pages will always be in sync with server. In this case, when user goes back, browser may show a different content simply because server state has changed. This behavior differs from HTTP spec, but HTTP spec defines behavior for hypertext document, not for web application. HTTP spec does not try to separate these two different types of applications. HTTP got somewhat obsolete, and should be updated, or a well-known big company will roll out its own protocol.
  43. Either I don't get it right, or your idea of keeping/restoring state is opposite to mine. Please correct me if I am wrong, but I read this as "go back in page history, load stale page, and modify server state according to stale page", that is, go back in time on server too.

    Yes, Wicket permits time travel. The server can go back in time to match up a submit or link click from a (potentially) stale page in the browser's cache.
    My idea, is that server always keeps *current* state. It does not matter what browser displays.

    It seems to me that you are trying to change the nature of browsers. Browsers, as a matter of their design, permit access to pages in the cache with the back button. Users depend on this and it should work for them.

    You're really attempting to circumvent the design of web browsers. It might work okay for you in your particular problem arena or for your particular users, but I don't think this is a good general practice to follow, and I doubt if your users will really understand or like what you're doing. This is, of course, a matter of opinion.
  44. You're really attempting to circumvent the design of web browsers. It might work okay for you in your particular problem arena or for your particular users, but I don't think this is a good general practice to follow, and I doubt if your users will really understand or like what you're doing. This is, of course, a matter of opinion.
    Of course, I am not advertising this approach as the best in all cases. But what would you do in the classic case of shopping cart: you are at the checkout point, you payed for goods, server recorded the transaction and charged credit card. The shopping cart as business object is destroyed. Now you click back. What do you expect to see? What do you expect a user to see? Stale shopping cart? What for, to risk that they would submit it again? Will you recreate the whole shopping cart object tree on server? Im my approach the user will simply see a message, that shopping cart was already processed and discrarded. That's it, no harm is done. Again, this is an application, not just a sequence of hyper-documents. HTTP got obsolete, and while some browsers try to stick to obsolete standards, other browsers allow to do more.
  45. Yes, I agree that it's case by case. It could be worth doing what you're suggesting for a high volume commerce site if a business-level decision was made in terms of usability. But I think most of the time it's disconcerting to users because it breaks the browser model that users are used to. I think this is particularly true of wizards where the back button is a great way for the user to back up a step.

    As far as the shopping cart example goes, in Wicket, you might remove versioning information from the page(s) involved once the shopping cart was finalized. Then if the user went back, they'd get a stale page warning if they tried to resubmit. Another approach would be to not version your shopping cart at all. This is something users are fairly used to with shopping carts. Again, case-by-case. Wicket gives you the choice to version or not version your pages. Sometimes transparent back-button support is good. Sometimes it gets in the way. So you just turn if off then.
  46. Now, as for the 'redirect after post' pattern, Wicket supports several flavors for doing page submits
    How about renaming "Redirect After Post" to "Two-phase input" or "Two-phase request processing"? It sounds more sofisticated, and it better reflects the distinguishing feature of this pattern: submit once, render many. Oh, another cool buzzword :)
    post and render in one pass (plain vanilla 'post' pattern)
    Why don't you prohibit that approach? Even if there can be cases when it does not hurt application state, it still pops up the ugly dialog on reload. Considering that you keep state on the server, you can easily drop this method.
    post and render to buffer in one pass, redirect to buffered response (serverside behaves like plain vanilla 'post' pattern, but client side behavior seems like 'redirect after post'
    This is a good one! So, it is possible to reinvent a wheel after all. Wicket looks very promising, I hope you finish the documentation, especially the part which talks abouts submits and server state.
  47. "Why don't you prohibit that approach? Even if there can be cases when it does not hurt application state, it still pops up the ugly dialog on reload. Considering that you keep state on the server, you can easily drop this method."

    in big scalable clusters this may be preferred by some. and even if it's not, it's there for completeness.
  48. Client-Side Sate Storage[ Go to top ]

    I had no idea that was even planned. Is it going to get anywhere near the transparency of the .NET viewstate pattern?
  49. Yet another component-based web framework, suffering from the usual problems of such frameworks (from what I've understood just by reading this thread):
    - dirty URLs (to me, URLs should be clean, readable, immediately understandable and rememberable)
    - state stored in the session: either the state has a *real* session scope (user login, roles, etc.), or it shouldn't be in the session at all. The fact that you have to handle the back button is a design smell to me. Redirect after post should be sufficient. If state can become stale just by going back, then this state should not be in the session at all. You could of course store the component states in the client, but then you would increase the first problems: dirty URLs.

    Call me a has-been if you want, but that's why I love non-component based frameworks such as Struts: they allow me to keep my URLs clean, my state light, and my HTML code readable.

    Just my two cents.

    JB.
  50. Yet another component-based web framework, suffering from the usual problems of such frameworks

    I strongly disagree with you on this point, the issues you mention are not 'problems', but temporary set backs. As the technology matures (when compared to MVC frameworks, component based development is still new), these concerns will be solved.

    I see them as a temporary set back while driving web application development forward, allowing for more complex web applications, developed in less time. Component based frameworks enable the developer to just do that, and in my opinion Wicket excels right there.
    I love non-component based frameworks such as Struts: they allow me to keep my URLs clean, my state light, and my HTML code readable.Just my two cents.JB.

    I think that the industry will move to component based development what so ever, either using JSF, Tapestry, Wicket or .Net. The benefits to be gained are way too big to keep at the current technology. I doubt that in two years the bulk of (new) web development will be done using model2 frameworks. But that is my vision.

    As a side note, I love the way my java code looks when building Wicket applications, when compared to MVC java code. I had the (un)fortunate experience to have to debug an application build with a MVC framework, and was amazed at how much scaffolding is needed for the most mundane tasks.
  51. I had the (un)fortunate experience to have to debug an application build with a MVC framework, and was amazed at how much scaffolding is needed for the most mundane tasks.

    Well ... not exactly needed but I agree some people can design/develop an application in ways that will force them to make compromises later. There are very few ways of developing a web application and keep an eye on anything from back button problem to performance and all the way to security. I actually know a single way to do it and I developed it in few years (2-3) unfortunately :-(.
  52. For those who are reading along, you can ignore this knee-jerk response in the long term. All this and more is scheduled be addressed in Wicket 1.1.

    The URL issue is actually solvable in Wicket 1.0 with some effort. It will be trivial in 1.1.

    The session state issue is already partly addressed with detachable models and PageState notes to compress replicated data in clusters. Client side state, including zero-state will be available in 1.1.
  53. Congratz to the Wicket team, the product is great. They're also very responsive and not only that, but they actually react to community requests also and you can see it in the code/features.

    I've played a little with it and I like Wicket. I'm planning a pilot project with it, I hope it to become the preffered framework for me.
  54. I like what I see. Good work!

    How does Wicket handle form validation? Is there a way to automatically check user input, collect error messages, and then display them to the user in the language of the user's locale?

    I noticed the wicket.markup.html and wicket.protocol.http packages in your API and the XML output format in one of your example. Are there plans to support other markup languages and protocols, such as WML, WAP, and XML over HTTP/HTTPS?

    As far as the URLs are concerned, I agree with JB and I also want clean, memorable URLs. I suppose a servlet filter could intercept HTTP requests and invoke Wicket components behind the scenes. Anything on the roadmap to address this issue?

    My last concern is about session usage. One of my goals is to minimize session state so my applications scale better and support more users with less RAM. Is it possible to move components into request scope? In Struts I find this works well and allows me to serve up my model without the overhead of sessions.

    Thanks,
    Ian
  55. I like what I see. Good work!How does Wicket handle form validation? Is there a way to automatically check user input, collect error messages, and then display them to the user in the language of the user's locale?

    Thanks :) Yes, Wicket supports a powerful validation, type convertion and feedback mechanism. Rather than explain how it works here, take a look at the forminput example that comes with Wicket and also in the Wicket wiki (http://wicket.sourceforge.net/wiki).
    I noticed the wicket.markup.html and wicket.protocol.http packages in your API and the XML output format in one of your example. Are there plans to support other markup languages and protocols, such as WML, WAP, and XML over HTTP/HTTPS?

    We don't have any immediate plans to support these technologies at the current time. The next, 1.1, release will be focusing on improved Javascript and CSS support (including Ajax) plust more options for state management. We may look at other protocols and markup formats after that. THe object-oriented design of Wicket was particularly focused on allowing future additions in this way.
    As far as the URLs are concerned, I agree with JB and I also want clean, memorable URLs. I suppose a servlet filter could intercept HTTP requests and invoke Wicket components behind the scenes. Anything on the roadmap to address this issue?

    Yes, we are looking into this for the 1.1 release.
    My last concern is about session usage. One of my goals is to minimize session state so my applications scale better and support more users with less RAM. Is it possible to move components into request scope? In Struts I find this works well and allows me to serve up my model without the overhead of sessions.Thanks,Ian

    This is one area where Wicket is very different to many other web frameworks. My personal belief is that session size is far less critical than it used to be. In most cases RAM is very cheap and you will almost certainly start hitting processor and i/o bottlenecks before you run out of memory for storing sessions. Even for a very large Wicket application where each user has a 200k session you can still theoretically support approx 2500 user sessions on a machine with 1GB ram!

    Where session size is an issue is for clustered applications which require session replication across the network. Wicket already supports the ability to detach business model objects from the session and an expansion point for controlling the replication of page state. For 1.1 we will be adding additional features such as stateless operation, client based state and so on.
  56. Looks good 2 me[ Go to top ]

    Any plans to integrate with Spring web flows? Both Tapestry and Shale have indicated plans for incorporation.

    As an aside, I think as soon as you have an open Forum like Spring and Hibernate do Wicket will have a much better chance to flourish in the community. Providing a great support forum makes it easy for people to find answers and to provide feedback.
  57. Looks good 2 me[ Go to top ]

    Any plans to integrate with Spring web flows? Both Tapestry and Shale have indicated plans for incorporation.
    There are no plans yet, but you may post an RFE for that. I know there are several people looking at the Spring integration we already have in place (http://wicket-stuff.sourceforge.net). This sounds like something they also can pick up.
    As an aside, I think as soon as you have an open Forum like Spring and Hibernate do Wicket will have a much better chance to flourish in the community. Providing a great support forum makes it easy for people to find answers and to provide feedback.
    We already have a great support forum: the user mailinglist.
    The problem with forums is that they are e-mail unfriendly (especially the sourceforge one). All of the Wicket core members work during the day and can't monitor the forum. This leads to unanswered questions, and a distribution of information (having a mailinglist, forum, trackers, wiki, standard documentation) which makes it hard to find answers. Our preferred method of communication is through the mailinglist, which is already a good place to find information (and is thriving). By publishing the contents of the lists to several archives (mailarchive, gmane, sourceforge mail archive) there are many ways to search the mailinglist.
  58. New slogan for Wicket?[ Go to top ]

    "I too have a wife and kids and have a life, something that gets in the way poring over source and mauals to figure out how good a framework is. I have had "Tapestry In Action" for months but never got past Chapter 1."

    Wicket--for people who have a wife and kids.

    LOL
    Miko
  59. This is ALL wrong[ Go to top ]

    The java web-framework proliferation is ridiculous because it produces lots of partially finished, partially mature frameworks, none of which have a deep component set or market. Stop building frameworks and start building components. Have you seen the .NET component market? It makes java components (including commercial JSF components) look like something from the iron age...
  60. Openness creates diversity[ Go to top ]

    Microsoft takes a completely different approach than does the Java approach. Sure there are positive and negative attributes of both styles, and the Java side is more open and thus more diverse.
  61. This is ALL wrong[ Go to top ]

    The reason I use Java is because I can choose the framework that I'm most comfortable developing in. How much choice do I have in .NET? Oh yea, that's right, there's one.

    And if you want more component developement, you should talk to the people working on the 20 or so model-2 frameworks. Wicket is really only the third component-based presentation framework.
  62. Component development[ Go to top ]

    And if you want more component developement, you should talk to the people working on the 20 or so model-2 frameworks. Wicket is really only the third component-based presentation framework.
    Any JSP development can be component development, if you use <jsp:include>. The catch is that you cannot forward from included resource, because current JSP spec mandates that response stream should be closed if request was forwarded. Thus, if I include a resource (say, Struts action) which forwards to another resource (say, JSP page), then Tomcat, being a reference implementation of JSP, closes the response, and the rest of the main page is not rendered. This is a flaw of current JSP spec, which should be fixed. Then, any included resource with URL can be a component.
  63. Component development[ Go to top ]

    Depends on how you define component development in terms of we apps. If we consider jsp:include to be component-oriented, then even the old versions of PHP (not even object oriented) can be considered as component frameworks. When I think of components I usually think of independent (can be reused across multiple projects), active (meaning that they can process user action on their own to certain extent - like browsing months in a calendar) and statefull (meaning that they have state on their own - calendar itself is responsible for storing the dates chosen by the user,etc). It is hard for me to imagine how a JSP page could fulfil these needs.
    It is also great if the component is a class that I can extend. This is not the case with JSP...
    A couple of months ago I was looking for a good web framework. I think I have looked at all of them (OK, most of them). Wicket was the best. I needed 2 days (including learning wicket from scratch) to develop a expandable tree component that was a nightmare in jsp/struts. I could pack the classes into a jar and reuse them in another project just by adding an import and add() to the page code. Can you get more component - oriented ? :)
  64. Component development[ Go to top ]

    Depends on how you define component development in terms of we apps. If we consider jsp:include to be component-oriented, then even the old versions of PHP (not even object oriented) can be considered as component frameworks. When I think of components I usually think of independent (can be reused across multiple projects), active (meaning that they can process user action on their own to certain extent - like browsing months in a calendar) and statefull (meaning that they have state on their own - calendar itself is responsible for storing the dates chosen by the user,etc). It is hard for me to imagine how a JSP page could fulfil these needs.
    Check out this example of JSP web component. See the "Sign In" table cell? It is JSP/Struts web component, built with Struts Dialogs. This login component is rendered using a completely separate JSP. It is:
    * independent. The only information needed is the URL where to redirect to re-render the component, possibly along with other child components.
    * it processes input by itself (check the URL in the address bar, and url of login form)
    * it is stateful
    It works with current JSP spec, but can be implemented even easier if JSP spec were modified a bit. Now, check the page URL. Try to log in. Use guest/guest as username/password. After you logged in, you see... the same page, and same URL. Notice, that you cannot go "back". After you logged in, master page is updated, the prices are changed, and "Contact Us" menuitem is shown.
    It is also great if the component is a class that I can extend. This is not the case with JSP
    The component you see is a Struts Dialog component, and can be extended.
  65. Wicket is good for my sex life[ Go to top ]

    Seriously, I also have a wife and kid. And the productivity gained from implementing in Wicket is unsurpassed. The extraordinary diagnostics available is worth it alone. OOP isn't bastardized within this framework, it is embraced. Take a look at the goals of the project:

    http://wicket.sourceforge.net/Introduction.html

    And have a look at the DatePicker component, which neatly encompassed Java and Javascript (AJAX), in other words I don’t need to know a damn thing about JavaScript for its benefits. Yes folks, encapsulation.
  66. Wicket is good for your sex life[ Go to top ]

    Wow, adds a whole new interpretation to the concept of "date picker".
  67. That date picker, I think you could sell. Might be tough to debug though...
  68. Too much java[ Go to top ]

    After a few hours' code reading of the samples, here is my thought:

    -- Too much Java - particularly too much swing taste: all those form.add() stuff reminds me of those painful days of programming Swing (well, at least Wicket does not require one to code with layout managers. That's a good thing. ) We need IDE support to alleviate the problem.
    -- I also saw quite a bit of subclassing of those components to add presentation logic.
    -- Too much naming pattern to track: the wicket:id must match those Java components "added" on the form, and also the properties of the model bean. Coding/refactoring that is painful without IDE support.
    -- No central place for defining navigation rules. All I saw is hard-coded forward/redirect in the Java code.

    I haven't checked the Spring integration package yet. I hope I could find something interesting there for injecting business objects.

    For now I'll stay with JSF. While I'm at it, to be able to take whatever the visual designers have done and add business logic behind it is a very positive thing. I hope JSF will be able to deliver that soon (Facelet?).
  69. JSF is strong and formal api, and with lightweight presentation technology like Facelets it will be better than mess of new component based frameworks....
  70. JSF is strong and formal api, and with lightweight presentation technology like Facelets it will be better than mess of new component based frameworks....

    I presented a bit on the framework in Minneapolis this week. Much of my EL work has been incorporated into Sun's Glassfish project, so while I'm at JavaOne, I'm going to be discussing licensing issues in relation to Facelets and the EL-RI and API. It's the only thing I'm waiting on before releasing Facelets.

    Vendor support for Facelets is a non-issue. It's just as easy for them to incorporate Facelets support in their component configs as it is for you to use Facelets.

    Thanks for your interest guys!

    Jacob (Facelets Author)
  71. Re: Facelets[ Go to top ]

    Jacob,
    Facelets really good and clean work. Wish to play (and to work) with Facelets as soon as possible...
    Did you have any info when jsf 1.2 impl will be avalible?

    Regards, Eugene Lucash
  72. Re: Facelets[ Go to top ]

    Jacob,Facelets really good and clean work. Wish to play (and to work) with Facelets as soon as possible...Did you have any info when jsf 1.2 impl will be avalible?

    Regards, Eugene Lucash

    First off, apologies for the OT post to Wicket--

    I just posted a release of Facelets, JSF 1.2 is available from:

    http://javaserverfaces.dev.java.net/

    A release of Facelets is available from:

    http://facelets.dev.java.net/

    If you have any questions or issues, feel free to email me via the facelets project (click on 'jhook' as the project owner)

    Thanks again for your interest! This is an early access release and hopefully I can get other's helping to resolve any bugs.

    Jacob
  73. Too much java[ Go to top ]

    Too much Java - particularly too much swing taste: all those form.add() stuff reminds me of those painful days of programming Swing (well, at least Wicket does not require one to code with layout managers. That's a good thing. ) We need IDE support to alleviate the problem.


    I think some would argue this. I am personally not a fan of JSP/JSF/struts because of all the custom tags in the JSP files - too much markup complexity. The reason I got involved with Wicket is because I prefer to keep my HTML pages as close to pure HTML as possible. I also love the object-oriented approach to Wicket development.

    I agree with IDE support. I would certainly long-term be looking towards some kind of IDE plugin to aid creation of the Wicket pages and then a tool to easily map page components into the HTML markup.
    I also saw quite a bit of subclassing of those components to add presentation logic.

    Internally Wicket uses quite a bit of subclassing in order to provide a powerful default set of components. When you use it to write real applications it is very rare that you need to sub-class the components in this way. In most cases all you need do is supply a model object to a component and implements a listener interface to handle events that happen on that component.
    Too much naming pattern to track: the wicket:id must match those Java components "added" on the form, and also the properties of the model bean. Coding/refactoring that is painful without IDE support.

    This is a slightly incorrect statement. Yes, you do need to ensure that ther Wicket component name in the Java code is the same as the name used in the wicket:id field in the HTML. How is this different from passing named attributes via the request, or referencing form elements defined in XML in things like JSP and Struts?

    One thing that Wicket does do is that it can tell you if there are any components in your Java that are not referenced in the HTML, so the chances of name mismatch are very small.

    The properties of the model beans do not need to match the names of the components/form fields. Yes, Wicket can do a one-to-one mapping if you wish (it saves code) but it is also possible to bind any form component to any model property doing type conversion along the way as well.
    No central place for defining navigation rules. All I saw is hard-coded forward/redirect in the Java code. I haven't checked the Spring integration package yet. I hope I could find something interesting there for injecting business objects.

    Yes, navigation rules are defined as part of the Java code - it works surprisingly well for most applications where flow between pages doesn't change regularly. We are looking at providing other ways of defining navigation rules are part of the 1.1 effort. I think Spring WebFlow has already been mentioned.
    For now I'll stay with JSF. While I'm at it, to be able to take whatever the visual designers have done and add business logic behind it is a very positive thing. I hope JSF will be able to deliver that soon (Facelet?).

    Er, isn't this what Wicket does - only better than JSF? In WIcket your visual designers can code up any HTML pages they want using any HTML editor of their choice. The business team can write any business code they require without needing to be (too) aware of the web layer. Wicket then provides an easy way of linking HTML pages to POJO based business object without requiring massive alterations to either.
  74. Too much java[ Go to top ]

    Too much Java? The problem I have with typical web development too little Java and too much HTML and Javascript.
    Too much Java - particularly too much swing taste:
    It is like Swing? Then I am definitely looking into it.
     all those form.add() stuff reminds me of those painful days of programming Swing
    For me, I would much rather do Swing than most web frameworks.
    (well, at least Wicket does not require one to code with layout managers. That's a good thing. )
    Swing doesn't require layout managers - use an null layout and have a UI just like VB :( . Which reminds me - I prefer Swing to VB.
  75. Too much java[ Go to top ]

    -- Too much Java -
    Quite personal. You must love PHP.
    Coding/refactoring that is painful without IDE support.--

    So, how good is refactoring support of other frameworks? The more configuration files, the more toolsupport you need.
    No central place for defining navigation rules.

    Oh, please stop. Was that ever a problem for you when you built Swing applications? It is just that people are used to thinking like that. It would be a breeze to build in support for e.g. WebFlow, but personally I feel absolutely no itch here.
    For now I'll stay with JSF. While I'm at it, to be able to take whatever the visual designers have done and add business logic behind it is a very positive thing.

    Excellent. We're not trying to be the catch-all framework for everyone. If you like JSF that's fine, we're providing an alternative here; we don't have the illusion we will blow away JSF.

    Wicket targets the niche of developers that hold proper object orientation, clean seperation of concerns, testability, maintainability and tool independency in high esteem. Finally, Wicket is very much model oriented, whereas other frameworks tend to focus on the display side of things only.
  76. Too much java[ Go to top ]

    So, how good is refactoring support of other frameworks? The more configuration files, the more toolsupport you need.

    With JSF there need be only one configuration file, and that can be handled by tools.
    No central place for defining navigation rules.
    Oh, please stop. Was that ever a problem for you when you built Swing applications?

    Not if you use tools to develop Swing GUI applications, but otherwise it certainly can be a problem in building large and maintainable applications.
    It is just that people are used to thinking like that.

    No, it is because the way GUIs are developed has matured. Having navigation embedded in code is not cleanly separating things.
    Wicket targets the niche of developers that hold proper object orientation, clean seperation of concerns, testability, maintainability and tool independency in high esteem.

    I think it is unhelpful to imply that the majority of developers don't appreciate these things.

    I don't mean to sound too negative. My first impression is that there are some nice features in Wicket - especially the component model.
  77. Navigation Rules[ Go to top ]

    Based on the way things are currently done, it's a reasonable criticism of Wicket that it doesn't attempt to separate out navigation from code. But I don't precisely understand what this technique gets you. I think it just kindof evolved through struts because of JSP and that - even without any Wicket tooling - existing IDE searching features ought to be able one to find the connections between pages fairly easily. And I'm at somewhat of a loss to understand what else navigation config files are useful for...

    In any case, there's nothing stopping anyone from building an XML file specification that externalizes navigation in Wicket. In fact, you ought to be able to hide that logic neatly in some base class (NavigatedWebPage or something) and make setResponse final to help prevent code from manually setting the destination page.

    I think the actual logic behind navigation is more complex than can be reasonably expressed in an XML file, and this tends to indicate to me that it's a code thing. So, I'm still fairly unclear on the value of trying to data-drive it. I'm not saying it's not good to do this in /some/ cases. I just don't quite get it as an overall use-this-everywhere kind of design pattern.
  78. Navigation Rules[ Go to top ]

    Based on the way things are currently done, it's a reasonable criticism of Wicket that it doesn't attempt to separate out navigation from code. But I don't precisely understand what this technique gets you.

    The additional level of indirection allows lots of neat things. For example, in JSF the indirection in the XML file can be an expression.

    It also provides something that I think will become increasingly important, which is the ability to re-use the components and model with different rendering technologies. The navigation rules don't have to link web pages...
    I think the actual logic behind navigation is more complex than can be reasonably expressed in an XML file, and this tends to indicate to me that it's a code thing.

    That is why JSF allows expressions in the XML.
    I just don't quite get it as an overall use-this-everywhere kind of design pattern.

    Personally, I really like the idea that navigation isn't hard-wired into code; it allows for things like pluggable replacements for navigation mechanisms.
  79. Navigation Rules[ Go to top ]

    Okay. I still don't like it myself (I think in part because you wind up with code in your data with these expressions), but I think I understand what you see in it and I believe it could easily be implemented as an elegant little add-on to Wicket.
  80. Navigation Rules[ Go to top ]

    Our application definitely has a use case that would benefit from externalised navigation control or in the case of Wicket probably better put as 'declaritive component organisation/registration'. We need to support variations of the same application to different customers within the same installation. This could only work if the knowledge on how to assemble the components is externalised from the code and specified for each customer seperately.

    We've had some success with this using an in house framework but are looking for a wider community based framework to support the same functionality.
  81. Navigation Rules[ Go to top ]

    Tell me of a customer that doesn't want the moon and I will gladly join that profession. As the amount of distinct externalized navigational control increases for each client, inconsistencies will be discovered between various configurations and source will have to be modified to compensate for lack of flexibility in declarative based navigational control.

    You probably will end up with distinct code bases when a client wants it done yesterday. "the quick and dirty" will prevail over "impact analysis."

    Why not abstract away through polymorphic delegators based on role/right authorizations?
  82. Navigation Rules[ Go to top ]

    Our application definitely has a use case that would benefit from externalised navigation control or in the case of Wicket probably better put as 'declaritive component organisation/registration'. We need to support variations of the same application to different customers within the same installation. This could only work if the knowledge on how to assemble the components is externalised from the code and specified for each customer seperately.

    Now, /that/ sounds like an interesting case. You know, the reason for not having declarative navigation in Wicket yet is that we just haven't had the time (Wicket still is little over one year old), and that none of the core developers had the itch to solve it. Furthermore, with Wicket we provide the basis in such a way that things like custom navigation can be implemented on top of Wicket gracefully.

    Your case sounds like it needs more than just declarative navigation though. It is interesting as the company I work for has several web applications that need variants as well. I'd be interested to know more about your specifications. If you are considering Wicket at all, please join the developer's list and start a discussion about it.
  83. Too much java[ Go to top ]

    Not if you use tools to develop Swing GUI applications, but otherwise it certainly can be a problem in building large and maintainable applications.


    Having developed visual components (VCL for Delphi, VBX for VB, and Custom Components for Borland OWL) in a previous lifetime, IMO externalizing state flow via XML or whatever else is a hindrance if the architecture is component based. All this for pretty little boxes with lines crisscrossing through them:

    1. The configuration (map file) files ends up looking like source code in complex systems
    2. Requires engineer to process two resources (source code and map) versus one, which introduces syncing issues.
    3. State flow mapping file could get very hairy in dynamically generated parameters in URLS

    If your developing in a non component based framework, it's worth it for the sake of maintainability as mentioned previously.
  84. Too much java[ Go to top ]

    Yes, and I think with a bit of tooling in NetBeans or Eclipse, you could produce some pretty little boxes and lines anyway.
  85. Too much java[ Go to top ]

    Wicket targets the niche of developers that hold proper object orientation, clean seperation of concerns, testability, maintainability and tool independency in high esteem.
    I think it is unhelpful to imply that the majority of developers don't appreciate these things.

    Hmmm. that sounded more negative than I meant it, sorry. What I do mean is that I don't expect Wicket to 'beat' JSF. I hope for JSF to succeed as I think the way we are currently developing webapplications with Java (with model 2 frameworks that is), is problamatic, and see in my own professional environment that .NET is gaining ground just because of this. That said, I am one of the people that regret that JSF is the framework that came out to be our next webapp development standard, as I care more about the long-term gains I described earlier - for which I think JSF is not helping.
  86. Too much java[ Go to top ]

    -- Too much Java -
    Quite personal. You must love PHP.
    Coding/refactoring that is painful without IDE support.--
    So, how good is refactoring support of other frameworks? The more configuration files, the more toolsupport you need.
    No central place for defining navigation rules.
    Oh, please stop. Was that ever a problem for you when you built Swing applications? It is just that people are used to thinking like that. It would be a breeze to build in support for e.g. WebFlow, but personally I feel absolutely no itch here.
    For now I'll stay with JSF. While I'm at it, to be able to take whatever the visual designers have done and add business logic behind it is a very positive thing.
    Excellent. We're not trying to be the catch-all framework for everyone. If you like JSF that's fine, we're providing an alternative here; we don't have the illusion we will blow away JSF.Wicket targets the niche of developers that hold proper object orientation, clean seperation of concerns, testability, maintainability and tool independency in high esteem. Finally, Wicket is very much model oriented, whereas other frameworks tend to focus on the display side of things only.

    Don't get me wrong, man. I may have sounded too critical, but I just silently recognized all the nice stuff in the current release and I’ll be keeping watching the progress.

    Having been doing Java for (quite) a few years, I just feel Java has become mundane and needs some fresh air. That aside, I was expecting from Wicket things like annotations, which will be a good fit for associating web element and Wicket UI components. In total the complexity of web app programming is not reduced – any savings in the XML configurations will translate to cost in somewhere else, in the case of Wicket, it’s in the Java code. The procedural nature of Swing’s way of UI laying-out does not quite convey the final UI intuitively. UI in its core is of declarative nature. That’s why people try to come up with solutions like XUL etc. Admittedly, a perfect solution is still yet to come.

    When I wrote Swing one thing I really hated to see was all those panel.show() (or something like that) scattered in the event handlers. I wanted a centralized event handling and navigation model. At that time I did not find any. That’s one of the areas that web development frameworks are more advanced than the classical Swing, IMHO.

    The wiring of the HTML tag with Wicket component purely by the ID makes it hard/trickier for IDE to track which is which at design time. We all know IDEs use all sorts of tricks/patterns to support visual Swing designing. For JSF, the faces-config.xml works as the central hub and tie everything together and one knows how the application works by simply checking out this file. I found it hard for me to have a bird’s eye view of what’s happening in some of the Wicket samples.

    In addition to the navigation issues, what about session/application-scoped models? It looks like all the models are page scoped…

    Again, all the above is based on a few hours' sample reading. It's quite possible that once I lay my hands on it and the "feel" is actually better than the “look”.

    I hope Wicket will set the standard high and take advantage of the zero baggage, including Swing. It would be disappointing to target only a niche of the developers.
  87. Too much java[ Go to top ]

    I hope Wicket will set the standard high and take advantage of the zero baggage, including Swing. It would be disappointing to target only a niche of the developers.

    We'll try. There is no perfect framework yet as you said, and surely Wicket is not the silver bullet either. We hope to contribute to lifting the Java community to the next step (that is IMO component based frameworks). Hopefully in a few years we will have the next framework (JSF 2?) that takes the different approaches seriously and comes up with a solution that everybody is happy with. If that is possible at all ;)
  88. Too much java[ Go to top ]

    UI in its core is of declarative nature. That’s why people try to come up with solutions like XUL etc.

    Why is that? If UI in its core is declarative we wouldn't need anything more than HTML right? The truth is in the middle and very much depends on the (custom needs of) interactivity of the UI versus the ammount of (static) information to be displayed.
  89. please stop....
  90. we dont need any more web frameworks[ Go to top ]

    please stop....
    You are right. We should just give up trying to make web application (NOT web site) development, maintenance and deployment easier. :)

    Sadly, some deployment environments make it impossible to do anything else but webapps. In that light I cheer on the development of frameworks like Wicket, Echo and JSF.
  91. we dont need any more web frameworks[ Go to top ]

    framwworks written over night lack the quality and ease of use. i dont see this framework doing anything better to make it simple to develop web apps.
    It just adds one more row in the thousands of half baked ideas in the list of opensource projects. why dont you resuee somehting already done by srping, apache etc etc etc and then work on top of it. just a waste of time... i know its harsh to say but its the truth . there is nothing about monopoly here - its like you go to buy a bread and you see 1000000 different breads - although 89% of people dont switch the type of bread they eat in their lifetime - its white or wheat... i guess u r the fools who fall in that 11% who dont know what they want and dont let others find their simple "always works" bread easily. you guys are no different than the dot comers who sold coffee online
  92. Yeah, we've been through this before. And yet, we're getting thousands of downloads and tens of thousands of visitors (and we haven't even hit JavaOne yet). Must be all those people who are so satisfied with the status quo?

    Those who have tried Wicket out in depth generally have very glowing things to say about it. And there seem to be hundreds of these Wicket "fools" out there now, just wasting their time.

    It's harsh to say, but you haven't got the foggiest idea what you're talking about.

    In the event that you'd like to learn something, you could start here:

    http://wicket.sourceforge.net/Introduction.html
  93. Yeah, we've been through this before. And yet, we're getting thousands of downloads and tens of thousands of visitors (and we haven't even hit JavaOne yet). Must be all those people who are so satisfied with the status quo?Those who have tried Wicket out in depth generally have very glowing things to say about it. And there seem to be hundreds of these Wicket "fools" out there now, just wasting their time.It's harsh to say, but you haven't got the foggiest idea what you're talking about.In the event that you'd like to learn something, you could start here:http://wicket.sourceforge.net/Introduction.html
    Tons of downloads can mean a lot of things and may not really result into the framework being popular. Creating a simple silly website versus standing upto a large size website - people wont think of wicket. ITs just to paly around on the weekend and throw it and go back to good old working ways.
    Lets see time will tell. I dont want to discourage you from wasting your own time and i wont commment anymore & waste my own time. Happy ???
  94. Yeah, we've been through this before. And yet, we're getting thousands of downloads and tens of thousands of visitors (and we haven't even hit JavaOne yet). Must be all those people who are so satisfied with the status quo?Those who have tried Wicket out in depth generally have very glowing things to say about it. And there seem to be hundreds of these Wicket "fools" out there now, just wasting their time.It's harsh to say, but you haven't got the foggiest idea what you're talking about.In the event that you'd like to learn something, you could start here:http://wicket.sourceforge.net/Introduction.html

    Oh yeah forgot to mention
    if you throw in struts config handlers and add some tapestry to it and then write some ugly java code which determines a lot of your presentation then u have wicket framework my friend.

    Amen !!!
  95. yeah forgot to mention if you throw in struts config handlers and add some tapestry to it and then write some ugly java code which determines a lot of your presentation then u have wicket framework my friend. Amen !!!

    No, you don't.

    If you're really this jaded, you should do yourself and everyone you work with a favor and find a new occupation -- one that you actually care about.
  96. framwworks written over night lack the quality and ease of use. i dont see this framework doing anything better to make it simple to develop web apps. It just adds one more row in the thousands of half baked ideas in the list of opensource projects.
    OK, you definitely haven't paid attention. Wicket isn't written over night, Wicket is about quality and ease of use. Have you even read anything about Wicket, or are you just complaining that someone came up with a good idea?
    why dont you resuee somehting already done by srping, apache etc etc etc and then work on top of it. just a waste of time... i know its harsh to say but its the truth .
    All those frameworks you are talking about (except maybe Tapestry, but I have no evidence that you have looked at that one either), are MVC frameworks, which is a totally different technology. Look up and see the world of tomorrow: JSF, Tapestry and Wicket are here to stay and will shape the web applications of the future. The technological gap between component based web frameworks and MVC web frameworks is too big to even consider rescue (is that what you mean?) them.

    Why reinvent the wheel? This time it rolls smoother, makes you go faster and steer lighter. That's why!
  97. framwworks written over night lack the quality and ease of use. i dont see this framework doing anything better to make it simple to develop web apps. It just adds one more row in the thousands of half baked ideas in the list of opensource projects.
    OK, you definitely haven't paid attention. Wicket isn't written over night, Wicket is about quality and ease of use. Have you even read anything about Wicket, or are you just complaining that someone came up with a good idea?
    why dont you resuee somehting already done by srping, apache etc etc etc and then work on top of it. just a waste of time... i know its harsh to say but its the truth .
    All those frameworks you are talking about (except maybe Tapestry, but I have no evidence that you have looked at that one either), are MVC frameworks, which is a totally different technology. Look up and see the world of tomorrow: JSF, Tapestry and Wicket are here to stay and will shape the web applications of the future. The technological gap between component based web frameworks and MVC web frameworks is too big to even consider rescue (is that what you mean?) them.Why reinvent the wheel? This time it rolls smoother, makes you go faster and steer lighter. That's why!
    you guys think everyone in the world who have invested millions of dollars in different techniology would just one day wake up and hug you and decide to use wicket. How - Well its created by some folks who dont sleep in the night , think they have the best framework and if u look into the details its jst same old struts + tapestry + spring ideas ...
    Have some sleep guys . the world is fis on its current wheels.
    Amen !!
  98. you guys think everyone in the world who have invested millions of dollars in different techniology would just one day wake up and hug you and decide to use wicket.

    with billions invested in C++, who needs this java crap? -- you, 10 years ago
  99. you guys think everyone in the world who have invested millions of dollars in different techniology would just one day wake up and hug you and decide to use wicket. How - Well its created by some folks who dont sleep in the night , think they have the best framework and if u look into the details its jst same old struts + tapestry + spring ideas ... Have some sleep guys . the world is fis on its current wheels.Amen !!

    Woa. That's one angry dude! You make big assumptions here. What do you think, it is all hobby? No man, the company that I work for makes large scale webapplications on a daily basis. We have been looking for a framework that solves the problems we experience when using web mvc frameworks. Wicket was by far our favorite, even though it was in alpha stage back then. But it answered to our needs of simplicity (train new programmers, but teach them proper OO, don't turn them in VB monkeys), reusability, testability and maintainability perfectly. After a while we got active on the project (that's the open source way) because we need it to be good enough for our projects, and because we actually care about our profession and feel that there still is a lot that can be done better in the IT sector where more than half of the projects fail to at least some extend.
  100. KISS[ Go to top ]

    Once upon a time engineers understood the KISS concept and its pros. Nowadays, "BIGGIE SIZE IT" seems to be the prevailing sentiment for HAPPY MEALS and frameworks.

    The educational system here in the US has turned into a breeding ground of drones. It's no wonder we have Hitler II running the country now.
  101. KISS[ Go to top ]

    The educational system here in the US has turned into a breeding ground of drones. It's no wonder we have Hitler II running the country now.
    Must be if you think W and Hitler are comparable in the slightest. Very sad.
  102. KISS[ Go to top ]

    Mark,

    Reference link in context to my statement:
    http://semiskimmed.net/bushhitler.html

    And while you’re at it, turn off FOX NEWS. Enjoy current events from literature beyond 3rd grade level comprehension.
  103. we dont need any more web frameworks[ Go to top ]

    http://raibledesigns.com/page/rd?anchor=java_jobs_broken_down_by

    I think this is one of the better bits of evidence out there as to who's really taking off. One thing to note is that Tapestry has been out longer, but JSF already has a much larger job share. Once Shale is out there, I can imagine a slow transfer from Struts to JSF.

    Struts seems to be winning because of the knowledge base that's out there, but between Spring and JSF, it's the 'flex-factor' with POJO's that makes them so appealing. With JSF 1.2 and the EL-API's, you can pretty much wire anything under the sky into your presentation-- from Spring, PicoContainer, InitialContext, or Managed Beans, just to name a few...
  104. My Observations[ Go to top ]

    I'm pretty excited about Wicket. So I started to write about my experiences while evaluating this framework.

    Read about it on my blog. More coming up later.

     S.
  105. Wicket looks promised... but personally I have some concern about:

    (1) How about testability of component ? Is it possible to write unit test or
    integration test (like StrutsTestCase) ?

    (2) Security: for MVC2 framework with 'beauty' URL, it's quite easy to control
    who can access specific resources. Does Wicket provide alternative approach or
    just leave all security concern in business layer ?

    (3) Integrate with others frameworks, especially with Spring. Is it possible to inject business services into components ? Does it work with page layout frameworks, such as SiteMesh ?
  106. (1) How about testability of component ? Is it possible to write unit test orintegration test (like StrutsTestCase)

    Yep, quite easy. We deliver special classes that makes testing Wicket pages a breeze with the core framework.
    (2) Security: for MVC2 framework with 'beauty' URL, it's quite easy to controlwho can access specific resources.

    Though I can see why people find that handy (it's what I have used for years), Wicket tries to move you away from thinking in URL's. We have excellent build-in support for security that is tight and object oriented, so you probably won't miss the ability to declare auth stuff on urls. That said, we plan nicer url support for 1.1. (out due september).
    (3) Integrate with others frameworks, especially with Spring. Is it possible to inject business services into components ? Does it work with page layout frameworks, such as SiteMesh ?

    Yes it works together with Spring. We have an integration project for that, and we have several members that use Sprint.

    Now, for SiteMesh etc... I've looked into it a bit. Wouldn't be too hard to support, though I wouldn't want to support it as part of the core project as it - again - would move us too much in the 'thinking in url's' direction again. You don't need that kind of frameworks, as you have all the page composition options you need build in with Wicket.
  107. Is Wicket anything like Scope?[ Go to top ]

    Scope (http://scope.sourceforge.net/)looks like it made a stab at a swing-like, component based web MVC architecure three years ago. Although it looks like there is no more activity in the project, not quite making it to a v2, it does appear as though it was a substantially way ahead of it's time. I wonder what it lacked that Tapestry and Wicket have now that will enable them to be more successful?
  108. Great job on the presentation at JavaOne! Simplicity is a great advantage of Wicket's, but the API should open itself up a little bit more for delegation and extensibility as a few people had commented.

    Jacob
  109. The API should open itself up a little bit more for delegation and extensibility as a few people had commented.Jacob

    I'm afraid I was bussy talking with HLS, so I missed those questions. Could you give any specifics? (join the mailing list maybe? ;))