Jonathan Locke

Greenhorn
+ Follow
since Mar 11, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jonathan Locke

Originally posted by Tomasz Prus:
The power of Wicket is his big awesome community. I heard that Wicket have a lot of contributors. This have some pluses and some minuses. How Wicket leaders secure code quality, design quality and Wicket quality at all.

I'd like ask question for Agile and TDD fanatics "Do You like Wicket?"



a lot of it comes down to democratic process and arguing out decisions. Wicket has a very healthy community decision-making process among the core team. another thing is that not everybody is an equal contributer. some people do more work than others. finally, the work tends to break down into areas and there are de-facto specialists for each area

Originally posted by Josh Brown:
Does the Eclipse plugin work well? I've used some Eclipse plugins that are severely lacking, so I'm a bit wary. What about the plugin for IntelliJ? Have you worked with it at all? How does it compare to Eclipse?



I've actually had my share of problems with the eclipse plug-in. The good news is you really don't need it to be extremely productive in Wicket. It's pretty much all just plain Java and your IDE is already very good at that.
I actually think it's quite a lot worse than that. In some sense many of these standards based frameworks are more or less designed by committee, which is a bit like having several authors write a book. Wicket has something like 20 developers now and has branched out to do a lot of things I never envisioned, but I think this has been relatively painless simply because it started with a single coherent vision.

Originally posted by Martijn Dashorst:


I think the Sun motto is: Innovation happens elsewhere. JSF may have a benefit of being a standard, but it is also its achilles heel. Improvements in the platform arrive at glacial speed because they have to be approved by the committee.

Yes. Thoof ran out of money for hardware long ago. You can read this blog post:

http://blog.thoof.com/index.php/geekery/build-to-scale-our-web-architecture/

about our scalability.

Originally posted by John Todd:
But one drawback -I think- is you hard-code component's name in your Java code :
add(new Label("message", "Hello World!"));
What if you want to change component's name ?
?



The question isn't quite right. You meant 'what if I want to change the components /id/'. The only reason I can imagine wanting to do that is simply to make the id you chose more meaningful to readers of your code. In that case, it's simple refactoring. You change the id in the HTML and the Java so they match up again. A designer would never change it.

But I just realized that you may not know that wicket ids are scoped. They do not have to be globally unique! You can use the id 'message' elsewhere on the same page even. You just can't use it twice /in the same container/. Also, wicket:ids have no other purpose than identifying the Java component that's connected to the tag.

Originally posted by Karthik Guru:

Does tapestry support stateful components and pages like wicket? If it doesn't then the only similarities are that they have swing-like components and work out plain html templates? How about echo? Is there any other framework that manages state/session like wicket?



I don't pretend to understand much about Tapestry, but to my knowledge, Tapestry components are not transparently stateful in the way that Wicket components are. In my own brain, I don't think of Tapestry as truly OO in the way that Wicket is... as in normal Java objects with normal state. If you look back to the Tapestry mailing lists around April 2004, you'll find me asking lots of annoying questions about Tapestry's state management on there. After pissing Howard off, I finally decided that Tapestry had taken the wrong approach to the whole problem. So I think you are correct if you think that Wicket's state management is its biggest differentiator from Tapestry. It's unfortunately one of the last things that people notice when glancing at the two frameworks! That dawns on them later. Ooooh. It's just Java. YEAH. That's kindof the whole point.
A few thoughts and observations about some of the questions asked in this thread:

- I've been using wicket since day 1 (since I designed it) and I'm not being conceited in saying that it's vastly more productive for me than any other web framework. The simple reason is that getting back to Java itself is more productive for me.

- I know nothing about Spring or Spring integration. I love that Wicket supports Spring and someday I may use that, but you don't actually need Spring. You can use any of several Hibernate integration projects, including my own little such project in wicket-stuff.

- Friendly URLs are achieved in Wicket by "mounting" pages or whole packages of pages on various URLs. This is done through ordinary method invocations like pretty much everything else in Wicket.

