Home

News: Wicket: Do we need yet another presentation layer framework?

  1. The answer could be yes. The new Wicket project at CodeHaus, written by a former member of the Swing UI engineering team at Sun Microsystems, takes a unique and simple approach to web UIs.

    Like Tapestry, Wicket decorates HTML tags with a special name attribute. But unlike Tapestry, it is dirt simple, having no further HTML syntax, no XML configuration files and a much simpler Swing-like component model.

    Wicket was also designed for easy Hibernate integration. With an IDE plugin or two, a good basic idea like this could just turn out to be a better idea than JSP or JSF, especially in a world moving away from legacy J2EE practices. Wicket is Open Source under the Apache Software License.

    Visit the Wicket home page

    Threaded Messages (86)

  2. Checked it out real quick. He mentions Tapestry and Echo. I've not use Tapestry but I have used Echo. While it looks good, I'm not sure what gains there are over Echo. Echo apps can be laid out with HTML. And it can use CSS too.
  3. Echo[ Go to top ]

    I think one of the main differences between Echo and Wicket is that Wicket is much more presentation agnostic. In Echo, you code more literally like Swing with events and layouts and the like. For example, take a look at some of the echo tutorials like the code at the bottom of this page: http://www.nextapp.com/products/echo/doc/tutorial/grids_layout.html. To a Swing programmer, this will feel familiar. But it's a lot of verbosity and a lot of display-related parameters to tweak in code. In Wicket, anything that's related to the layout or presentation is always pure HTML that you can WYSIWYG preview or edit with DreamWeaver. In my view, this is a good thing because look and feel should be handled by a talented design person, not a coder.
  4. Echo[ Go to top ]

    http://echopoint.sourceforge.net/LinkedArticles/UsingHtmlTemplatePanel.html
  5. Echo[ Go to top ]

    and http://echopoint.sourceforge.net/LinkedArticles/CascadingStyleSheets.html
  6. Differences[ Go to top ]

    While it is possible to create HTML based layout components in Echo, the top level is still some kind of application constructed in code. Wicket's simpler approach means that the whole page is going to be previewable and editable by a designer, not just a sub-component of the page. This means that something like "CSS support" is simply not required in Wicket because HTML pages can always have CSS support. You can do anything in Wicket that you can do in HTML and in exactly the way you always used to do it. I think that kind of simplicity is valuable.

    Still, your point is well taken. Echo does have an answer to this issue even if it is not quite the answer I want. I want the whole framework to be based around this "HTML-panelness".

    There are other significant differences between Echo and Wicket that require in-depth knowledge of both frameworks. Since I don't know Echo deeply, I would assume that nobody can adequately compare the two. One place I would look though is in Wicket's state management, form validation and Hibernate support. For example, Wicket's way of updating models on a form submission is different from the usual model. And I think it's different in a good way.
  7. Differences[ Go to top ]

    Fair enough. Maybe someone who has looked indepth at both can provide more insight.
  8. Yes[ Go to top ]

    It will take some time for people to absorb what I've done here. I believe the simplicity and power of it will prove worthwhile. But at this moment, I'm the only one who knows Wicket inside and out. And unfortunately, my knowledge of Echo is not deep at all. So it will take some time before a nuanced comparison can be articulated. As an Echo person, I would be interested in your comments on Wicket's architecture if you can make the time to look at it. Cheers!
  9. Yes[ Go to top ]

    It will take some time for people to absorb what I've done here. I believe the simplicity and power of it will prove worthwhile. But at this moment, I'm the only one who knows Wicket inside and out. And unfortunately, my knowledge of Echo is not deep at all. So it will take some time before a nuanced comparison can be articulated. As an Echo person, I would be interested in your comments on Wicket's architecture if you can make the time t look at it. Cheers!
    While I don't know Echo in and out, I think I know it well enough to make a comparison. I check out Wicket when I get a chance. BTW, don't get me wrong, it does look good and for projects where I need UI help, it might do the trick. Keep up the good work.
  10. Yes[ Go to top ]

    Thanks!

    BTW, Wicket is still Alpha code and the design is not totally locked down yet. If you discover important or interesting features missing from Echo that could be incorporated into Wicket in an elegant way, I'm all ears. In fact, I spent a few months lurking on the Tapestry mailing list basically looking for complaints about Tapestry that I could address in Wicket (perhaps I should have done the same with Echo!). I was surprised by how many things came up. I added everything from skins support to easy ways to write pages to files.
  11. Try EchoStudio[ Go to top ]

    Wicket's simpler approach means that the whole page is going to be previewable and editable by a designer, not just a sub-component of the page.
    Check out EchoStudio. You can create content like in any other RAD-Tool and it has a WYSIWYG-Editor with preview.

    Echo has no build-in hibernate-support, but I don't think it is a must for a UI-framework to has a build in persistent support.

    We use Echo+Spring+Hibernate and it works awesome.

    - Michael
  12. IDE Pluginst[ Go to top ]

    That looks good! I'm hoping there will be an Eclipse IDE plugin for Wicket before long. The cool thing about Wicket is that it is so simple that all you would need are a couple of simple extensions to the Eclipse HTML editor to make it easy to add components and check component wiring. Of course, if you don't want to use a RAD tool, with Wicket you can always go WYSIWYG in DreamWeaver.
  13. HtmlTemplatePanels[ Go to top ]

    Another thing that occurs to me about Echo's html component workaround is this:

    Can you structure tables of components that edit a list this way?

    In Wicket, you can create components (or use them) that do programmatic things like this while still keeping 100% design control in the hands of the person with Dreamweaver.
  14. And...[ Go to top ]

    you can arbitrarily nest these components, including "Border" components which can be used to easily, even transparently, add your designer's navigation HTML.
  15. I love Tapestry, and would recommend it to anyone, but a solution which is similar but uses Java instead of XML configuration files would fix what is to me an irritation with Tapestry.
  16. this is going absurd..
  17. this is going absurd..
    Actually it seems to, finally, be going in the right direction.
  18. Innovation is important. No existing web framework is perfect, and I doubt that any can be perfect for all types of applications. So I think we should welcome people trying new approaches.
  19. As shown on this thread, one of the major advantages (usually) is a new presentation framework tends to be more open to comments and suggestions. Also its more quick to adapt.

    Existing frameworks as they grow big tend to be harder to change. Also with only a few people who use the product, its easier for the developer to talk and support them. Once it grows to the point where you have to support people who keep on asking "new user" type questions 90% of the time, its going to be harder to support and adapt to change I think.
  20. I like it so far[ Go to top ]

    I'd really like a component-oriented web framework that is both simple and flexible. From a cursory glance, it looks like Wicket is something I should evaluate further.

    The good news is that there is no pressure, because I'm blessed enough to be working on an "rich internet application". I'll take that over any kind of web app, any day of the week.

    God bless,
    -Toby Reyelts
  21. I like it so far[ Go to top ]

    If you want to work with a Swing-like application framework why dont you try WebOnSwing that is not Swing-like, is Swing!!
    WebOnSwing reuse Swing technology to create web pages and provides among other things:

    * Template engine that works with pure html files with no special tags, very similar to this aproach.
    * Server side state and client state is fully supported and very easy to use, you can keep a Swing window in window session if you are working with desktop-like applications or you can make your pages fully stateless and put all window state (as viewstate) in html page if you work with web-like applications. The state is handle automatic and the only thing you have to provide is each component data that want to be persisted.
    * You may use any Swing editor to create your pages, all IDEs has its own Swing editor so you can develope on WebOnSwing in your favorite IDE.
    * The reusability of WebOnSwing components is the same of Swing components.
    * You can use your browser back button!! Inclusive when you open multiple modal windows, because you can tell WebOnSwing to store each window state in html page
    , allowing to get back to any parent window! With no data in session! Fully stateless.
    * .NET like validation framework very easy to use.
    * Provides a really UI abstraction layer that hides all HTTP/HTML issues
  22. Wicket vs. Swing[ Go to top ]

    When I say that Wicket has a "Swing-like component model", I do not mean to imply that it *is* Swing. Nor would I want Wicket to be Swing! I think Wicket is a lot better than Swing because its structure is more minimal and it is targeted at a particular purpose (working with markup servers).

    What's Swing-like about Wicket is that all the logic is contained in components that are structured in a containment hierarchy. Beyond that there's not a lot of comparison. Crucial design decisions in Wicket were very different from those made in Swing. Wicket does not have, for example, an event queue. There are really no events in Wicket (although there are callbacks) because events are a GUI concept that is not needed in a web framework. I could go on at length about the differences between Wicket and Swing, but I think you get the picture.
  23. Wicket vs. Swing[ Go to top ]

    You really think that having a more minimal structure and targeted for a particular purpose is an architecture better than Swing?
    Swing is very abstract because it use models inside each component, so you are able to implement the view the way you want!! When you develope under Swing the targeted UI is unknown and could be any. Look at SwingWT as an example of how versatile is Swing architecture.
    Also WebOnSwing is using right now Swing classes that comes with JDK, and we almost finish a version that works with either GNU-Classpath Swing implementation or SwingWT implementation, just switching the Swing base you could enhaced everything! With no recoding or changing packages names.
    Version 1.0.2 is using a Dummy look&feel, Toolkit, GraphicsEnviroment, etc that doesnt do anything, so neither an EventQueue or other Swing-Desktop specific handler is required or instanced.
    WebOnSwing really dont want to reinvent the wheel, so it use a well know architecture as Swing, with many years of usage to unified the application process (desktop and web) and let the developer work with prexisting components, windows, applications, editors, tutorials, manual, documentations, bug fixes, etc, etc...
  24. Wicket vs. Swing[ Go to top ]

    Yes, I do. Sometimes a specific tool is better than a general one.

    If I was planning to port an application between the desktop and the web, I would definitely look into Swing and WebOnSwing.

    But if I'm just writing a web UI, what I really want is a very simple and flexible framework that gets the job done cleanly and quickly. I want something that is focused on making markup applications easy (and not just HTML/HTTP, BTW), and I want to use DreamWeaver, not an IDE to build the UI. But above all, I really don't care if the UI is portable. I'd rather have simplicity than abstraction.

    The nice thing about re-inventing wheels is that you can sometimes make them *rounder*. ;-)
  25. I like it! Awesome![ Go to top ]

    I think its an awesome way to deal with this whole web UI framework mess. I am happy to see someone take a simple and clean approach to the whole problem, and come up with a transparent POJO solution.
    I like the direction the framework is going. And good documentation and examples from the beginning, unlike the other codehaus projects.
    Just hope that as you pile on features, it does not become complex like the other frameworks...

    Thanks, keep it up, can't wait to try it out...
  26. Wicket vs. Swing[ Go to top ]

    Yes, I do. Sometimes a specific tool is better than a general one.If I was planning to port an application between the desktop and the web, I would definitely look into Swing and WebOnSwing.But if I'm just writing a web UI, what I really want is a very simple and flexible framework that gets the job done cleanly and quickly. I want something that is focused on making markup applications easy (and not just HTML/HTTP, BTW), and I want to use DreamWeaver, not an IDE to build the UI. But above all, I really don't care if the UI is portable. I'd rather have simplicity than abstraction.The nice thing about re-inventing wheels is that you can sometimes make them *rounder*. ;-)
    I think that you dont understand WebOnSwing concept.
    Wicket is a framework for web developement, that use pure html as templates and has a Swing-like style.
    And WebOnSwing is framework for web development and desktop development, it unifies both worlds!. With WebOnSwing you have the same simplity of Wicket, works also with pure html files (that can be also edited in the same way with Dreamweaver). And in addition you may use a visual editor to create pages and then apply html templates that comes from the designer to change the look of the application (take a look at validation tutorial http://webonswing.sourceforge.net/xoops/modules/wfchannel/index.php?pagenum=6 ).

    BTW can you tell me why you think that developing with Wicket is more clean, quickly and simple than developing with Swing or WebOnSwing? Please give me some examples!
  27. Wicket vs. Swing[ Go to top ]

    Or if you dont like how Eclipse VEP editor generate Swing code, take a look to WebOnSwing Developer's Guide at http://webonswing.sourceforge.net/xoops/modules/wfchannel/ where you can find examples of how simple is development in WebOnSwing. There are examples of a simple calculator, javascript listeners, page state management, validation framework tutorial, automatic modal windows management, page navigation and template engine.
  28. Wicket vs. Swing[ Go to top ]

    As someone who worked on Swing, I think I do understand. To get a flavor for clean and simple Wicket, take a look at the examples:

    http://wicket.codehaus.org/Examples

    and then download the SDK and look at the full range of examples:

    http://wicket.codehaus.org/Download

    I think the comparison with WebOnSwing design time is a little unfair right now because there isn't yet a Wicket plugin of any kind. But I was just talking with someone who wants to write one this afternoon... so that may not last forever.
  29. Wicket vs. Swing[ Go to top ]

    ...But if I'm just writing a web UI, what I really want is a very simple and flexible framework that gets the job done cleanly and quickly....
    As someone who worked on Swing, I think I do understand. To get a flavor for clean and simple Wicket, take a look at the examples:http://wicket.codehaus.org/Examplesand then download the SDK and look at the full range of examples:http://wicket.codehaus.org/DownloadI think the comparison with WebOnSwing design time is a little unfair right now because there isn't yet a Wicket plugin of any kind. But I was just talking with someone who wants to write one this afternoon... so that may not last forever.
    Yes, perhaps you work with Swing but not with WebOnSwing, fist you tell me that developing in Wicket is more simple, quickly and clean, but now you are not able to make a comparison?
  30. Stop dumb comparisons[ Go to top ]

    ...But if I'm just writing a web UI, what I really want is a very simple and flexible framework that gets the job done cleanly and quickly....
    As someone who worked on Swing, I think I do understand. To get a flavor for clean and simple Wicket, take a look at the examples:http://wicket.codehaus.org/Examplesand then download the SDK and look at the full range of examples:http://wicket.codehaus.org/DownloadI think the comparison with WebOnSwing design time is a little unfair right now because there isn't yet a Wicket plugin of any kind. But I was just talking with someone who wants to write one this afternoon... so that may not last forever.
    Yes, perhaps you work with Swing but not with WebOnSwing, fist you tell me that developing in Wicket is more simple, quickly and clean, but now you are not able to make a comparison?
    Please stop having dumb comparisons. Swing is extremely complicated, and very verbose for doing even the simplest of tasks. That is why everyone has rejected it for SWT. And, using swing for web development is an even worse idea.

    Wicket is clean, simple and elegant. I don't think you should even be trying to compare the two.

    If you wish to have your own announcement, create your own posting. Otherwise, stick to comments that make sense.

    Don't take away from the merit of another project.
  31. Stop dumb comparisons[ Go to top ]

    ...But if I'm just writing a web UI, what I really want is a very simple and flexible framework that gets the job done cleanly and quickly....
    As someone who worked on Swing, I think I do understand. To get a flavor for clean and simple Wicket, take a look at the examples:http://wicket.codehaus.org/Examplesand then download the SDK and look at the full range of examples:http://wicket.codehaus.org/DownloadI think the comparison with WebOnSwing design time is a little unfair right now because there isn't yet a Wicket plugin of any kind. But I was just talking with someone who wants to write one this afternoon... so that may not last forever.
    Yes, perhaps you work with Swing but not with WebOnSwing, fist you tell me that developing in Wicket is more simple, quickly and clean, but now you are not able to make a comparison?
    Please stop having dumb comparisons. Swing is extremely complicated, and very verbose for doing even the simplest of tasks. That is why everyone has rejected it for SWT. And, using swing for web development is an even worse idea.Wicket is clean, simple and elegant. I don't think you should even be trying to compare the two.If you wish to have your own announcement, create your own posting. Otherwise, stick to comments that make sense.Don't take away from the merit of another project.
    Sorry but I dont agree with your opinion about Swing... I think that Swing is extremely simple and abstract, and if you take a look to WebOnSwing Developer's guide or learn more about Swing you will realize that Wicket isn't more simple, elegant or clean, is just that examples a components of Wicket are too simple right now.
    And I repeat that WebOnSwing is not coupled to Swing and this means that you could create your own components as simple as you need or think...

    But all this things could be said and not necessary be true! So take a look to both frameworks and try to figure out witch is more simple, elegant, clean, abstract, better architecture, decoupled, extensible, etc, etc. The source code is there....
  32. Wicket vs. Swing[ Go to top ]

    I'm not sure that using Swing as a toolkit for developing web UIs is at all a good idea. There have been various "your native toolkit becomes your web toolkit" (WebCream comes to mind) things over the years, but using the resulting applications are usually pure hell to use if they are not trivial. The problem domain of a web application is not the same as that of a desktop app, and any framework that tries to conflate the two is going to have non-trivial problems (performance, too many conversations with the server, back button behavior, handling of custom components, handling poor connections gracefully, etc. - all problems that no desktop UI framework takes into account, because desktop toolkits simply don't have those problems). I'd say if you want Swing, write an applet. WebOnSwing seems like a nice idea, but any solution to web apps that pretends that the network isn't there is going to produce seductively nice prototypes that fall down in real life use on real life networks.

    Wicket seems to me very nice, simple and an elegant solution for its problem domain. I am primarily a desktop UI developer, (and, full disclosure, a friend of Jonathan's since grade school) but if I were doing a web app, I would definitely take a look at Wicket.

    In the history of computing, good solutions come slow, standing on the shoulders of earlier solutions that explored the same problem domain and grew some warts in the process. Remember that it took 20 years to really work out what a String should be (null terminated? ASCII? Unicode?); while we take "files" for granted, there was a time when whether there should even *be* files was a matter of debate.

    So, we're starting to see some mature solutions to the problem domain of web apps, designed by looking hard at the problems in other framworks and a determination not to repeat them. Jon's done a very good job here, and Wicket is definitely worth a look.
  33. Wicket vs. Swing[ Go to top ]

    You are comparing WebOnSwing with WebCream and both frameworks are completly different!
    WebCream is an automatic migration tool for Swing applications to web, and WebOnSwing use Swing components for web applications!!!! WebOnSwing has a layer that can handle all web specific issues!
    You can do everything you want in web, you have total control of this, but is DECOUPLED!!
    In Swing layer you dont know anything about web environment but there is another layer that handles cookies, http session, html, html templates, page state persistence, web renderers, etc...
    I think that having an abstract layer that decouples from html/http is very usefull because your applications do not depend of the final UI environment, so you may interchange it when you want or the technology require. For example if HTML/HTTP change in the future, and Macromedia flex becomes the standard, Wicket application will no run under this new standard but WebOnSwing applications will!! You will only have to change the second layer that handles html rendering and html events and everything will run in the same way!
  34. Wicket vs. Swing[ Go to top ]

    I forgot to tell another interesting feature of WebOnSwing...
    WebOnSwing is not coupled to Swing! (maybe only the name :) ), any component hierarchy can be wrapped! Or you can develope your own component hierarchy implementing some interfaces!
  35. Wicket vs. Swing[ Go to top ]

    I forgot to tell another interesting feature of WebOnSwing...WebOnSwing is not coupled to Swing! (maybe only the name :) ), any component hierarchy can be wrapped! Or you can develope your own component hierarchy implementing some interfaces!
    Can you change the look and feel of the component as easy as changing the HTML of that component? I find tapestry to be very difficult to implement something like tabs.
  36. I think its a good idea that we have another presentation framework built. At the very least it would give ideas to the more popular presentation frameworks to extract.

    Glancing through the website, it is a certainly a step in the right direction (at least similar to that of ASPX and Tapestry). Although its still pretty newish.

    At the moment, if I were to build a new application, I am leaning on using Tapestry as my application framework. My main problem with JSP and tag based pages is it usually forces the web development team to build the templates first and have it signed off by the client, which is not a problem until you want to change things because the HTML source is now laden with tags that are not recognized by HTML editors or browsers making design changes more difficult.

    Being based on HTML and putting in attributes (like Tapestry) is a good idea. I hope he adds those special attribute values like $remove$ and include support that Tapestry has, if it has not already. All it would need now is some proper documentation on-line so no one has to go download the thing to see how it works.
  37. It's good to see some minds are still open here!

    I think adding $remove$ is a very good idea and I'll put it on the short list of things to do right away. The syntax will probably be [remove], however, to be consistent with other special Wicket names.

    As far as docs go, I have completed 9 out of 12 chapters of a book on Wicket. If I get my butt in gear, I can finish it off in another week or two. I have a designer friend who is going to help me with the cover and inside art. The current plan is to publish the book via CafePress, which is nice because most of the proceeds will go to support me as an Open Source author. Although I'm also toying around with the idea of giving CodeHaus some small percentage for hosting my project (don't tell Bob though cause he might get greedy or something... ;-)).
  38. Deploy to ibiblio[ Go to top ]

    While you're at it can you put it in ibiblio so I can use it as a maven dependency. And perhaps a genapp patch (I might get bored and make one for you if I have time, no promises though).
  39. Swing[ Go to top ]

    It's kind of funny to ask "why not use Swing", as the author of Wicket was part of the original Swing team and I assume knows a lot about the ins and outs of Swing.

    This looks interesting, I would love to hear from someone who has tried a bunch of these including Echo and Tapestry...
  40. Okay, I've implemented [remove]. I want to test it out before I upload it though...
  41. Very nice idea. I know well ... as I my first web framework used excatly the same concept (it was 4 years ago) ;).


    Only remark I have- why is Wicket using

    <span componentName = "message"/>

    and not (something which can be validated in XHTML/HTML valdidator)

    <span id = "message"/>


    Michal (hausmate)
  42. You can change the name of the attribute that Wicket uses. It's an application setting. But also, it's not too late to change this. Is "id" always available for use like this? I'm worried that Wicket would step on values used by some other tool...
  43. You can change the name of the attribute that Wicket uses. It's an application setting. But also, it's not too late to change this. Is "id" always available for use like this? I'm worried that Wicket would step on values used by some other tool...
    AFAIK "id" is a standard (x)html attribute for assiging unique identifiers to tags within an html page.
    It would be nice if html templates which prepared by web designers were
    fully compilant with html dtd/schema.

    Michal
  44. You can change the name of the attribute that Wicket uses. It's an application setting. But also, it's not too late to change this. Is "id" always available for use like this? I'm worried that Wicket would step on values used by some other tool...
    No, you shouldn't ever rely on being able to use the id attribute. Web pages themselves are going to need to use that attribute for site-specific purposes and for Cascading Style Sheet style assignments. One of the most common CSS selectors is by id (along with by class), and you can't take that away from the web designer.

    Regards,
    Colin
  45. You can change the name of the attribute that Wicket uses. It's an application setting. But also, it's not too late to change this. Is "id" always available for use like this? I'm worried that Wicket would step on values used by some other tool...
    No, you shouldn't ever rely on being able to use the id attribute. Web pages themselves are going to need to use that attribute for site-specific purposes and for Cascading Style Sheet style assignments. One of the most common CSS selectors is by id (along with by class), and you can't take that away from the web designer.Regards,Colin
    That's the whole point. Whatever comes out from hands of web developer should
    be possibly pure html and standard compilant (e.g. you should be able to validate the page using one of available tools). Or at least it would be greate :)

    And id has indeed a couple different roles in html:
    http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2

    Many people and myslef are already using "id" artribute for two very
    different things already: css selector and javascript.
    Why it won't be possible to add Wicket to this list?


    Michal
  46. I have sort of the same issue with Tapestry, but perhaps the author can make it so that it can be configured to use that value instead. Shouldn't be too difficult can it? (Then again, I haven't seen the code and its more arduous than I thought) :)
  47. Not too tough to do:

    public class MyApplication extends WebApplication
    {
        public MyApplication()
        {
            getSettings().setComponentNameAttribute("id");
        }
    }

    The only question is what ought to be the default. I'm actually leaning towards "wid" or something unique like that. The reason is that people might make component libraries in Wicket and they need those libraries to merge into arbitrary projects where "id" might already be in use. But you can certainly use the code above to set it to "id".
  48. Compare notes with BarracudaMVC?[ Go to top ]

    It might be worth comparing notes with the BarracudaMVC folk, as they use a similar markup using class="value", but they're able to co-exist with the CSS definitions, etc.

      There might be other things to check out there too - they're a pretty friendly lot, even to alternative framework developers!

    Gwyn
  49. No problems.[ Go to top ]

    If you read through the API you can change what value it uses to name components. Its a property of the web application as a whole and can be set with one line of code. So yes it can use id if required.
  50. It looks quite promising[ Go to top ]

    I glanced at the examples page and it looks good. I will give it a try.
  51. Micro container integration[ Go to top ]

    I glanced at the examples page and it looks good. I will give it a try.
    I agree with that.

    I did not look that close but read the the CommentForm2 example. I just wonder if it is possible to setup a Page or even a component in a Spring-Context so that I could inject my business beans.
  52. Micro container integration[ Go to top ]

    I may have to learn something about Spring here to see if Spring integration could be usefully added to Wicket. I understand the basic IOC idea and have played with picocontainer. Is there some particular web page I should look at to "grok" what you're talking about? Thanks!
  53. Micro container integration[ Go to top ]

    Would be great if you have the time.

    For a start an introduction-articel is:
    http://www.theserverside.com/articles/article.tss?l=SpringFramework

    The Spring project site with a lot of detail documentation:
    http://www.springframework.org
  54. I agree[ Go to top ]

    I am currently a satisfied Tapestry user, taking a look at the Wicket examples I have to admit though it seems to have the potential to evolve into a interesting Tapestry alternative. :D

    I would like to suggest considering to use a less verbose attribute name for component identification (something like jwcid in Tapestry). 'componentName' has the potential of cluttering HTML documents with much noise IMHO.
  55. I agree[ Go to top ]

    I've heard this a couple of times now, so to quote Ross Perot... "I'm all ears". ;-) Do you have any particular suggestion?
  56. I agree[ Go to top ]

    I would choose the acronym of it: 'cn'. Alternatively 'name' would also be better.
  57. Echo vs Wicket[ Go to top ]

    I have only glossed over Wicket but I think I got a rough idea of how it works. I have done a lot of work in Echo so I can say there are similarities between the two.

    It appears that state management is inherent in Wicket as in Echo. This is nice for the programmer but does impose certain contraints on the back end especially for systems with large number of concurrent users which require large server farms (load balancing, replication,...etc).

    Anyway, to me Wicket looks like a specialized version of Echo. It appears focused on doing the GUI layout in plain HTML while all control is handled in Swingish like POJO. You can actually do something similar with Echo using the Echo HTML and JSP templating and layout features but Wicket seems to have a slightly cleaner seperation (or at least more determined seperation).

    Wicket seems like an interesting idea. It might be worth having the Wicket and Echo folks talk.
  58. Echo vs Wicket[ Go to top ]

    As you point out, there is a lot more state on the server. If you just want to scale something, you could use sticky sessions to do that relatively easily. But one of the downsides right now is that failover clustering is unimplemented. It's certainly possible, but not planned for version 1.0. The upshot of this is that I wouldn't write a UI for a banking system in Wicket right now. But I hope that's obvious anyway due to the Alpha status of the code.
  59. Echo vs Wicket[ Go to top ]

    Just thinking about the differences. It seems that wicket is still more page oriented. ? That would make it more like ASP.Net. Not that it is bad. Some things need that pagishness but not the pain of say Struts. :)
  60. Echo vs Wicket[ Go to top ]

    Well, not exactly (if I understand you correctly).

    While you CAN just be page oriented if you want to, it's not a requirement... or even a good idea in most cases. Every page in Wicket contains a nested hierarchy of components. Some of those components may have *their own* associated markup that gets merged in to produce the final page. Simple containers like Panel are a pretty straightforward merge process in the Wicket core. Other containers like Border are a lot more complicated in the way they merge HTML to form the final page.

    Anyway, you can do some pretty sophisticated things with nested containers in Wicket to compose pages. For example, you can easily make Panels of components and Border components which can be reused throughout a project. Check out the Navomatic example to see an example of Border components. Once you've digested that, take a look at the Library example, which kindof puts it all together, including sign-in, authentication, navigation, etc. It's all done with components and inheritance. Not at all "page oriented". Simple page-based applications are the tip of the component iceberg with Wicket.

    All very unlike ASP from what I know about it.
  61. Echo vs Wicket[ Go to top ]

    Ok. I'll try to look more indepth.
    BTW, ASP <> ASP.Net - BIG difference. While I can place components on pages and use inheritance, I still have to deal with page navigation (in ASP.Net).
  62. Echo vs Wicket[ Go to top ]

    Wicket has at least basic support for navigation built in. I'm very annoyed as a developer about how much work it takes to deal with navigation, so I'd be interested to know what could be improved.
  63. Echo vs Wicket[ Go to top ]

    Wicket has at least basic support for navigation built in. I'm very annoyed as a developer about how much work it takes to deal with navigation, so I'd be interested to know what could be improved.
    Me too. In an app, I don't want to deal with "navigation". Just launching/showing windows and dialogs.
  64. Echo vs Wicket[ Go to top ]

    Now that I re-read your comment, I'm not sure if I understand you... what do you mean by "page-oriented"? My assumption was that you meant each page has a single HTML file. But now I'm not sure...
  65. Echo vs Wicket[ Go to top ]

    Now that I re-read your comment, I'm not sure if I understand you... what do you mean by "page-oriented"? My assumption was that you meant each page has a single HTML file. But now I'm not sure...
    If I have to know I am dealing with pages, even if at the lowest level - How I "navigate" is the clue.
  66. Echo vs Wicket[ Go to top ]

    I'm still not sure I understand. If you weren't navigating to pages, what would you be navigating to?
  67. Echo vs Wicket[ Go to top ]

    BTW, I'm not being dense on purpose here... I really don't understand... maybe you can give me an example?
  68. Echo vs Wicket[ Go to top ]

    I know you aren't. Sometimes things just don't click. It is clear for me so that makes it difficult to make it clear to you. I get the same way. But when it clicks ...

    This is how Echo works. Best thing to do is pull up one of there examples. Like ... http://demo.nextapp.com/EchoTutorial/src/ButtonDemoServlet.java

    I wouldn't want Wicket to be just like Echo. Like I said, some things need the "page paradigm" (does any one else think pair-a-digum when they see that now? Stupid commercial).
  69. Echo vs Wicket[ Go to top ]

    Gotcha. No, Wicket doesn't support that kind of usage at this time. In fact how forms get submitted via submit buttons is all up to the HTML. There's no Wicket button class at all, nor any need for one.

    It is possible, however, to define new listeners in Wicket (such as ILinkListener.linkClicked and IFormSubmitListener.formSubmitted, which are not particularly "special")... although that's normally an internal kind of thing and "advanced usage" right now. So you *could* make that button demo happen. It's just not a priority right now since "page oriented" works so well.
  70. Echo vs Wicket[ Go to top ]

    The framework handles it. So effectively, yes the app is navigating to "pages". Or maybe everything is one page in the browser's 'mind'. But in the code, I know nothing about it. And don't have to worry about it.
  71. Echo vs Wicket[ Go to top ]

    Ah, I think I understand what you mean now (maybe!). Wicket links are not inherently tied to pages. See the Linkomatic example to get a view of the different kinds of links you can have. For example, you can have a link on a page which simply has a handler and redirects back to the same page. The actionLink example in Linkomatic demonstrates this. Each time you click the link it increments its own text:


            // Action link counts link clicks
            final Link actionLink = new Link("actionLink")
            {
                public void linkClicked(final RequestCycle cycle)
                {
                    linkClickCount++;

                    // Redirect back to result to avoid refresh updating the link count
                    cycle.setRedirect(true);
                }
            };
            actionLink.add(new Label("linkClickCount", this));
            add(actionLink);
  72. Tapestry Comparison[ Go to top ]

    At first glance, Wicket looks promising and lot less complicated than Tapestry. Jonathan, are there features in Tapestry that are missing in Wicket? For example, Spring integration, page pooling? I really like to know what the missing features are in Wicket and what the roadmap is.
  73. Tapestry Comparison[ Go to top ]

    You know, a development roadmap is a really great idea. I think I will work on one for the codehaus site real soon.

    Wicket is pretty immature right now next to Tapestry, which has been going on for several years. It's an alpha product at the moment and I wouldn't use it on something that needs to be in production soon.

    I'm not a tapestry expert, but there are some thing missing to be sure. A couple of things that I know are missing include support for JavaScript components, client side validation and date picker. This is not planned for version 1.0. I want to get all the basic stuff working first. To that end, basic forms and validation are done and mostly work... although there are some known problems (even one ugly one in the examples that I plan to get to real soon).

    Wicket does not do page pooling. What it /does/ do is make the markup stream which renders each page immutable and shared. This means the markup for a page is only ever loaded once. In addition, the immutable markup stream is parsed into appropriate sized chunks which make rendering very efficient (it's not tag, by tag).
  74. Wicket vs. Tapestry[ Go to top ]

    What advantages does Wicket have over Tapestry, which addresses the same domain in a similar fashion, but is also more mature and well proven? I like the fact that Wicket doesn't rely on XML configuration files, but does it have any additional benefits over Tapestry?
  75. Wicket vs. Tapestry[ Go to top ]

    Your point is correct that Tapestry is mature and Wicket is not. You could ship a production Tapestry app today. Production Wicket applications on a stable Wicket 1.0 are probably a few months off.

    I think Wicket has substantial advantages over Tapestry for most kinds of problems that you'll encounter in Web UIs. In fact, I was trying to learn Tapestry when I got motivated to write Wicket. Maybe I'm just slow, but I don't want a framework that requires me to read the book/docs more than once to get anything done. The overarching goal with Wicket is to make it as simple as possible while still having enough power to make problems easy to tackle.

    Wicket's other advantages lie in state management. Wicket has a pretty tight state management strategy and a pretty first class object model. There's kindof one reasonable way to do things (as opposed to ad-hoc manipulation of session state). This means two things right now. On the upside, Wicket has tight control over the state and its structure in the session. This is good because Wicket can do things like automatically dealing with the back-button by detecting stale data. It's also easier to write state manipulating pages and forms and easier to integrate your code with Hibernate. On the downside, Wicket uses more memory than Tapestry to store this state and does not yet have a clustering strategy (since you don't just put values in the session). This will hopefully be addressed in version 1.1 when more is understood about the problem.
  76. Just looked at Wicket examples.

    I like the idea of not using XML config files so heavily. Java is such a high level language so why the obsession with XML config files?

    So this framework is a good idea I think. Not just because of limiting XML, but also because of the non-intrusive (no tag libs) HTML pages like Tapestry approach. Way to go IMO if you are doing web developemnt. Hopefully more java developers see the light in ragards to this and begin to expect it with any web framework.

    Good web frameworks should be easy for the basics but very extendable in case of something unique. The goal is to get the job done in a reasonable amout of time and make money...not make things more complicated. Wicket is just an evolutionary step in the right direction.
  77. I am actually looking for work right now and it would especially nice if there were a Seattle area company interested enough in Wicket to apply it to something real. Although it's alpha right now, I think it's more or less ready to be applied to a real-world web UI problem. My resume is at http://www.muppetlabs.com/~jonl

          Jonathan
  78. Hey, it's good to see other folks in Seattle. Wicket looks really nice. A very clean solution to web programming. I might have to play with it a bit ;)

      .adam sanderson
  79. Looks good[ Go to top ]

    This reminds me of the Sofia framework http://www.salmonllc.com/website/Jsp/vanity/Sofia.jsp however without the reliance on jsp tags and dreamweaver plugin (which I always found to be unstable). I look forward to future releases.
  80. Wicket: Hello World Example[ Go to top ]

    Hello Jonathan,
    The framework looks very promising and I hope that many developers will start using the framework. I have to admit that I have not gone deep with it and before I do that I would like to ask a question.

    I took a quick look at Hello World example. I am wondering if it is possible to pass parameter(s) to your java class from html.

    Examples
    <html>
    <body>
     
        <span componentName = "message" label="First Name"/>
     
    </body>
    </html>
    In this case "First Name" will be passed to my java class and then displayed on my page. Likewise
    <html>
    <body>
     
        <span componentName = "message" label="Last Name"/>
     
    </body>
    </html>
    The label "Last Name" will be displayed on the site. If this functionality does not exist, then it means that for every label you want to create, you will have to create its java class, which will be very cumbersome!
  81. Wicket: Hello World Example[ Go to top ]

    No parameters. And that is a GOOD THING because you would only use a label component if the name of the label were dynamic (and therefore updated by Java code). If the name of the label is static, you'd just use regular old HTML with no component at all:

    <html>
    <body>

       FirstName

    </body>
    </html>
  82. Wicket: Hello World Example[ Go to top ]

    No parameters. And that is a GOOD THING because you would only use a label component if the name of the label were dynamic (and therefore updated by Java code). If the name of the label is static, you'd just use regular old HTML with no component at all:<html><body>&nbsp;&nbsp;&nbsp;FirstName</body></html>

    Johnathan,

    I don't understand your reply. Can you please rephrase it and/or be more verbose? :)

    Thank you,
    Gili
  83. Wicket: Hello World Example[ Go to top ]

    Hello Jonathan,
    The framework looks very promising and I hope that many developers will start using the framework. I have to admit that I have not gone deep with it and before I do that I would like to ask a question.

    I took a quick look at Hello World example. I am wondering if it is possible to pass parameter(s) to your java class from html.

    Examples
    <html>
    <body>
     
        <span componentName = "message" label="First Name"/>
     
    </body>
    </html>
    In this case "First Name" will be passed to my java class and then displayed on my page. Likewise
    <html>
    <body>
     
        <span componentName = "message" label="Last Name"/>
     
    </body>
    </html>
    The label "Last Name" will be displayed on the site. If this functionality does not exist, then it means that for every label you want to create, you will have to create its java class, which will be very cumbersome!
  84. This looks interesting, it is good to see an entirely different approach to Tapestry, and its good to see people's minor (mostly!) frustrations made tangible with an alternative
  85. This looks interesting, it is good to see an entirely different approach to Tapestry, and its good to see people's minor (mostly!) frustrations made tangible with an alternative.

    There were many familiar things in my brief overview of the examples, JL has been lurking in the Tapestry lists. Remember that what's obvious and natural to one person is not so much to the next.

    In addition, we all have our own priorities. JL clearly wanted to avoid any and all XML. Tapestry seeks to minimize Java code and preserve scalability and clusterability.

    Simplicity. Consistency. Efficiency. Feedback.

    I haven't looked at the code, but based on the notes here, it sounds like Wicket instantiates complete pages and stores them in the session ... and goes on to say that clustering is not a real option. By contrast, Tapestry goes to great lengths to ensure that very little is stored in the session, and make use of pools for efficiency. On the other hand, Wicket looks like it uses very little reflection, whereas Tapestry (via OGNL) uses quite a bit.

    I think the HTML templates are pretty equivalent. I'm concerned that, like older versions of Tapestry, the HTML templates must be stored in the classpath with the Java classes, which hampers the efforts of HTML designers to work with, and preview files.

    Wicket does get high marks for consistency; especially consistency with the ideas behind Swing. Tapestry's long evolution has resulted in a wide range of choices.

    Tapestry wins on feedback ... I munged some of the Wicket URLs and got nothing but a simple stack trace.

    I didn't see internationalization issues addressed anywhere.

    Like Tapestry (3.0) everything runs through a single servlet, causing issues with leveraging J2EE declarative security (which is effectively folder based).

    I know it isn't fair to compare his early code to Tapestry 3.1, which has barely been started yet. But the features we're looking forward to in 3.1 are pretty important:
    - Portlet support
    - Persistent page state as query parameters and/or HTTP cookies (as well as traditional HttpSession)
    - Prettier URLs
    - Significantly simplified XML
    - Extreme extensibility via integration with HiveMind

    Wicket looks like a good piece of engineering. It's exteremely hard to gain market share in this overcrowded space. Competition is always good and I'm sure we'll cherrypick each other's best ideas!
  86. In addition, we all have our own priorities. JL clearly wanted to avoid any and all XML. Tapestry seeks to minimize Java code and preserve scalability and clusterability.
    >
    > Simplicity. Consistency. Efficiency. Feedback.

    Wicket has all of the same goals as Tapestry plus a couple.
    In particular, Wicket has a goal of safety/security, which
    means NOT exposing session state.

     o EASY (SIMPLE / CONSISTENT / OBVIOUS)

       - POJO-centric
       - All code written in Java ala Swing
       - Minimize "conceptual surface area"
       - Avoid overuse of XML configuration files
       - Fully solve “back button problem”
       - Easy to create bookmarkable pages
       - Hibernate integration for easy database persistence
       - Maximum type safety and compile-time problem diagnosis
       - Maximum diagnosis of run-time problems
       - Minimum reliance on special tools
       - Components, containers and conventions should be consistent

     o REUSABLE

       - Components written in Wicket should be fully reusable
       - Reusable components should be easily distributed in ordinary JAR files

     o NON-INTRUSIVE
      
       - HTML or other markup not polluted with programming semantics
       - Only one simple tagging construct in markup
       - Compatible with any ordinary HTML editor
       - Easy for graphics designers to recognize and avoid framework tagging
       - Easy to add tagging back to HTML if designers accidentally remove it

     o SAFE

       - Code is secure by default
       - Only explicitly created external page links can expose state in the page or in the URL
       - All logic in Java with maximum type safety
       - Easy to integrate with Java security

     o EFFICIENT / SCALABLE

       - Efficient and lightweight, but not at the expense of other goals
       - Use of “sticky sessions” can achieve scalability (without failover)
       - Clustering via session replication more heavyweight, but possible

    > I haven't looked at the code, but based on the notes here, it sounds
    > like Wicket instantiates complete pages and stores them in the session
    > ... and goes on to say that clustering is not a real option. By
    > contrast, Tapestry goes to great lengths to ensure that very little is
    > stored in the session, and make use of pools for efficiency.

    Yup. This is a design decision difference that makes Tapestry and Wicket
    very different. Wicket's design assumes that software is expensive and
    complex to create and that hardware is cheap and plentiful. I think this
    scenario will increasingly play out in the future and that the assumption
    is a good one. I think saving the cost of a $300 e-machine (or two or
    three!) by spending days fixing pooling and state bugs is just not worth
    it in the end.

    Failover clustering (you can always do sticky session clustering) does
    not exist simply because I've been the only one working on Wicket and
    I cannot create a worthwhile failover clustering strategy by myself
    inside the 1.0 release timeframe. Actually, I'm currently looking for
    help to do this for 1.1. Questions remain about exactly how to do
    clustering, but I can think of several good basic alternatives. The
    trick will be making the replication really efficient. I believe that
    will turn out to be do-able.

    Page state is very lightweight in Wicket because it seeks to make the
    maximum amount of each page immutable. The immutable state is shared
    among all pages across all sessions. So what ends up in the session is
    typically fairly small and in the future there may be ways to further
    reduce that state. Benchmarking of object sizes shows that a typical
    page is a few KB in size. While this is signifiant, you can immediately
    cluster wicket using sticky sessions and in the future there will be a
    failover clustering strategy of some sort.

    > On the other hand, Wicket looks like it uses very little reflection, whereas
    > Tapestry (via OGNL) uses quite a bit.

    Correct. Wicket actually uses OGNL in language internationalization, however.

    > I think the HTML templates are pretty equivalent. I'm concerned that,
    > like older versions of Tapestry, the HTML templates must be stored in
    > the classpath with the Java classes, which hampers the efforts of HTML
    > designers to work with, and preview files.

    This was a design decision, and while I agree with your concern, I think
    packaging the associated markup files in a modular way is more important
    than lumping files together for designers to work on. For one thing, it
    makes component software easier to produce and maintain. And a simple
    copy or zip filter or other solution can always be used to handoff the
    HTML files... although they ultimately DO have to have the same folder
    nesting.

    > Wicket does get high marks for consistency; especially consistency
    > with the ideas behind Swing. Tapestry's long evolution has resulted in
    > a wide range of choices.

    Yes and no. Wicket is very Swing-like in its component/container nesting.
    But I'd say it's a lot less verbose.

    > Tapestry wins on feedback ... I munged some of the Wicket URLs and got
    > nothing but a simple stack trace.

    This is actually just a bug. Wicket has substantially good feedback pages,
    including detailed stack traces and HTML which highlights the location of
    errors. If you can repro the bug, please enter it in the Wicket bug db!

    > I didn't see internationalization issues addressed anywhere.

    I18N is addressed throughout, as well as "skinning". See the PUB
    example, where you can switch between American and Canadian English
    Locales, eh. You can also do some really neat stuff with OGNL to
    localize strings used in web applications.

    > Like Tapestry (3.0) everything runs through a single servlet, causing
    > issues with leveraging J2EE declarative security (which is effectively
    > folder based).

    Correct. I think there may be a solution to this in the future, although
    I'm not sure what it might be yet. One possibility would be to make the
    underlying servlet so that you can attach it to multiple folders.

    In the meantime, you can manage security programmatically. The Library
    example shows how to make pages authenticated and secure by using Java
    inheritance. I think this may ultimately be a better approach to the
    problem anyway...

    > I know it isn't fair to compare his early code to Tapestry 3.1, which
    > has barely been started yet. But the features we're looking forward to
    > in 3.1 are pretty important:
    >
    > - Portlet support

    Agree.

    > - Persistent page state as query parameters and/or HTTP cookies (as well as traditional HttpSession)

    Disagree. Form cookies are supported in Wicket (if you use them
    explicitly). However, transparently storing page state in this way
    is explicitly not a goal of the Wicket framework since it increases
    complexity and the tendency of programmers to create security bugs.
    I thought about this for a long time and decided I'd prefer a framework
    that is safe by default and where you have to make very explicit
    decisions to make usage of it unsafe.

    > - Prettier URLs

    Prettier URLs are already available for external pages that need to be
    bookmarked. Although it might be nice in the future to come up with a
    way to present prettier URLs to users, I think the current URLs are good
    enough for 1.0. A scheme can easily be added in the future.

    I also think there is a good argument for adding obfuscated URLs in the
    future for people with extreme security issues to solve (i.e., NO state
    in the client). It would be very easy in the future to guarantee this
    with Wicket since it already ensures that all the state is on the server.

    > - Significantly simplified XML

    Disagree. There is no plan to make Wicket XML configured.

    > - Extreme extensibility via integration with HiveMind

    > Wicket looks like a good piece of engineering. It's exteremely hard to
    > gain market share in this overcrowded space. Competition is always
    > good and I'm sure we'll cherrypick each other's best ideas!

    Yup! Happy trails, Howard!
  87. Heh. Oops. In that last little bit, I was discussing how your Tapestry 3.1 plans might apply to Wicket. Didn't make that clear.

    Also, wanted to point out just how unfair the comparison to Tapestry is right now. Tapestry is mature and development has been going on for years. All of Wicket was written by yours truly starting the 3rd week of April, 2004. So I think there's a lot of room for improvement and the Wicket community is really just getting started. Check back with us in a year or two!

    BTW, thanks to everyone out there for all the email and encouragement!!