|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 70
Messages: 70
Messages: 70
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Apache Wicket 1.3 released
Starting the new year with a bang, the Wicket Team has released Apache Wicket 1.3. With this release comes a lot of great successes, but most of all the team wanted to express their wishes to everyone for a happy new year.
Apache Wicket is one of the fastest growing Java open source component based web frameworks, based on mailing-list traffic. With a focus on producing valid html and a logical separation between design and code. Within minutes you can start to enjoy throwing out tag soup, complex components and high maintenance overhead for a simple POJO + html data model.
Take a look at some of the following highlights or skip to the bottom and get started now.- Last JDK-1.4 release (next release will be Java 5 based)
- First Apache release: renamed packages to
org.apache.wicket - Simplified several core APIs
- Now works with zero-config behind a proxy server using relative URLs
- Added Google Guice support
- Use your Wicket pages directly in a portal without changing a line of code (JSR-168/JSR-286 support)
- Switched logging API from commons-logging to slf4j
- Integrate velocity templates as panels in your pages
- YUI-calendar and Joda time based date picker (wicket-datetime)
- Adds new javascript dependencies to the page header using an Ajax request - for example, if a component is replaced on the client via Ajax, and the replacement requires script.aculo.us, script.aculo.us and any other required dependencies will be downloaded at need.
- Improved, more robust header contributions
- Scale to extremely large numbers of users with stateless pages and components
- Improved AjaxTree/AjaxTreeTable
- Hybrid URL encoding to make search engines and your users happy
- Create form panels and use them anywhere without worrying about the nesting of form tags
- Minimized session use by storing component hierarchy in file system (DiskPageStore)
Get started today by checking out the following examples or follow the download link directly at the bottom.Best wishes from the Wicket Team and a prosperous 2008!
|
|
|
Message #244369
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released
Hi,
What differences or advantages does this framework has over JSF?
|
|
|
Message #244372
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Congratulations!
Congratulations Eelco, Al, and team! Now hurry up and get that book finished ;)
|
|
|
Message #244374
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What advantages does this framework has over JSF?
What differences or advantages does this framework has over JSF?
JSF is based on JSR 127. Wicket is written by some smart developers...
|
|
|
Message #244380
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What advantages does this framework has over JSF?
Non snarky response please.
What's snarky about my comment?
|
|
|
Message #244384
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why YUI and scriptaculous
The date picker is based on YUI and i see the mention about scriptaculous. Does Wicket need more than one javascript library ?
regards
Ashok
|
|
|
Message #244390
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket versus JSF versus ...
This is such a broad question that you can make a study out of it. I suggest looking at the Comparing Web Frameworks presentation done by Matt Raible at JavaZone'07.
Other links:
There is enough material out there in old TSS threads comparing Wicket versus JSF.
But could google for those links yourself. As TSS is a forum, some discussion is also needed. I'll take the bait :)
As for differences (opinionated, so assume some bias), I think the biggest differences are: the configuration requirements, the templating language and in the ability to create and reuse custom components.
Configuration of Wicket is done in Java or using a single property for sensible defaults. Navigation between pages is done in Java. JSF requires quite some XML to glue things together (faces-config.xml), navigation is done using strings that need to be configured in faces-config.xml).
Wicket uses plain HTML as the templating language (with additional components that allow the inclusion of Velocity or WebMacro templates in your pages), whereas JSF is a mix/match of JSP, JSF tags and JSF EL. Support for plain HTML templates in JSF needs an additional library.
Creating custom components using JSF is something that requires a special role (just as the EJB composer, deployer, etc): it is not for the faint of heart. Creating custom components in Wicket is not rocket science: use the extends keyword (public class MyComponent extends Label). Using the component is as simple as adding a new instance of the component: add(new MyComponent("someid")); Packaging the custom components for reuse in a different project? Put all necessary resources (html, javascript, css, images) in a JAR file and place it on the classpath of the other project. Then use as you would normally do.
Less dramatic, but still noteworthy is the ability to test your GUI. WicketTester provides a really good way to unit test your Wicket application and test all your components in isolation. Unit test support for JSF is just starting to develop (in my understanding).
There are more differences, but these are the biggest that come to my mind.
But there are also similarities: both are component based, both provide the means to build Ajax applications without having to learn JavaScript, and both have passionate developers and teams working to further the technology.
In my opinion Wicket delivers a development experience right now that JSF has promised for a long time, and still hasn't delivered.
|
|
|
Message #244387
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released
Thank you very much for your work on one of the finest Java web frameworks ever. Once "Wicket in Action" is released, this will be, no doubt, Wicket's year.
Regards,
Daniel.
|
|
|
Message #244391
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Why YUI and scriptaculous
The date picker is based on YUI and i see the mention about scriptaculous. Does Wicket need more than one javascript library?
In principle Wicket doesn't need any library other than what is in core.
Instead of creating our own DatePicker component, we looked in the open source marketplace, looked at the various licenses of the JavaScript DatePickers and picked the YUI DatePicker as the best option. So if you use the date picker, it will use the YUI javascript libraries necessary to support the javascript control.
But that is all we use from the YUI libraries (currently).
There are lots of really good javascript libraries available: mootools, scriptaculous, YUI, jquery, rico, prototype, dojo toolkit, etc. Instead of inventing our own library, and instead of prescribing our preferences (not that we are in alignment about that, mind you), we allow people that have a preference to add supporting component libraries for these excellent JavaScript libraries.
Wicket's header contributions enable the use of these tools remarkably well: adding a TinyMCE panel using Ajax to an already rendered page works automatically.
The javascript support libraries are available from our sibling project, Wicket Stuff. So there is scriptaculous support, YUI support, dojo support, mootools support, etc.
So, no Wicket doesn't need more than one JavaScript library, but provides support for lots and lots of libraries. It is just what your application needs that is needed. If you want, you can write a whole application without ever hand coding one single line of javascript, and still have it do Ajax calls.
|
|
|
Message #244393
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
diferences and pros......
there r a lot of differences,some of them r
1-True component model with no exposure to the servlet api
2-Wicket development is all in java ,no xml descriptors(java developer friendly) with all the refactoring capabilities empowering u to enhance ur design
3-There is no logic in the view markup,u even cannot put it there
4-U can develop the view using any WYSIWYG html editor and the result is the final valid wicket markup(designer friendly)
5-True event model very similar to swing's
6-The easiest framework to develop custom component with(the framework encourage u to do much every thing as a custom component and it is VERY EASY)
7-out of the box ajax support with several built in components to use and to subclass
8-Wicket use the new java keyword to instanciate pages(unmanaged framework)very natural to developers, no dependency on a factory or ioc container(the tapestry way)although naturally integrated with other frameworks and ioc containers
9- Page composition is superb and built in (no external lib as facelets) and really is very powerfull,with at least thre techniqus(inheritance,borders,fragments)
10-Pages and views can b statless or statfull
11-built to scale as it is really cluster ready with builtin terracotta support or custom solution can be easily developed
12-Easy and bookmarkable url with the mounted page
13-REST solutions can be easily developed(read above point)
14-Table ,tree and other data aware components use java model similar to swing or jface
15-these models r statfull with proxy backing to reduce to a huge extent the memory consumed by each session
there ra lot of amazing other features,although i focused on diferences from JSF BUT u cannot realise the real power of wicket unless u use it and see how pleasure it is
|
|
|
Message #244394
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: diferences and pros......
u cannot realise the real power of wicket unless u use it and see how pleasure it is
And how easy it is to forget all the benefits you get from using a framework you truly enjoy.
I still remember the day when I had to go back to a Maverick based MVC application and do some maintenance on the pages. It is only then that you appreciate the benefits of Wicket (in this particular case: making a change required updates to 4 files).
Thanks for your list!
|
|
|
Message #244397
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tutorial - Getting Started - New User
Hi,
Congratulations on the new release.
I am looking for a good and simple tutorial to get started with Wicket 1.3. I checked the Wiki and there is a New User's/Getting Started Guide, but it reads "A little dated/incomplete...".
I am looking for a document that explains the basics to get you going with Wicket 1.3. I have seem some examples but they are for older versions.
Thanks.
|
|
|
Message #244401
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Tutorial - Getting Started - New User
Hi Kent. I will get those free chapters. Thanks a lot.
|
|
|
Message #244404
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket 1.3 comparison with Tapestry 5 ?
At first sight, Wicket 1.3 and Tapestry 5 are both
- component-based
- targets a HTML-based template.
While Tapestry 5 use JDK 1.5 annotations, and Wicket 1.3 not, I am sure they share other points.
Has any developper an experience to get a Tapestry/Wicket comparison ?
Thanks.
|
|
|
Message #244406
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released
Congratulations to the entire Wicket team on a superb framework. I migrated an application to Wicket exactly a year back and totally enjoyed it. It is running in production where I work - as well as in lots of places all over the world. I must say the Wicket mailing list support is awesome as well.
Here's Looking forward to 2008: The Year Of Wicket :)
|
|
|
Message #244408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released
Congratulations, sincerely!
Wicket is a nice alternative to the JSF mammoth and the first framework introducing the pure HTML template approach.
I learned with Wicket some key rules of how to develop a developer-friendly web framework (not a tool-oriented framework ).
Jose M. Arranz
Developer of ItsNat, Natural AJAX
|
|
|
Message #244412
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released
Congratulations to the Wicket team and community!
Wicket is the first java web framework that made me enjoy doing web development again. Having the feeling to do clean object oriented code to develop a web app is a pleasure, and developing custom components (like I did for a jquery tab panel for example) is so easy that you can really decompose your application and encourage code reuse over the team.
Thank you so much for such a great framework!
|
|
|
Message #244414
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Congrats
Last 8 months ive done 2 months SEAM (gave up because of dissapointment) and the rest has been wicket. Implemented a small application. I must say im mighty impressed with what these fellows have done (not the docs though). Theres a reason why there are 1000s of web frameworks. Because none have been good enough. But everytime I've felt this "-Damn, another crippled framework", it ends up Im wrong. Wicket hasnt dissapointet me once in these months. Beeing consistent, structured and simple enough for me to reason myself to solutions to every problem. I dont wanna be a framework fanboy or start talking about a revolution - but I cannot really understand how a web framework could be that much better. I add a little but, because I havent seen it in production and under load yet.
Thanx and good luck.
|
|
|
Message #244415
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
To follow the Book Wicket in Action
It is true that documentation is not the best part of Wicket.
But the creators are writing "Wicket in action" for Manning.
I am reading it in Early Access Program and this book explains everything. Now i can say I understand Wicket.
This book will be a must-have for all developpers using Wicket. This book is the best news-to-come for Wicket .
|
|
|
Message #244428
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released: Why stick to HTML?
Congrats to the Wicket team!
Though, from time to time, I ask myself: Why are we still sticking to HTML?
As a Java Developer, I see the future in frameworks such as ECHO2, ThinWire, JSeamless, GWT, etc. because I could do my work using 100% Java without worrying about the HTML/JavaScript/Flex code.
Moreover, some of these frameworks could allow deploying the very same code as a desktopApp or webApp.
|
|
|
Message #244429
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
WicketBench
Unless it's changed significantly since I tried it a few months ago, IMHO WicketBench really wasn't helpful at all.
In fact, since Wicket uses 99% straight HTML, I ended up using Dreamweaver and/or plain text editor to edit the pages for our Wicket project. Since almost everything in Wicket is done in Java, Eclipse code completion is pretty much all you need to get going.
|
|
|
Message #244432
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: WicketBench
Wicket Bench opens all the related files together in one tabbed editor. This saves quite some extra editors. So you have in one editor the HTML, Java and resource bundles, and possibly even related javascript and css files.
Furthermore it provides quick fixes for creating a Page and Panel class, which will create Java and HTML files directly, which is a (minor) timesaver.
Finally it hooks into the refactorings for rename and move (iirc) so not only your class will be renamed or moved, but all related resources as well.
If you get compile errors using the current version when creating a new page or panel, you should edit the templates (Preferences -> Wicket -> templates). It is only the default package name that is borked.
|
|
|
Message #244434
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Quite a narrow sweet spot
I think Wicket is great for a low traffic HTML heavy website and/or you need to support low end browsers (without JS).
However for Ajax style application it is not really suitable. Requests are synchronised on the page object so it is Sjax not Ajax and the dual HTML/component thing becomes a pain when you just want to throw panels, buttons around.
I've also found that because they have gone for many large components rather than composing things of a few small building blocks it is a bit inconsistent and inflexible to work with.
Wicket has a very helpful community so a good choice if you match their sweet spot.
|
|
|
Message #244435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wicket 1.3 comparison with Tapestry 5 ?
At first sight, Wicket 1.3 and Tapestry 5 are both
- component-based
- targets a HTML-based template.
Well latest T5 snapshots aren't coupled with HTML, you could serve more generic XML content just fine as it was HTML.
Have a nice day.
|
|
|
Message #244439
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released
Is it a bit too old when 1.3 is only based on JDK 1.4 and next release is still based on 1.5 only?
|
|
|
Message #244442
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
Just curious x y, what's your framework of choice?
I don't understand what you're talking about when you say it's a pain to throw panels and buttons around. I haven't found this to be difficult.
|
|
|
Message #244444
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
For web based applications I like GWT. Obviously it falls down if you need to support low end clients.
Almost all the styling we do is in CSS so having to maintain the component tree in HTML _and_ in Java component tree is an overhead with little reward. So if I just want a div full of buttons I have to have an HTML fragment lying around rather than just setting the correct CSS style name that I was given by the HTML/CSS monkey.
Talking of him he hates that Wicket needs to take over HTML ids (when using Ajax partial updates) as it makes his JavaScript slower only using class.
Sorry about the x y thing. I tried to set my real name but after filling out lots of other stuff the update didn't work.
|
|
|
Message #244449
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
I think Wicket is great for a low traffic HTML heavy website and/or you need to support low end browsers (without JS).
I've only used wicket a year ago for a very small proof of concept, so I'm not that versed, but I think the above quote is just something you throw around without any proof. Are you saying that wicket is not scalable?
However for Ajax style application it is not really suitable. Requests are synchronised on the page object so it is Sjax not Ajax and the dual HTML/component thing becomes a pain when you just want to throw panels, buttons around.
That's complete BS. Just like in JSF and any other component based frameworks, there are components that are AJAX enabled and some that are not. It's relatively simple to put together a wicket component that will not synchronize the whole page, so again, you have no clue what you're talking about.
Ilya
|
|
|
Message #244450
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
I think Wicket is great for a low traffic HTML heavy website and/or you need to support low end browsers (without JS).
However for Ajax style application it is not really suitable. Requests are synchronised on the page object so it is Sjax not Ajax and the dual HTML/component thing becomes a pain when you just want to throw panels, buttons around.
Actually, Wicket is pretty scalable. Throwing around claims about Wicket not being able to handle high traffic without any actual numbers isn't very helpful. Not to mention that in real world the web framework is rarely the bottleneck.
Ajax is asynchronous in Wicket, having it locked on page instance doesn't change this fact. The requests are asynchronous and the client is not blocked, although the ajax requests are ordered on client and put to queue(s). They have to be in order to ensure deterministic behavior.
The serverside lock on page instance makes good sense, otherwise it would become a nightmare of concurrency bugs. In most of the model 2 applications I've seen noone even bothers to lock things in session...
I've never had problem working with panel or other components, would you mind explaining where the pain is? Preferably on mailing list.
Thanks.
|
|
|
Message #244451
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
For web based applications I like GWT. Obviously it falls down if you need to support low end clients.
Almost all the styling we do is in CSS so having to maintain the component tree in HTML _and_ in Java component tree is an overhead with little reward. So if I just want a div full of buttons I have to have an HTML fragment lying around rather than just setting the correct CSS style name that I was given by the HTML/CSS monkey.
Talking of him he hates that Wicket needs to take over HTML ids (when using Ajax partial updates) as it makes his JavaScript slower only using class.
Sorry about the x y thing. I tried to set my real name but after filling out lots of other stuff the update didn't work.
Just because wicket sets element id for ajax updated elements (which is kinda necessary :), it doesn't mean it's impossible to use the element id to get to the element. You can either pass the generated id to javascript or even set your own (Component#setMarkupId).
|
|
|
Message #244458
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
My two cents
I've been using Wicket for a project at work and I have used struts/JSP in the past and here are my comments.
1. Overall, I like the approach and most of the design decisions. Since I am an OO programmer Wicket translates HTML and Javascript into something I am more comfortable with and I like that.
2. I love the uncluttered HTML and lack of XML configuration. This is one of the best things about Wicket.
3. I found it hard to program some of the things in Wicket. My application has a very complex UI. It was hard enough to get some of that stuff to work in HTML and then having to 'translate' it to Java/Wicket was frustrating at times. To be fair a lot of the frustrations were because HTML sucks and really not due to Wicket. What the Wicket team is doing is really difficult work as HTML/Javascript are so ill defined. However, I did manage to uncover some bugs in Wicket and working around them took some time. Many of these issues are fixed in 1.3 but it did not help me as I am still using 1.2
4. The support for Wicket on the forums is fantastic. The documentation is not too great but the team is very helpful
5. Wicket is a moving target at this time. It's not easy to upgrade from one version to another since there are many, many changes. I think that in the future Wicket will become more stable and easier to work with. It is possible to build production applications in Wicket now but it's still a little on the 'bleeding edge'
6. Overall I think with Wicket you have to write much more code more than with Struts/JSP. However, the Wicket code is much more maintainable and understandable. If you consider that an application usually spends only 10% of it's life cycle in development and 90% in maintainance then it's a fair trade off.
7. The AJAX support in Wicket is really nice. For example, it's fairly simple to update a button title without reloading the page.
I believe that my experience with Wicket would have been smoother if I had started with 1.3 instead of 1.2. As a small example a small bug in 1.2 makes it impossible for me to reload a single cell in a table using AJAX. However, this has been fixed in 1.3.
Congratulations to the Wicket team for a fine framework!
|
|
|
Message #244462
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
Actually, Wicket is pretty scalable. Throwing around claims about Wicket not being able to handle high traffic without any actual numbers isn't very helpful. Not to mention that in real world the web framework is rarely the bottleneck.
I don't think I said that. I just said I thought its sweet spot is in a particular area.
Ajax is asynchronous in Wicket, having it locked on page instance doesn't change this fact. The requests are asynchronous and the client is not blocked, although the ajax requests are ordered on client and put to queue(s). They have to be in order to ensure deterministic behavior.
The serverside lock on page instance makes good sense, otherwise it would become a nightmare of concurrency bugs.
Sorry if I was not precise in my original statement. I was thinking of the queue on the client and the lock on the server side that you mention. I can totally see why it was done but it does seem like a serious limitation to me.
I've never had problem working with panel or other components, would you mind explaining where the pain is?
Ive found in HTML light web applications maintaining the HTML fragments seems redundant. I'd rather just manipulate components in Java and set the appopriate css class names.
Cheers
Sam
|
|
|
Message #244465
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
I've only used wicket a year ago for a very small proof of concept, so I'm not that versed, but I think the above quote is just something you throw around without any proof. Are you saying that wicket is not scalable?
No. I'm saying I think this is where its greatest strength lies. I'm sure it can scale however for my money I'd rather try and get something simpler to scale if it was a high traffic site. But as you say I'm clueless ;)
It's relatively simple to put together a wicket component that will not synchronize the whole page, so again, you have no clue what you're talking about.
As I said in my reply to Matej I'm sorry if my language was inaccurate I was thinking of the queue on the client side and the server side page lock. If you have a way around these it would be very helpful for my current project.
Cheers
Sam
|
|
|
Message #244466
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
Just because wicket sets element id for ajax updated elements (which is kinda necessary :), it doesn't mean it's impossible to use the element id to get to the element. You can either pass the generated id to javascript or even set your own (Component#setMarkupId).
All true. We looked at these but in the end decided it was simpler (code and division of work) to either use a css class name or have a non-wicket div or span. The HTML monkey is just sulking about extra spans and divs ;)
Cheers
Sam
|
|
|
Message #244469
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Wicket 1.3 and Liferay Portal
How easy is it to use Wicket 1.3 application as a portlet in Liferay Portal 4.xx? As anyone tried it yet?
|
|
|
Message #244477
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wicket:id ?
Why do you need to add everywhere in the HTML templates the wicket:id parameters?
Wouldn't it be easier to maintain - for Html guys - to use the normal html "id"? Just like GWT ?
(To me GWT and Tapestry are the closest framework to Wicket)
|
|
|
Message #244478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wicket:id ?
It's the only way to bind the markup component with it's associated java component. Something similar to "bind" from jsf.
|
|
|
Message #244479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wicket:id ?
Why do you need to add everywhere in the HTML templates the wicket:id parameters?
Wouldn't it be easier to maintain - for Html guys - to use the normal html "id"?
The semantics are slightly different as wicket:id only has to be unique relative to its parent. This means you can re-use HTML fragments without having to worry about ids clashing. Having said that it would be nice if an absolute id could be specified in the HTML to override the default behaviour.
Just like GWT ?
(To me GWT and Tapestry are the closest framework to Wicket)
Obviously one of the big differences between GWT and Wicket is that in Wicket the component tree is held on the server side. Lots of pros and cons to this difference. One less obvious difference is that to improve scaling, I think, the components (and any other page state) is serialised. Needing to support serialisation is a bit of a pain but they provide some classes to support attaching/detaching the model etc.
I think Wicket in full Ajax (partial updates) "mode" is very much like Echo.
Cheers
Sam
|
|
|
Message #244480
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Couple of reasons for wicket:id
Hi,
I think when Wicket started they also used normal id instead of wicket:id (not really sure about this). But there are a couple of pro's for using wicket:id.
1. Seperation. Designers like to have control over the ID for CSS etc. Then the developers have their own ID for developing.
2. Wicket:id allows duplicate names in the markup, normal id needs to be unique on a page (according to the standard). On a page with multible tables you might use the wicket:id="row" multiple times.
3. Working together with different frameworks the wicket:id also helps. I think some AJAX frameworks (like prototype/dojo etc?) use the id's, so its better to have wicket use something else so they don't collide.
I hope this will help you understand the choice they made. It looked weird to me too at first, but you get accustomed to it pretty fast.
|
|
|
Message #244481
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released: Why stick to HTML?
As a Java Developer, I see the future in frameworks such as ECHO2, ThinWire, JSeamless, GWT, etc. because I could do my work using 100% Java without worrying about the HTML/JavaScript/Flex code.
Fine, but it breaks the *web development culture*: the web developer/designer usually wants *full control* of the HTML layout.
I invite you to read this article (disclaimer: is written by me, Wicket approach fits well with my thinking).
Moreover, some of these frameworks could allow deploying the very same code as a desktopApp or webApp.
Do you really need this strong feature? I think >90% of web applications have no code shared with desktop app, do you agree?
|
|
|
Message #244483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
For web based applications I like GWT. Obviously it falls down if you need to support low end clients.
Almost all the styling we do is in CSS so having to maintain the component tree in HTML _and_ in Java component tree is an overhead with little reward.
Do you know what is "separation of concerns"? and decoupling?
Independent concepts should be independently represented and should be combined only when needed B. Stroustrup about C++ templates.
The reason that data structures and algorithms can work together seamlessly is ... that they do not know anything about each other. Alex Stepanov about Generic Programming.
Replace:
data structures => HTML layout
algorithms => data model
|
|
|
Message #244484
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
I was thinking of the queue on the client and the lock on the server side that you mention. I can totally see why it was done but it does seem like a serious limitation to me.
Do you like multithread code? do you like coding locks by hand?
Do you know the HTTP 1.1 only allows two concurrent (AJAX or not AJAX) requests per browser-server? No very much concurrency is allowed.
Do you know a processor/core only can dispatch very very few threads concurrently? we are talking about web applications with several concurrent users, every user needs two or more threads? sure?
Do you know servlet containers usually manage a pool of threads? if all threads are used your request must wait.
Of course if you want to run a new concurrent task you can create a new thread.
|
|
|
Message #244486
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
Do you know what is "separation of concerns"? and decoupling?
Have you seen http://www.csszengarden.com/ ? Ive found the seperation of concerns works very well with HTML/CSS developers and me if I produce a nice DOM tree with semantic CSS names and other meta data that the front end developer can work with. Obviously if IE6 implemented CSS properly it would be much nicer.
As I said originally where the application is more HTML heavy then Wicket looks a lot better. I still find that having to match hierarchy between HTML and components is an overhead I could live without. It gets worse when using partial updates as Wicket takes over the id.
data structures => HTML layout
algorithms => data model
Not sure I buy this analogy. I'm just working on a different split. I spit out a semantic HTML DOM tree (concern A) and another deleloper makes it pretty with CSS (concern B).
I thought when CSS arrived we were all excitied because we could get rid of font tags etc. Then we were all pushing to avoid tables for layout etc so that we produced nice clean semantic HTML for screen readers etc...
For what it is worth I find I can work well with just semantic CSS names and the guy that sits next to me being busy with JQuery and CSS.
Cheers
Sam
|
|
|
Message #244489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Quite a narrow sweet spot
Do you like multithread code? do you like coding locks by hand?
Nope. It is a nightmare. Why can't a server handle more than one request per client without application specific multi-threading? Surely I can have a slow task be performed in one thread and do something for the user in another without hand coding any MT code?
Do you know the HTTP 1.1 only allows two concurrent (AJAX or not AJAX) requests per browser-server?
I thought it was a suggestion rather than a hard rule but still seems very handy to allow the user to use the UI incase another action is being slow.
Do you know a processor/core only can dispatch very very few threads concurrently? we are talking about web applications with several concurrent users, every user needs two or more threads? sure?
My main concern (about our large Wicket application) is now having the need to make sure all requests are handled very promptly. Obviously I would want to avoid this no matter what the architecture but now it is even more damaging as the whole UI is blocked meaning the user will probably start clicking more as they find everything "seems to have stopped working".
Do you know servlet containers usually manage a pool of threads? if all threads are used your request must wait.
also if I have a 100 free my poor Wicket user still can't use one.
Cheers
Sam
|
|
|
Message #244501
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
No portlet support
I believe wicket does not have portlet support, so not usable in any Portal server.
Maybe the wicket team is waiting for JCR-268 (next generation portlet spec) to be completed?
|
|
|
Message #244573
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No portlet support
I believe wicket does not have portlet support, so not usable in any Portal server.
Maybe the wicket team is waiting for JCR-268 (next generation portlet spec) to be completed?
Wicket does support portlets out of the box. In fact, one of the core developers (Ate) is also involved in various portlet initiatives and JSRs. See for instance http://www.slideshare.net/ate.douma/wicket-portlet-primer/
|
|
|
Message #244575
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No portlet support
I believe wicket does not have portlet support, so not usable in any Portal server.
Maybe the wicket team is waiting for JCR-268 (next generation portlet spec) to be completed?
Wicket does support portlets out of the box. In fact, one of the core developers (Ate) is also involved in various portlet initiatives and JSRs. See for instance http://www.slideshare.net/ate.douma/wicket-portlet-primer/
Do however check out the various discussions on the mailing list (or ask if you run into trouble). On some portlet containers it should run smoothly, but others might require more work (Liferay for instance).
|
|
|
Message #244578
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Many Thanks
No doubt, Wicket is the most sensible, most enjoyable and most friendly web framework.
I only wish the core developers to stay humble and listen to the needs voiced out in the user land. We've all seen pride of success distroy people, work and future hopes. Pride damages the brain in a way the patient is not aware of.
Thanks for the hard work.
|
|
|
Message #244586
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: No portlet support
I stand corrected.
This just does goes to show I can never trust anything my colleagues tell me.
|
|
|
Message #244606
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Keep up the good work!
I second hoping that the core team remains humble and focused on developers feedback and not engage in excessive vanity (as tragically happened with some in Rails community --- I love Rails though). However, I also agree with their firmly responding to some of non-sensical and amaturish critiques.
Thanks Wicket team for a truely elegant and sensible framework.
|
|
|
Message #244608
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released: Why stick to HTML?
Do you really need this strong feature? I think >90% of web applications have no code shared with desktop app, do you agree?
Don't or shouldn't?
I don't write web applictions. I write applications that might have as one of their UI's a browser UI.
|
|
|
Message #244613
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released: Why stick to HTML?
Do you really need this strong feature? I think >90% of web applications have no code shared with desktop app, do you agree?
Don't or shouldn't?
I don't write web applictions. I write applications that might have as one of their UI's a browser UI.
Of course, almost any desktop application managing "business" data may have a browser GUI (I'm not talking about intensive graphics applications), before the web most of applications where fat client connected to databases, these days those applications have been *replaced* to web applications to avoid maintenance problems. Of course now we have Java Web Start etc but the web approach won.
This "history" is a generalization many applications have two versions, desktop to internal use, web based for clients but to convert semi-automatically a desktop application UI part to the web (using a like-Swing web framework) is not a recommended approach if your user wants a "like a web site" application.
|
|
|
Message #244615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Keep up the good work!
I second hoping that the core team remains humble and focused on developers feedback and not engage in excessive vanity (as tragically happened with some in Rails community --- I love Rails though). However, I also agree with their firmly responding to some of non-sensical and amaturish critiques.
Thanks Wicket team for a truely elegant and sensible framework.
I imagine I come under the category of "non-sensical and amaturish critiques". Strangely the most venom came from people who admitted to "used wicket a year ago for a very small proof of concept" while Matej Knopp, who I think is a core Wicket developer, was very polite, well reasoned and informative.
I've been coding web applications for about 10 years and using Wicket full time for about 5 months so thought I had something to contribute to the discussion. I like robust geeky discussion but I've not really enjoyed the response to my first post on theserverside.
Anyway I honestly wish the Wicket team all the success in the world. I've found them all very polite and helpful.
Cheers
Sam
|
|
|
Message #244616
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wicket:id ?
Thank you for these answers. I did not think about the possible multiple wicket:id-s. But I definitively think this would be nice not to change anything on the HTML pages. So these pages can change easily and the java developper simply decorates the given work of the web guy. "the web developer/designer usually wants *full control* of the HTML layout.". Separation of concerns and Configuration over convention. Which is one of the mantra of wicket (and this is why i think Wicket is better than the other frameworks).
Maybe adding a new signature to the Component where the String wicket:id is replaced by something like that object: new WicketId(String htmlId) (or a static factory WicketId.getHtmlId(String htmlId) ) - where the wicketId represents/creates a wicket:id.
Moreover, most of the time the multiple wicket:id happens in components, not in the pages. In tr/td not in divs... And when you have multiple components with same wicketIds, you will certainly not have access to an html id.
This could lead to java developpers not changing html pages at all. (There is other tags like wicket:remove but still I think one can find a workaround). Anyway maybe this is not the best place to continue the conversation?
But this wicket:id-s somehow shows the other pain with wicket (sorry, guys): one have to code more. As said before, this code is easy to maintain so it may worth the price. But still..Binding the fields of an objet is a long and (most of all) uninteresting work. What about some more configuration over convention where you bind an object to an entire component (and its ids)?
|
|
|
Message #244617
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wicket:id ?
What about some more configuration over convention where you bind an object to an entire component (and its ids)?
One word: CompoundPropertyModel.
It allows you to bind bean properties based on component identifiers.
Form form = new Form("form", new CompoundPropertyModel(person));
form.add(new TextField("name"));
form.add(new TextField("address.street"));
form.add(new TextField("address.zip"));
form.add(new TextField("address.city"));
There is one caveat: when you rename a property, for instance zip to zipcode, then you end up having to rename the textfield's id in both the Java code and markup. Convention over configuration does have its price.
This is why framework builders really want to have a typesafe way to bind to bean properties.
|
|
|
Message #244629
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released: Why stick to HTML?
Do you really need this strong feature? I think >90% of web applications have no code shared with desktop app, do you agree?
Don't or shouldn't?
I don't write web applictions. I write applications that might have as one of their UI's a browser UI.
Of course, almost any desktop application managing "business" data may have a browser GUI (I'm not talking about intensive graphics applications), before the web most of applications where fat client connected to databases, these days those applications have been *replaced* to web applications to avoid maintenance problems. Of course now we have Java Web Start etc but the web approach won.
This "history" is a generalization many applications have two versions, desktop to internal use, web based for clients but to convert semi-automatically a desktop application UI part to the web (using a like-Swing web framework) is not a recommended approach if your user wants a "like a web site" application.
So are you now saying they do share code? :)
Anyway, the "ease" of "web apps" is not maintenance. It is their deployment (which is not always easy). The majority of people have chosen html based browser UIs not for maintenance or deployment issues. They did it because they have the herd mentality. One of the factors in this is that people think you have to do web apps to do enterprise applications. Of course, this is not true.
I highly doubt the web approach has "won". Most users don't like web applications. I have seen the tide turning back to more "desktop" applications.
Those on the bandwagon dumped their desktop apps and went web without understanding what actually was good about them both and figuring out how meet both needs with both. They usually didn't keep both. And if they did, they didn't share anything, sadly. This is why i asked you the question. I think the "applications" could share a lot code and should.
The main application I am currently involved in is a combination of a web enabled Eclipse RCP (for daily users), a Web UI (soon to be 3) for occasional users, and a non-ui-interface for system processes.
I agree with your assessment about web sites and Swing like frameworks, for the most part. I suggest you go look at what Yoxos is doing. With "Web 2.0" the line is becoming more blurred.
http://eclipsediscovery.yoxos.com/discovery/rap
Anyway, apologies to the Wicket people for hijacking their thread.
|
|
|
Message #244631
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released: Why stick to HTML?
The majority of people have chosen html based browser UIs not for maintenance or deployment issues. They did it because they have the herd mentality.
I disagree. Most developers I know would prefer to work on desktop(-like) applications rather than web applications. But companies often do prefer the easier (cheaper) maintenance/ deployment of web applications. For just about every project I've done the last few years a serious evaluation of desktop alternatives was done before going for a browser based solution. The latter always won because customers preferred it and techs like Java Webstart failed to be robust enought (there was always at least one test client with installation problems). Also, I think it is an urban myth that desktop applications are always cheaper to develop.
Maybe something like Adobe Air will change this preference. Believe me, even though I've invested plenty of blood, sweat and tears into Wicket, I'd love to have a good alternative to web applications as they are today.
My 2c
|
|
|
Message #244642
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released: Why stick to HTML?
I disagree. Most developers I know would prefer to work on desktop(-like) applications rather than web applications.
Why is that? Also, when I said "herd mentality", i was talking more about "companies" and management, like you mention in you next statement.
But companies often do prefer the easier (cheaper) maintenance/ deployment of web applications.
This is a perceived value. And thus why i said "herd mentality". I am NOT saying that if you do web apps you are part of the "herd mentality". There are valid reasons for doing it and for using products like Wicket.
For just about every project I've done the last few years a serious evaluation of desktop alternatives was done before going for a browser based solution.
So, then how is the web app easier to maintain ?
The latter always won because customers preferred it and techs like Java Webstart failed to be robust enought (there was always at least one test client with installation problems).
Well, I have had the opposite experience. Web Start has it issues, but so do web apps and those are more difficult to solve.
Also, I think it is an urban myth that desktop applications are always cheaper to develop.
I would have to agree. If I said "always" then I retract that.
The problem is that people say that about web apps. And that, definitely is a myth.
There is way too much that goes into figuring out cost and ease. And what is true today might not be tomorrow.
Maybe something like Adobe Air will change this preference. Believe me, even though I've invested plenty of blood, sweat and tears into Wicket, I'd love to have a good alternative to web applications as they are today. If you develop desktop apps that sometimes need to be web apps or the opposite, check out RAP.
For web sites with application like functionality, I'll give Wicket a deeper look. We are about move to the next phase of our "solution" and this is the type of UI we will be adding.
|
|
|
Message #244645
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released: Why stick to HTML?
So are you now saying they do share code? :)
Sometimes, but not frequently :)
Anyway, the "ease" of "web apps" is not maintenance. It is their deployment (which is not always easy).
Your bank doesn't need to update your browser when their end user bank application changes, it would be nice but they don't want to fix my computer :)
The end user doesn't need to install any software to manage his/her bank accounts.
May be the deployment of a web application is a nightmare but is not the user problem.
The majority of people have chosen html based browser UIs not for maintenance or deployment issues. They did it because they have the herd mentality.
To the end user, web is easy, web is one stop, web is no installations, web is "one click", web is cool, web is "super", web is tons of beautiful (and hot) images... we, software developers, are slave of end users so we must deliver web... :)
I highly doubt the web approach has "won". Most users don't like web applications.
Today the web approach has won, may be someday...
I'm not talking about the web technology is superior to any other. Web development is a hack, but is a hack so cool... and end users love this hack.
I think the "applications" could share a lot code and should.
I agree, this is possible, for instance Wicket's tree uses Swing's tree data model, my web framework, ItsNat, uses *ever* Swing data and selection models. Both frameworks use a component oriented background, this background is "compatible" with desktop development style.
The problem is UI: web UI (technology and culture) is so different to desktop UI ... any attempt to bring the desktop UI to web is interesting but I think is a wrong option unless you are coding a quick port. Is my opinion and of course I'm biased but when I see the source code of a web page of such RIA desktop-like web frameworks I can't breath and my heart stops :)
|
|
|
Message #244646
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Apache Wicket 1.3 released: Why stick to HTML?
So, then how is the web app easier to maintain ?
The latter always won because customers preferred it and techs like Java Webstart failed to be robust enought (there was always at least one test client with installation problems).
Well, I have had the opposite experience. Web Start has it issues, but so do web apps and those are more difficult to solve.
Regarding webapps, I'd like to know exactly what these difficulties are, and how a desktop app provides a better solution.
I'll admit, I'm part of the "herd-mentality"... on just about every front I can imagine, webapps are easier:
- Security
- Languages - not just Java, but PHP, Ruby, CGI, .Net, whatever... maybe I'm out of touch, but it seems that desktop apps are limited to Java and M$ technology.
- Portability - just about every major desktop has a browser.
- Versioning
Java Web Start addresses alot of these issues, but that's just for applications written in Java.
I can think of a couple of advantages a desktop-app would have, mainly:
- More responsive UI
- Scalability
AJAX/Web 2.0 has come a long way in addressing the former. Admittedtly, these are hacks, but frameworks like Wicket and GWT provide enough abstraction so Joe Developer won't have to worry about the hacks. Scalability is a real concern, but for most enterprise apps, the majority of processing needs to happen on the server-side anyway, so having a fat client provides marginal benefits.
I'm not trying to undermine your points... I'd seriously like to know what the "pro-" arguments are in going with a thick-client solution (or more specifically, Java Web Start).
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
