It also ensures that your library is going to be a pain to work with on systems that do shared libraries well. Sure, multiple versions can be installed at the same time, but generally, you only want to do that with major revisions -- especially since you need your app to know which version it needs, while at the same time not forcing them to one particular revision.
Yeah, never do that for minor versions. My experience is though, that you'll always first have a long period of development for a major revision, and a couple of clients with immediate interest in it working on those alphas/ betas. During that period, it's fine to break, and you should take the opportunity to sort your API out. Once you've done that, and churned out your first ga release for a major revision, you shouldn't break clients. So yes, like I said, you should want both.
Maybe so. But I also don't necessarily know my way around everyone else's code, so I don't necessarily know best what the implications are if I make the change there. Generally, if it's an incompatible change, it is actually going to require more than just changing the one line in which my method is called.
It also doesn't address the problem of projects that I don't actually control.
Note that I say: "so it's actually *not always* a bad idea to fix yourself"
Maybe so. I think, though, that if you actually remove the old method (interface, API, etc) and provide a new one, that's sufficient to break it. I think the only difference is whether the break happens at compiletime or runtime, but as we're learning now, unit testing is a must for any sizable project, and unit testing is basically trying to break it at runtime.
Unit testing, the wonderful solution for everything, whether it involves syntax checking or API evolution. Sorry, but I don't buy that.
Yep, I prefer to break hard an early. I would typically make the old method final on abstract classes or remove it if it is part of the interface. That together with library versions in case there are multiple projects depending on it, ensures that no-one will miss it.
I'd also rather have 10 programmers fix 2 calls each than have to fix all 20 calls myself.
But see, *you* are the one making the change, so you probably know best what the implications are so it's actually not always a bad idea to fix yourself. And if it is in one project, or multiple projects in the same phase, just issues one refactor command in your IDE is enough.
Now, I'm not dissing deprecation; sometimes that's a good thing and you don't always have the luxury to break hard and fast. But I'm arguing you should want proper support for both. And static typing is helpful in that.
Yeah, I agree. But it's a short term solution. Unfortunately, in my experience, deprecated warnings are often ignored by people, *even* if their IDE warns them. So chances are you end up maintaining a very bloated API, and having to be back wards compatible can be a pain as well that slows you down properly fixing/ improving things.
I'd have to think very hard to come up with a situation in which I have to change a method signature that's already being used by 10 developers, rather than simply making a new method and wrapping it with the old one. Isn't that the whole point of Java "interfaces", to define a public API and then leave it alone?
So: I think it's extremely debatable that strongly typed == maintainable.
It is. And as you may have guessed by now, I'm in the camp that says strong typing, or rather, static typing, is a good thing.
I regularly do stuff with Ruby for instance. As much as I like the language, it annoys the hell out of me that I spend much of my time fixing stupid syntax errors and googling for object/ method descriptions etc. Same thing when working with Javascript. With static typing and a good IDE on the other hand, navigating through/ discovering APIs is really a breeze, and things like code completion can improve productivity quite a bit. And while refactoring is often a very tedious with other languages, in Java (and again, with a good IDE) it's a breeze.
Of course there is a fine line between how much extra verbosity and rigidity gets in the way of productivity, or how much long term gains cost you in the short term. I'm not as zealous an OO/ static typing fanatic as I may come across here, but I do believe the best APIs are build consistently to a clear vision, and it is part of Wicket's vision to support statically typed (Java) OO programming to the maximum extend. That doesn't mean we think all other ways are wrong, it's just the path we choose.
Wicket's an example of a minimalist concept that refused to grow beyond it in order to satisfy some ideology of "purity".
That sounds pretty negative. Another way of saying is that Wicket stays true to it's philosophy and puts consistency before feature explosion. I don't think giving in to every whim is helpful in developing a robust framework at all.
Refusing to support even a moral equivalent of taglibs is an example.
Not entirely true. See the wicket:message and wicket:link tags for instance. Developing custom ones is fairly easy.
Re:Worse than Wicket?
on
GWT in Action
·
· Score: 2, Insightful
just that one book and some very basic tutorials.
And now Wicket In Action is available (partly) via early access. But agreed documentation could be better, which holds true for most open source projects that depend on unpaid volunteers.
I haven't seen leaky PKs be too much of an issue. A lot of keys are just local identifiers, or your API should be doing requisite security checks.
But it is something you'll always have to be aware about. The application I'm working for for instance, has a very fine grained authorization model. Now, I never have to worry about users accessing the wrong data just by guessing URLs etc; all that information is server-side only. And I know from experience that that would have been quite a different story when using e.g. a model 2 framework.
Re:Worse than Wicket?
on
GWT in Action
·
· Score: 3, Informative
I just don't see what Wicket - or possibly any web framework - buys you.
Maybe especially core Wicket, which isn't trying to do much but wrap HTML bits as objects. What really is the benefit of that?
You're obviously missing the point indeed. What it aims to do besides providing abstractions is facilitate a stateless programming model that is safe by default and doesn't leak implementation details of widgets all over the place.
but often I end up having to put placeholder HTML in the page, and the set visibility = null.
use <wicket:enclosure> an you don't have to use extra placeholders.
And the Ajax support is so-so.
What's wrong with it? It's entirely optional.
I mean, I think the fact that the static Wicket homepages often produce session timeout exceptions is pretty damning that it encourages poor web programming.
If pages are not session-relative, design them to be bookmarkable. All you need to do is put a default constructor or a page parameters constructor in them. With Wicket, you'll have to do a bit of planning for bookmark-ability. But why is that bad? It is secure by default. In contrast with most application frameworks and the REST approach that let you leak internal things like PK's etc by default, so that you'll have to secure your site as a separate effort. Creating a site in the model 2 two way with Wicket, completely stateless, isn't very hard either. Just make pages for every function (like you'd do with actions for model 2 frameworks) and use page parameters to pass your 'state' around.
Re:Worse than Wicket?
on
GWT in Action
·
· Score: 2, Informative
Seriously, after years of Struts and stuff like Wicket, I don't see any real advantage over "Model 2+" (Servlet/JSP pairs) that I started with in 2001. There is a benefit to simplicity and writing HTML in HTML and writing Javascript in Javascript that over-engineers who are, frankly, a little OO-obsessed just don't get.
Sorry to hear it doesn't work for you. A little OO-obsessed though? Because the framework takes a stance to actually try to provide a real OO programming model where other frameworks simply don't?
I agree that there is a lot to say for simplicity. Especially if your problem is simple. However, my experience is that model 2 just doesn't cut it. I shudder to think back to the horrible instances I've seen of code duplication you get when you can't properly reuse widgets and the tons of hacks I've seen to get around the statelessness of web applications. And then scripting in templates, making them hard to sync with changed designs/ hire a designer to work on them and simply hard to track where logic is put in the first place. I don't know about you, but I never had much fun refactoring JSP and Velocity templates.
Wicket focusses on OO as that facilitates reuse and lets you better cope with complexity. Wicket enforces clean templates so that you won't get yourself into maintenance hell. But it may or may not work for you. It does for me and many others, but so many people, so many tastes. In the end it is a trade off that can be annoying in the short term, but should save you trouble in the long run.
Maybe years of Perl CGI has bent my brain but The HTTP Request/Response paradigm just doesn't seem so awful that it needs to be (leaky) abstracted away.
If what you are trying to do fits the request/ response paradigm, that's fine. I for one, prefer to reason about screens that have panels, forms, fields, tabs and buttons on them, and I don't want to rewrite half of my pages just because I decide to put a wizard in a tab, or move a pageable list to another page or whatever.
If you can use Ajax all the way, a simpler approach like using HTML + JS and maybe DWR should work fine, though a library like GWT should help you avoid all those nasty browser issues etc, AND let you write strongly typed (maintainable) code.
Slashdot Mirror
Because you can have that same method name/ sig implemented in many classes.
Yep, I prefer to break hard an early. I would typically make the old method final on abstract classes or remove it if it is part of the interface. That together with library versions in case there are multiple projects depending on it, ensures that no-one will miss it.
But see, *you* are the one making the change, so you probably know best what the implications are so it's actually not always a bad idea to fix yourself. And if it is in one project, or multiple projects in the same phase, just issues one refactor command in your IDE is enough.
Now, I'm not dissing deprecation; sometimes that's a good thing and you don't always have the luxury to break hard and fast. But I'm arguing you should want proper support for both. And static typing is helpful in that.
My 2cYeah, I agree. But it's a short term solution. Unfortunately, in my experience, deprecated warnings are often ignored by people, *even* if their IDE warns them. So chances are you end up maintaining a very bloated API, and having to be back wards compatible can be a pain as well that slows you down properly fixing/ improving things.
Yeah. I'd call it quick fix, but not a solid long lasting solution. But maybe that's just me.
It is. And as you may have guessed by now, I'm in the camp that says strong typing, or rather, static typing, is a good thing.
I regularly do stuff with Ruby for instance. As much as I like the language, it annoys the hell out of me that I spend much of my time fixing stupid syntax errors and googling for object/ method descriptions etc. Same thing when working with Javascript. With static typing and a good IDE on the other hand, navigating through/ discovering APIs is really a breeze, and things like code completion can improve productivity quite a bit. And while refactoring is often a very tedious with other languages, in Java (and again, with a good IDE) it's a breeze.
Of course there is a fine line between how much extra verbosity and rigidity gets in the way of productivity, or how much long term gains cost you in the short term. I'm not as zealous an OO/ static typing fanatic as I may come across here, but I do believe the best APIs are build consistently to a clear vision, and it is part of Wicket's vision to support statically typed (Java) OO programming to the maximum extend. That doesn't mean we think all other ways are wrong, it's just the path we choose.
Sorry to hear it doesn't work for you. A little OO-obsessed though? Because the framework takes a stance to actually try to provide a real OO programming model where other frameworks simply don't?
I agree that there is a lot to say for simplicity. Especially if your problem is simple. However, my experience is that model 2 just doesn't cut it. I shudder to think back to the horrible instances I've seen of code duplication you get when you can't properly reuse widgets and the tons of hacks I've seen to get around the statelessness of web applications. And then scripting in templates, making them hard to sync with changed designs/ hire a designer to work on them and simply hard to track where logic is put in the first place. I don't know about you, but I never had much fun refactoring JSP and Velocity templates.
Wicket focusses on OO as that facilitates reuse and lets you better cope with complexity. Wicket enforces clean templates so that you won't get yourself into maintenance hell. But it may or may not work for you. It does for me and many others, but so many people, so many tastes. In the end it is a trade off that can be annoying in the short term, but should save you trouble in the long run.
If what you are trying to do fits the request/ response paradigm, that's fine. I for one, prefer to reason about screens that have panels, forms, fields, tabs and buttons on them, and I don't want to rewrite half of my pages just because I decide to put a wizard in a tab, or move a pageable list to another page or whatever.
If you can use Ajax all the way, a simpler approach like using HTML + JS and maybe DWR should work fine, though a library like GWT should help you avoid all those nasty browser issues etc, AND let you write strongly typed (maintainable) code.