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
-
Wicket: Do we need yet another presentation layer framework? (86 messages)
- Posted by: Miko Matsumura
- Posted on: August 18 2004 15:03 EDT
Threaded Messages (86)
- Wicket: Do we need yet another presentation layer framework? by Mark N on August 18 2004 15:26 EDT
- Echo by Jonathan Locke on August 18 2004 15:53 EDT
-
Echo by Mark N on August 18 2004 03:59 EDT
- Echo by Mark N on August 18 2004 04:02 EDT
-
Differences by Jonathan Locke on August 18 2004 04:23 EDT
-
Differences by Mark N on August 18 2004 04:44 EDT
-
Yes by Jonathan Locke on August 18 2004 04:49 EDT
-
Yes by Mark N on August 18 2004 04:54 EDT
- Yes by Jonathan Locke on August 18 2004 05:03 EDT
-
Yes by Mark N on August 18 2004 04:54 EDT
-
Yes by Jonathan Locke on August 18 2004 04:49 EDT
-
Try EchoStudio by Michael Imari on August 18 2004 04:52 EDT
- IDE Pluginst by Jonathan Locke on August 18 2004 04:58 EDT
-
Differences by Mark N on August 18 2004 04:44 EDT
-
HtmlTemplatePanels by Jonathan Locke on August 18 2004 04:43 EDT
- And... by Jonathan Locke on August 18 2004 04:45 EDT
-
Echo by Mark N on August 18 2004 03:59 EDT
- Wicket: Do we need yet another presentation layer framework? by Tom Davies on August 18 2004 18:46 EDT
- Echo by Jonathan Locke on August 18 2004 15:53 EDT
- Do we need yet another presentation layer framework? !NOOO! by sdfdf dgdgg on August 18 2004 15:40 EDT
- Do we need yet another presentation layer framework? !NOOO! by Mark N on August 18 2004 16:03 EDT
- Do we need yet another presentation layer framework? !NOOO! by Rod Johnson on August 19 2004 10:20 EDT
- Do we need yet another presentation layer framework? !YES! by Archimedes Trajano on August 19 2004 12:33 EDT
- I like it so far by Toby Reyelts on August 18 2004 15:57 EDT
- I like it so far by Fernando Petrola on August 18 2004 16:22 EDT
-
Wicket vs. Swing by Jonathan Locke on August 18 2004 04:31 EDT
-
Wicket vs. Swing by Fernando Petrola on August 18 2004 05:00 EDT
-
Wicket vs. Swing by Jonathan Locke on August 18 2004 05:16 EDT
- I like it! Awesome! by john smith on August 18 2004 07:27 EDT
-
Wicket vs. Swing by Fernando Petrola on August 18 2004 10:02 EDT
- Wicket vs. Swing by Fernando Petrola on August 18 2004 10:22 EDT
-
Wicket vs. Swing by Jonathan Locke on August 18 2004 11:25 EDT
-
Wicket vs. Swing by Fernando Petrola on August 19 2004 10:55 EDT
-
Stop dumb comparisons by john smith on August 19 2004 01:10 EDT
- Stop dumb comparisons by Fernando Petrola on August 19 2004 01:52 EDT
-
Stop dumb comparisons by john smith on August 19 2004 01:10 EDT
-
Wicket vs. Swing by Fernando Petrola on August 19 2004 10:55 EDT
-
Wicket vs. Swing by Tim Boudreau on August 19 2004 05:57 EDT
- Wicket vs. Swing by Fernando Petrola on August 19 2004 10:35 EDT
-
Wicket vs. Swing by Fernando Petrola on August 19 2004 12:31 EDT
- Wicket vs. Swing by Keith Kee on August 21 2004 01:24 EDT
-
Wicket vs. Swing by Jonathan Locke on August 18 2004 05:16 EDT
-
Wicket vs. Swing by Fernando Petrola on August 18 2004 05:00 EDT
-
Wicket vs. Swing by Jonathan Locke on August 18 2004 04:31 EDT
- I like it so far by Fernando Petrola on August 18 2004 16:22 EDT
- Do we need yet another presentation layer framework? by Archimedes Trajano on August 18 2004 17:45 EDT
- $remove$ and Upcoming Wicket Book by Jonathan Locke on August 18 2004 17:58 EDT
- Deploy to ibiblio by Archimedes Trajano on August 18 2004 06:19 EDT
- Swing by Miko Matsumura on August 18 2004 06:24 EDT
- $remove$ and Upcoming Wicket Book by Jonathan Locke on August 18 2004 06:54 EDT
- $remove$ and Upcoming Wicket Book by Jonathan Locke on August 18 2004 17:58 EDT
- Wicket: Do we need yet another presentation layer framework? by Michal Maczka on August 19 2004 04:13 EDT
- Wicket: Do we need yet another presentation layer framework? by Jonathan Locke on August 19 2004 11:45 EDT
- Wicket: Do we need yet another presentation layer framework? by Michal Maczka on August 19 2004 01:40 EDT
-
Wicket: Do we need yet another presentation layer framework? by Colin Sampaleanu on August 19 2004 05:55 EDT
-
Wicket: Do we need yet another presentation layer framework? by Michal Maczka on August 19 2004 06:11 EDT
-
componentName vs id attribute by Archimedes Trajano on August 19 2004 07:38 EDT
-
componentName vs id attribute by Jonathan Locke on August 19 2004 08:49 EDT
- Compare notes with BarracudaMVC? by Gwyn Evans on August 20 2004 05:39 EDT
-
componentName vs id attribute by Jonathan Locke on August 19 2004 08:49 EDT
-
componentName vs id attribute by Archimedes Trajano on August 19 2004 07:38 EDT
-
Wicket: Do we need yet another presentation layer framework? by Michal Maczka on August 19 2004 06:11 EDT
- No problems. by qwam swatidi on August 19 2004 18:01 EDT
- Wicket: Do we need yet another presentation layer framework? by Jonathan Locke on August 19 2004 11:45 EDT
- It looks quite promising by johnny fifka on August 19 2004 06:49 EDT
- Micro container integration by Christian Essl on August 19 2004 12:14 EDT
-
Micro container integration by Jonathan Locke on August 19 2004 12:22 EDT
- Micro container integration by Christian Essl on August 19 2004 02:10 EDT
-
Micro container integration by Jonathan Locke on August 19 2004 12:22 EDT
- I agree by Dusan Kysel on August 19 2004 12:41 EDT
-
I agree by Jonathan Locke on August 19 2004 12:55 EDT
- I agree by Dusan Kysel on August 19 2004 05:57 EDT
-
I agree by Jonathan Locke on August 19 2004 12:55 EDT
- Micro container integration by Christian Essl on August 19 2004 12:14 EDT
- Echo vs Wicket by Sam Taha on August 19 2004 10:48 EDT
- Echo vs Wicket by Jonathan Locke on August 19 2004 11:53 EDT
-
Echo vs Wicket by Mark N on August 19 2004 12:56 EDT
-
Echo vs Wicket by Jonathan Locke on August 19 2004 01:19 EDT
-
Echo vs Wicket by Mark N on August 19 2004 01:27 EDT
-
Echo vs Wicket by Jonathan Locke on August 19 2004 01:31 EDT
- Echo vs Wicket by Mark N on August 19 2004 01:46 EDT
-
Echo vs Wicket by Jonathan Locke on August 19 2004 01:31 EDT
-
Echo vs Wicket by Mark N on August 19 2004 01:27 EDT
-
Echo vs Wicket by Jonathan Locke on August 19 2004 01:23 EDT
-
Echo vs Wicket by Mark N on August 19 2004 01:48 EDT
-
Echo vs Wicket by Jonathan Locke on August 19 2004 02:20 EDT
-
Echo vs Wicket by Jonathan Locke on August 19 2004 02:28 EDT
-
Echo vs Wicket by Mark N on August 19 2004 02:36 EDT
- Echo vs Wicket by Jonathan Locke on August 19 2004 02:47 EDT
-
Echo vs Wicket by Mark N on August 19 2004 02:36 EDT
-
Echo vs Wicket by Mark N on August 19 2004 02:29 EDT
- Echo vs Wicket by Jonathan Locke on August 19 2004 02:40 EDT
-
Echo vs Wicket by Jonathan Locke on August 19 2004 02:28 EDT
-
Echo vs Wicket by Jonathan Locke on August 19 2004 02:20 EDT
-
Echo vs Wicket by Mark N on August 19 2004 01:48 EDT
-
Echo vs Wicket by Jonathan Locke on August 19 2004 01:19 EDT
-
Echo vs Wicket by Mark N on August 19 2004 12:56 EDT
- Echo vs Wicket by Jonathan Locke on August 19 2004 11:53 EDT
- Tapestry Comparison by Ben Wong on August 19 2004 10:54 EDT
- Tapestry Comparison by Jonathan Locke on August 19 2004 12:03 EDT
- Wicket vs. Tapestry by Yariv Sadan on August 19 2004 11:20 EDT
- Wicket vs. Tapestry by Jonathan Locke on August 19 2004 12:20 EDT
- Wicket: Do we need yet another presentation layer framework? by Todd Bowker on August 19 2004 14:32 EDT
- Looking for work. Any Seattle companies want to apply Wicket? by Jonathan Locke on August 19 2004 15:09 EDT
- Looking for work. Any Seattle companies want to apply Wicket? by Adam Sanderson on August 20 2004 18:24 EDT
- Looks good by Chris Tuck on August 20 2004 01:42 EDT
- Wicket: Hello World Example by Godfrey Nangoma on August 20 2004 05:53 EDT
-
Wicket: Hello World Example by Jonathan Locke on August 20 2004 12:54 EDT
- Wicket: Hello World Example by Gili _ on December 24 2004 02:25 EST
-
Wicket: Hello World Example by Jonathan Locke on August 20 2004 12:54 EDT
- Wicket: Hello World Example by Godfrey Nangoma on August 20 2004 06:08 EDT
- Wicket: Hello World Example by Godfrey Nangoma on August 20 2004 05:53 EDT
- Notes from the Tapestry gu.y ... by Howard Lewis Ship on August 20 2004 06:58 EDT
- Notes from the Tapestry guy ... by Howard Lewis Ship on August 20 2004 07:37 EDT
- Notes from the Tapestry guy ... by Jonathan Locke on August 20 2004 13:44 EDT
- Notes from the Tapestry guy ... by Jonathan Locke on August 20 2004 02:09 EDT
- Notes from the Tapestry guy ... by Jonathan Locke on August 20 2004 13:44 EDT
-
Wicket: Do we need yet another presentation layer framework?[ Go to top ]
- Posted by: Mark N
- Posted on: August 18 2004 15:26 EDT
- in response to Miko Matsumura
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. -
Echo[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 15:53 EDT
- in response to Mark N
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. -
Echo[ Go to top ]
- Posted by: Mark N
- Posted on: August 18 2004 15:59 EDT
- in response to Jonathan Locke
-
Echo[ Go to top ]
- Posted by: Mark N
- Posted on: August 18 2004 16:02 EDT
- in response to Mark N
-
Differences[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 16:23 EDT
- in response to Mark N
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. -
Differences[ Go to top ]
- Posted by: Mark N
- Posted on: August 18 2004 16:44 EDT
- in response to Jonathan Locke
Fair enough. Maybe someone who has looked indepth at both can provide more insight. -
Yes[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 16:49 EDT
- in response to Mark N
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! -
Yes[ Go to top ]
- Posted by: Mark N
- Posted on: August 18 2004 16:54 EDT
- in response to Jonathan Locke
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. -
Yes[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 17:03 EDT
- in response to Mark N
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. -
Try EchoStudio[ Go to top ]
- Posted by: Michael Imari
- Posted on: August 18 2004 16:52 EDT
- in response to Jonathan Locke
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 -
IDE Pluginst[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 16:58 EDT
- in response to Michael Imari
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. -
HtmlTemplatePanels[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 16:43 EDT
- in response to Mark N
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. -
And...[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 16:45 EDT
- in response to Jonathan Locke
you can arbitrarily nest these components, including "Border" components which can be used to easily, even transparently, add your designer's navigation HTML. -
Wicket: Do we need yet another presentation layer framework?[ Go to top ]
- Posted by: Tom Davies
- Posted on: August 18 2004 18:46 EDT
- in response to Mark N
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. -
Do we need yet another presentation layer framework? !NOOO![ Go to top ]
- Posted by: sdfdf dgdgg
- Posted on: August 18 2004 15:40 EDT
- in response to Miko Matsumura
this is going absurd.. -
Do we need yet another presentation layer framework? !NOOO![ Go to top ]
- Posted by: Mark N
- Posted on: August 18 2004 16:03 EDT
- in response to sdfdf dgdgg
this is going absurd..
Actually it seems to, finally, be going in the right direction. -
Do we need yet another presentation layer framework? !NOOO![ Go to top ]
- Posted by: Rod Johnson
- Posted on: August 19 2004 10:20 EDT
- in response to sdfdf dgdgg
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. -
Do we need yet another presentation layer framework? !YES![ Go to top ]
- Posted by: Archimedes Trajano
- Posted on: August 19 2004 12:33 EDT
- in response to Rod Johnson
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. -
I like it so far[ Go to top ]
- Posted by: Toby Reyelts
- Posted on: August 18 2004 15:57 EDT
- in response to Miko Matsumura
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 -
I like it so far[ Go to top ]
- Posted by: Fernando Petrola
- Posted on: August 18 2004 16:22 EDT
- in response to Toby Reyelts
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 -
Wicket vs. Swing[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 16:31 EDT
- in response to Fernando Petrola
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. -
Wicket vs. Swing[ Go to top ]
- Posted by: Fernando Petrola
- Posted on: August 18 2004 17:00 EDT
- in response to Jonathan Locke
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... -
Wicket vs. Swing[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 17:16 EDT
- in response to Fernando Petrola
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 like it! Awesome![ Go to top ]
- Posted by: john smith
- Posted on: August 18 2004 19:27 EDT
- in response to Jonathan Locke
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... -
Wicket vs. Swing[ Go to top ]
- Posted by: Fernando Petrola
- Posted on: August 18 2004 22:02 EDT
- in response to Jonathan Locke
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! -
Wicket vs. Swing[ Go to top ]
- Posted by: Fernando Petrola
- Posted on: August 18 2004 22:22 EDT
- in response to Fernando Petrola
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. -
Wicket vs. Swing[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 23:25 EDT
- in response to Fernando Petrola
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. -
Wicket vs. Swing[ Go to top ]
- Posted by: Fernando Petrola
- Posted on: August 19 2004 10:55 EDT
- in response to Jonathan Locke
...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? -
Stop dumb comparisons[ Go to top ]
- Posted by: john smith
- Posted on: August 19 2004 13:10 EDT
- in response to Fernando Petrola
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....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?
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. -
Stop dumb comparisons[ Go to top ]
- Posted by: Fernando Petrola
- Posted on: August 19 2004 13:52 EDT
- in response to john smith
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.
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....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?
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.... -
Wicket vs. Swing[ Go to top ]
- Posted by: Tim Boudreau
- Posted on: August 19 2004 05:57 EDT
- in response to Fernando Petrola
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. -
Wicket vs. Swing[ Go to top ]
- Posted by: Fernando Petrola
- Posted on: August 19 2004 10:35 EDT
- in response to Tim Boudreau
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! -
Wicket vs. Swing[ Go to top ]
- Posted by: Fernando Petrola
- Posted on: August 19 2004 12:31 EDT
- in response to Tim Boudreau
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! -
Wicket vs. Swing[ Go to top ]
- Posted by: Keith Kee
- Posted on: August 21 2004 13:24 EDT
- in response to Fernando Petrola
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. -
Do we need yet another presentation layer framework?[ Go to top ]
- Posted by: Archimedes Trajano
- Posted on: August 18 2004 17:45 EDT
- in response to Miko Matsumura
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. -
$remove$ and Upcoming Wicket Book[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 17:58 EDT
- in response to Archimedes Trajano
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... ;-)). -
Deploy to ibiblio[ Go to top ]
- Posted by: Archimedes Trajano
- Posted on: August 18 2004 18:19 EDT
- in response to Jonathan Locke
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). -
Swing[ Go to top ]
- Posted by: Miko Matsumura
- Posted on: August 18 2004 18:24 EDT
- in response to Jonathan Locke
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... -
$remove$ and Upcoming Wicket Book[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 18 2004 18:54 EDT
- in response to Jonathan Locke
Okay, I've implemented [remove]. I want to test it out before I upload it though... -
Wicket: Do we need yet another presentation layer framework?[ Go to top ]
- Posted by: Michal Maczka
- Posted on: August 19 2004 04:13 EDT
- in response to Miko Matsumura
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) -
Wicket: Do we need yet another presentation layer framework?[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 11:45 EDT
- in response to Michal Maczka
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... -
Wicket: Do we need yet another presentation layer framework?[ Go to top ]
- Posted by: Michal Maczka
- Posted on: August 19 2004 13:40 EDT
- in response to Jonathan Locke
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 -
Wicket: Do we need yet another presentation layer framework?[ Go to top ]
- Posted by: Colin Sampaleanu
- Posted on: August 19 2004 17:55 EDT
- in response to Jonathan Locke
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 -
Wicket: Do we need yet another presentation layer framework?[ Go to top ]
- Posted by: Michal Maczka
- Posted on: August 19 2004 18:11 EDT
- in response to Colin Sampaleanu
That's the whole point. Whatever comes out from hands of web developer shouldYou 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
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:
https://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 -
componentName vs id attribute[ Go to top ]
- Posted by: Archimedes Trajano
- Posted on: August 19 2004 19:38 EDT
- in response to Michal Maczka
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) :) -
componentName vs id attribute[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 20:49 EDT
- in response to Archimedes Trajano
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". -
Compare notes with BarracudaMVC?[ Go to top ]
- Posted by: Gwyn Evans
- Posted on: August 20 2004 17:39 EDT
- in response to Jonathan Locke
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 -
No problems.[ Go to top ]
- Posted by: qwam swatidi
- Posted on: August 19 2004 18:01 EDT
- in response to Michal Maczka
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. -
It looks quite promising[ Go to top ]
- Posted by: johnny fifka
- Posted on: August 19 2004 06:49 EDT
- in response to Miko Matsumura
I glanced at the examples page and it looks good. I will give it a try. -
Micro container integration[ Go to top ]
- Posted by: Christian Essl
- Posted on: August 19 2004 12:14 EDT
- in response to johnny fifka
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. -
Micro container integration[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 12:22 EDT
- in response to Christian Essl
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! -
Micro container integration[ Go to top ]
- Posted by: Christian Essl
- Posted on: August 19 2004 14:10 EDT
- in response to Jonathan Locke
Would be great if you have the time.
For a start an introduction-articel is:
https://www.theserverside.com/articles/article.tss?l=SpringFramework
The Spring project site with a lot of detail documentation:
http://www.springframework.org -
I agree[ Go to top ]
- Posted by: Dusan Kysel
- Posted on: August 19 2004 12:41 EDT
- in response to johnny fifka
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. -
I agree[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 12:55 EDT
- in response to Dusan Kysel
I've heard this a couple of times now, so to quote Ross Perot... "I'm all ears". ;-) Do you have any particular suggestion? -
I agree[ Go to top ]
- Posted by: Dusan Kysel
- Posted on: August 19 2004 17:57 EDT
- in response to Jonathan Locke
I would choose the acronym of it: 'cn'. Alternatively 'name' would also be better. -
Echo vs Wicket[ Go to top ]
- Posted by: Sam Taha
- Posted on: August 19 2004 10:48 EDT
- in response to Miko Matsumura
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. -
Echo vs Wicket[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 11:53 EDT
- in response to Sam Taha
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. -
Echo vs Wicket[ Go to top ]
- Posted by: Mark N
- Posted on: August 19 2004 12:56 EDT
- in response to Jonathan Locke
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. :) -
Echo vs Wicket[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 13:19 EDT
- in response to Mark N
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. -
Echo vs Wicket[ Go to top ]
- Posted by: Mark N
- Posted on: August 19 2004 13:27 EDT
- in response to Jonathan Locke
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). -
Echo vs Wicket[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 13:31 EDT
- in response to Mark N
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. -
Echo vs Wicket[ Go to top ]
- Posted by: Mark N
- Posted on: August 19 2004 13:46 EDT
- in response to Jonathan Locke
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. -
Echo vs Wicket[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 13:23 EDT
- in response to Mark N
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... -
Echo vs Wicket[ Go to top ]
- Posted by: Mark N
- Posted on: August 19 2004 13:48 EDT
- in response to Jonathan Locke
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. -
Echo vs Wicket[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 14:20 EDT
- in response to Mark N
I'm still not sure I understand. If you weren't navigating to pages, what would you be navigating to? -
Echo vs Wicket[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 14:28 EDT
- in response to Jonathan Locke
BTW, I'm not being dense on purpose here... I really don't understand... maybe you can give me an example? -
Echo vs Wicket[ Go to top ]
- Posted by: Mark N
- Posted on: August 19 2004 14:36 EDT
- in response to Jonathan Locke
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). -
Echo vs Wicket[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 14:47 EDT
- in response to Mark N
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. -
Echo vs Wicket[ Go to top ]
- Posted by: Mark N
- Posted on: August 19 2004 14:29 EDT
- in response to Jonathan Locke
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. -
Echo vs Wicket[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 14:40 EDT
- in response to Mark N
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);
-
Tapestry Comparison[ Go to top ]
- Posted by: Ben Wong
- Posted on: August 19 2004 10:54 EDT
- in response to Miko Matsumura
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. -
Tapestry Comparison[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 12:03 EDT
- in response to Ben Wong
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). -
Wicket vs. Tapestry[ Go to top ]
- Posted by: Yariv Sadan
- Posted on: August 19 2004 11:20 EDT
- in response to Miko Matsumura
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? -
Wicket vs. Tapestry[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 12:20 EDT
- in response to Yariv Sadan
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. -
Wicket: Do we need yet another presentation layer framework?[ Go to top ]
- Posted by: Todd Bowker
- Posted on: August 19 2004 14:32 EDT
- in response to Miko Matsumura
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. -
Looking for work. Any Seattle companies want to apply Wicket?[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 19 2004 15:09 EDT
- in response to Miko Matsumura
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 -
Looking for work. Any Seattle companies want to apply Wicket?[ Go to top ]
- Posted by: Adam Sanderson
- Posted on: August 20 2004 18:24 EDT
- in response to Jonathan Locke
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 -
Looks good[ Go to top ]
- Posted by: Chris Tuck
- Posted on: August 20 2004 01:42 EDT
- in response to Miko Matsumura
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. -
Wicket: Hello World Example[ Go to top ]
- Posted by: Godfrey Nangoma
- Posted on: August 20 2004 05:53 EDT
- in response to Chris Tuck
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! -
Wicket: Hello World Example[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 20 2004 12:54 EDT
- in response to Godfrey Nangoma
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> -
Wicket: Hello World Example[ Go to top ]
- Posted by: Gili _
- Posted on: December 24 2004 02:25 EST
- in response to Jonathan Locke
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>
Johnathan,
I don't understand your reply. Can you please rephrase it and/or be more verbose? :)
Thank you,
Gili -
Wicket: Hello World Example[ Go to top ]
- Posted by: Godfrey Nangoma
- Posted on: August 20 2004 06:08 EDT
- in response to Chris Tuck
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! -
Notes from the Tapestry gu.y ...[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: August 20 2004 06:58 EDT
- in response to Miko Matsumura
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 -
Notes from the Tapestry guy ...[ Go to top ]
- Posted by: Howard Lewis Ship
- Posted on: August 20 2004 07:37 EDT
- in response to Miko Matsumura
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! -
Notes from the Tapestry guy ...[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 20 2004 13:44 EDT
- in response to Howard Lewis Ship
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! -
Notes from the Tapestry guy ...[ Go to top ]
- Posted by: Jonathan Locke
- Posted on: August 20 2004 14:09 EDT
- in response to Jonathan Locke
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!!