- There's really no need to integrate with JEE security. Actually, you can write pretty complete web applications without any container-provided feature in Wicket. Wicket's built-in security mechanism is decoupled from URLs and is more OO, component-oriented, powerful and granular than JEE security. I think once you understand it (which should not take long), you will never want to use JEE security again. Not only can you deny access to pages, you can even do something like: don't show this panel unless the user has the admin role. It's extremely easy to do this with annotations or Java. If you really want to externalize it into XML, you can do that easily on your own. You can also write your own authentication or authorization implementation. It's all completely pluggable.

- I think Wicket is actually easier to configure because our configuration is supported, documented and checked by your IDE. If you have an actual NEED to externally configure your settings, you can simply use our API to set values you read from XML... or use something like beanshell to script the whole thing. Personally, I don't find scripting the config calls at all useful on the projects I work on (I just use Jetty, which restarts in no time, and direct config in Java) so I don't do it. But you can do it easily enough if you want to. We do support "modes" (deployment, development, etc) and you can change that in your web.xml, I believe. This seems to be more than good enough for me. If someone really wants to make a module for external config of Wicket settings, we'd certainly take that contribution in wicket-stuff, but I don't view that problem as part of the core. The Wicket core is pretty much entirely a Java API.

Originally posted by John Todd:
Aaaa, I don't mean wicket:id , I mean message.
You hard-code the component name in your code then you refer to it in you HTML page.



Right. This is the only way I can think of to associate code with markup. To say it's "hard-coded" is a bit of a stretch. It's an identifier like any other identifier. Heck, your variables have names, don't they? They're just enforced by the compiler. "Hard-coding" usually refers to CONSTANTS that ought to be externally configurable or at least logically named, like language strings that require localization. That sort of thing is a major pain because localizing the application requires that you "soft-code" all the strings by loading them from a file or other location using, yep, /a constant id/.

I think the valid criticism you meant to bring up is that there isn't IDE support for making sure that the ids match up with the code (we do, of course check that they match up at runtime). However, this is soon going to be a misconception because Geertjan Wielenga (sp?) at Sun is working on a plugin for NetBeans for JavaOne in June which will take care of all this for you! I expect Eclipse support won't be far behind as Wicket really starts to take off this Summer and Fall.

[ April 22, 2006: Message edited by: Jonathan Locke ]
[ April 22, 2006: Message edited by: Jonathan Locke ]

Originally posted by Frank Silbermann:

Though Wicket's implementation uses some ideas taken from Tapestry, the only framework I know of which might have a similar style of programming is Echo.



Just to set the record straight, I only took one very general idea from Tapestry when I created the alpha version of Wicket: using an attribute to associate behavior implemented in Java with markup. Any other similarity to Tapestry is complete and total coincidence because I started absolutely from scratch with Wicket (to be honest, I wouldn't know how to copy Tapestry because after reading the book twice I still didn't understand it very well). The one apparent similarity to Tapestry users is probably the name 'RequestCycle'. However, that is a misconception. I actually did not start out with a RequestCycle at all, but gradually discovered there was a need for it... I picked the name RequestCycle reluctantly and simply because there is no better name for what it represents (and believe me, I thought about it for a long time!). As far as Echo goes, I heard that it generated HTML and didn't support the back button... so I never even downloaded it. Echo simply doesn't meet any of my requirements for a web framework, so it had no influence on Wicket at all.
Of course, now in J2SDK1.5, you would say:

and for an array, you would say the IDENTICAL thing:

and hotspot will take care of all those optimizations as required. nice huh?
20 years ago
Yup. And one more: your disk access will take several orders of magnitude longer than your memory access.
20 years ago
That code is pretty nonsensical for a couple of reasons:
1. It's customary to use java.lang.Object when creating a lock object.
2. The String isn't held in a member variable. It's apparently a local variable, which would mean each thread would create its own lock object and therefore always get access to it immediately, defeating the whole purpose of lock objects.
What you *mean* to write is more like this:

NOTE: method1 is just a shorthand way of doing exactly what method 2 does.
There's a lot more to locks and monitors than this, but does this at least make sense now?