April Fool's Joke? Pure Servlets

by Tim O'Brien

There was recently a post on TheServerSide that pointed to an article on DeveloperWorks titled, "Pure servlets: Rethink the view" by Jason Van Cleve. I read it, I read some of the reaction to the TSS thread. (read on..)

38 Comments

Robert
2007-04-04 14:17:08
I would not like to maintain that. I would probably introduce something like "Freemarker" and start cleaning it up a bit.
S
2007-04-04 14:34:50
When I saw that, I thought 'are you kidding?'


But since I can find NO negative articles on the net about GWT and I feel the same way about that, I'm assuming the Java community has a significant capacity for collective stupidity :)


Michael Podrazik
2007-04-04 14:42:51
I saw this and my jaw dropped in disbelief that it was being advocated as "advantageous" or as an "alternative" to other Java web frameworks. Strictly speaking it is an alternative, I suppose, but so is putting all the code to your application in a single class with 750 static methods. Not advantageous, to put it mildly.


The only scenario where one could even attempt an argument that this was acceptable would be something like a one-page, one-servlet, one-off. Even then I would argue that the equivalent templatized implementation was warranted. It takes only a handful of lines to initialize and render a Velocity template, for example.


The promotion of this article by TSS and DeveloperWorks really is a joke on the entire Java community...

Michael Podrazik
2007-04-04 14:49:50
S,


I don't think the comparison between the above monstrosity and something like GWT is apt. GWT, Wicket, Echo2, etc. are really no different than Swing, SWT or other windowing library, just attempting to port that programming model to the web application domain.


It's fair to argue that that approach is stupid. This on the other hand is truly beyond the pale. It's not trying to abstract the markup. It's taking all the limitations of scriptlet-based JSPs and throwing in some obfuscation and rigidity to boot...

George Jempty
2007-04-05 05:24:40
Sure you don't want to generate HTML using response/out. But I think the point is that all the frameworks I've seen abstract you too far away from the Servlet API. For instance, why do we *always* need a dispatch/front controller? Why shouldn't I be able to map one request to one servlet? A framework that truly adheres to the principles of reusability and simplicity would provide this sort of interface, and then build upon that to also provide a dispatch/front controller.
James Carr
2007-04-05 06:40:55
S Said:
But since I can find NO negative articles on the net about GWT and I feel the same way about that, I'm assuming the Java community has a significant capacity for collective stupidity :)


O'Rly?
http://my.opera.com/hallvors/blog/2007/03/27/how-to-say-hello-world-with-javascript


But in reference Jason's article... it must be a joke. IT MUST!

Bruce
2007-04-05 08:01:34
Glad I'm not the only one who didn't "get it". Writing "out.printBeginTD" in java instead of "" in a JSP doesn't seem like a step forward.
Jake
2007-04-05 08:06:09
I don't think it's a joke :(


Does anyone actually do a sanity check on content before it's posted?


2007-04-05 10:33:00
I checked out the author's website and my goodness! 1997 called and wanted it's poor usability web designs back!


http://www.vancleve.com/help/Menu#introduction

robert
2007-04-06 01:55:51
"I checked out the author's website and my goodness! 1997 called and wanted it's poor usability web designs back!"


-> this is called 'Barrier Free Web Design', no tables, just divs

Theo
2007-04-06 05:31:08
I maintain a website which has a code base not unlinke that code snipplet (I was not the original developer). I have started refactoring countless times, but I always decide it's not worth the trouble. Better leave it to die by itself. The parts that do change I have managed to refactor to use XSL for the presentation, but there is still so much ugliness below that.
Maurizio
2007-04-06 07:34:10
I think a combination of Velocity or Freemarker plus a nice tool like Stripes should do the job without the complexity of other MVC framerworks but also without jumping back by 8 years.


Cheers

Rupert
2007-04-06 09:03:44
I dunno. This is no worse than any JSF/JSP/PHP/ASP application out there today. If anything, the structure is simplified with the Servlet example because there are not as many 'moving' parts.


The whole point is being missed. The web sucks, be it 2.0 or otherwise. Shoehorning applications to run on a web browser is a mistake. They're complex, slow, and not guaranteed to run on all browsers in the same fashion. Swing is the future, not this or any other HTML based complex applications.


GWT is a step in the right direction, but it still must use the whole client/server paradigm and ultimately rely on a browser.


On a professional note, O'Brien's snotty attitude reflects a juvenile mind( which perhaps he is ). Word to the wise, drop the 'tude and insults and be civil. You look like an arse otherwise.

Tim O'Brien
2007-04-06 09:31:18
@Rupert, you are right Rupert, the web sucks, no one uses it and everyone I know if moving toward a future dominated by Swing.


To say that this is just as bad as the ASP/PHP/JSP/JSF approaches out there is to say that we should just retreat, we should judge all technical approaches against the lowest common denominator because, we'll all web technologies are terrible. You ignore the renaissance that is happening in Java web frameworks - but you probably can't be bothered to actually take a look at the richness that is available, because Stripes, Struts 2, Wicket, Tapestry, JavaServer Faces, JRuby, Grails, Echo....all that stuff is just as bad as ASP/JSP/JSF/PHP. Yeah, that's a pretty anti-intellectual reaction to an abundance of choice.


PS, there's nothing wrong with telling people they are just flat out wrong, especially if they produce featured articles selling "out.println" as a templating technology. Apologies if you'd rather I heap praise on this approach.

Rupert
2007-04-06 10:12:06
I simply said the whole web paradigm sucks, I never said that it isn't used. Plenty of bad ideas are in use. Their usage in no way reflects their merit.


I've used 75% of those frameworks for at least one moderately complex project over 7 years. JSF was used the most, so I'm speaking from experience, but of course everyone's mileage may vary. Web browsers were never made for application development, neither is the HTTP protocol. You can hack it, build on top of it, but ultimately something superior will supplant it.


There's nothing wrong with telling people you think they're wrong, but it's all a matter of style. But, whatever. Keep it up if it works for you.

Jason Van Cleve
2007-04-06 10:28:16
But, how do you fellows *really* feel about my design? Well, I was looking for criticism, and how better than to leap into the midst of one's most vehement opponents, as it seems?


I was hoping you folks would offer some clarification of how this simple idea is indeed so abominable, having put it forth not as a prescription for "the way" to do things, certainly--no snake oil here--but as a design that has served me admirably, and which might serve others in like circumstances. I've built several UIs this way, as many professional as hobby, and as a pragmatical matter it's proven its efficacy, so I consider it a valid means of getting things done. It isn't meant for shops with actual JSP designers, by the way.


Among the primary design goals is reuse, which seems more critical to Web interfacing than to many other problems, and which of course we haven't abandoned just because it was in use in 1997. I don't argue that 'out.printErrorDIV("pure servlets bite")' is cleaner than '<div class="error">pure servlets bite</div>', but encapsulating more complex structures as methods certainly is. Reusing those in the form of taglibs, the most popular solution, is relatively cumbersome, and we end up writing HTML in Java anyway, character-by-character in that case.


So now we attempt to abstract the HTML completely with projects like Echo, which is a completely different animal, and such abstractions have problems of their own. I don't question those designs, but I've yet to see that elusive holy grail.


Tell me, then, specifically what problems does this design create, Mr. O'Brien? That it doesn't look like HTML? How is this code so unmaintainable, considering there is a learning curve to every alternative? I've found it quite the opposite, compared to the standards-based projects I've worked on; and yes, in my experience it amounts to far less code than JSP systems. (Thirteen hundred statements is not a lot for a view layer.) And how is Java a "templating language", as you've told me? That's a rather dubious classification, don't you think?


Mr. Podrazik, what are the "limitations" and "rigidity" of which you speak? Note that every aspect of the output can be controlled and customized with this code, with little impact. Are you referring to the encapsulation of output code as methods? Isn't that just the shape of reuse as achieved simply through Java language features?


You seem to be focusing on the syntax, which is where the learning curve lies, granted. But the idea wasn't to promote the specific API I used, rather to show that, using such an API, a pure-servlet design can be very expedient. Exactly how is it not so?


Oh, and Mr. O'Brien, if you will, what was your point about my statement that good HTML means keeping style in the style sheet? I'm afraid I missed that one altogether.

George Jempty
2007-04-06 10:45:36
@Jason Van Cleve


Your design suffers from the same flaw as Struts does with its "execute()" uber-method: doBoth() does not provide a sufficient separation of concerns, it is in essence a "God" class/method. Your design is not easily extensible so as to be able to base a dispatch/front controller upon it. Furthermore, you have not sufficiently distilled a solution that can be trivially ported to other languages/platforms.


OK, I know the last two are asking an awful lot. Larry Wall says one of a programmer's chief virtues is hubris, and notwithstanding, I believe I've developed a solution to Web/MVC that addresses all of these issues; my manager last summer, a former Smalltalk programmer, and more recently a Java/Struts author, compared my approach to Smalltalk, and I subsequently ported the concept to PHP in mere hours. Next up, Lua, which does not suffer from an overabundance of web frameworks. Anybody, feel free to whois my web address for my email contact.

Jason Van Cleve
2007-04-06 12:37:09
Mr. Jempty,


Thanks for some valid input, but can you be more concrete with regard to extensibility? The essense here is just to build reuse into the output writer, not to dictate a servlet framework. What would impede me from building a front controller, if it were called for? Note that my design is not a framework, nor would I agree that that's its logical end.


I used to make Smalltalk myself, by the way; but as far as porting to other languages, I think you've misinterpreted the scope of my article. I'm not looking for the Cosmic Solution at all, just trying to demonstrate the peculiar advantages of a straightforward design--to show that an adjustable wrench sometimes fits better than a vice grip. It's certainly debatable the range of projects to which this design would apply, but it's been effective for mine.


And Rupert is right on about those moving parts. With pure servlets, for example, I can avoid repackaging display data in order to pass it through to the template, and that makes debugging much easier.

fenix
2007-04-06 16:09:56
Wow - so this was actually a real article. Everyone at my job thought this was a joke too...
anonynous
2007-04-06 16:29:50
[ comment deleted, it was (IMO) too much of an anonymous personal attack on Van Cleve - O'Brien]
mike33
2007-04-06 21:18:48
@anonynous education doesn't always indicate how good (or bad) an engineer is. There have been plenty of great engineers that don't have 4 year degrees.


That said, I really can't see your viewpoint on this Van Cleve. To state that using using pure servlets is superior in *any way* to , JSP, or XSL is almost laughable. Your primary arguments of being "pragmatic", avoiding "astonishingly complex" frameworks, or the "relatively cumbersome" taglib libraries seriously raise into question your technical ability.

mike33
2007-04-06 21:21:32
my comment got cut out there... it was supposed to say [insert web framework here], JSP, or XSL...looking forward to arguments on that
James Carr
2007-04-07 07:11:33
@Jason


Thanks for responding... it takes a lot of guts to stand up to your crictics, and I have to say I think that is quite respecatable.


Why do the majority of us think this is bad? I've lived the nightmare of having to mantains sites written like you describe... they tend to be highly unmaintainable and trivial changes are rather difficult, because design and logic are tightly coupled.


Additionally, in many shops the web designer and programmer are different roles, and the designer SHOULD NOT have to know java to change the web design. Also, from experience, many consulting jobs end with the "highly paid java developer" being paid and the company using their web designers they have on hand to make cosmetic changes... with your setup they are bound to always run back to the java developer for each cosmetic change they need (good for the developer's income, but dishonest).


I would note that I have seen people get away with a design such as yours and be able to maintain it, but I am not one of those people (and I am sure many others aren't either).


@anonymous


I would highly doubt that education means much. I have met someone with a Masters in Computer Science who was the WORST coder I ever met, and yet one of the brightest coders I know didn't even attend college.

Jason Van Cleve
2007-04-07 10:55:13
mike33,


In *any way* superior? Well, as I've mentioned, it results in less code, and business objects go directly into the output, without being shuffled through the request object. These things simplify debugging. I've described several other advantages in my article, so feel free to read that and refute them point-by-point. Another is that dynamic output logic is better expressed in Java than with logical taglibs.


As to the latter, I believe even Mr. O'Brien agrees that taglibs are cumbersome. Each requires a new class, complete with accessors, and an XML description. Can you argue that's easier than just adding a method? This is the "pragmatic" case, by the way. In my experience, taglibs don't go very far, because developers seldom write more than a few of them before deciding they're not worth the trouble. Encapsulating output in Java methods is more straightforward, and they can build on each other, so reuse can be maximized.


I don't see that it reflects on my ability to prefer these expediencies, where they apply. Anyway, I was hoping someone could refute these claims specifically.



Mr. Carr,


Thank you for playing fair. I have to reiterate that pure servlets are for Java coders who have to write and maintain their own HTML, not for shops with designers who can maintain the JSP or other template code themselves, so you're quite right with regard to that. I'm coming from a career involving few such designers. The ones I have worked with could hardly write usable HTML, much less JSP, and I'm sure I'm not alone in that. If you're fortunate enough to have a design team, then pure servlets obviously aren't for you. I thought I said that in the article, but maybe it didn't come across.

mike33
2007-04-07 13:41:29
I guess we can agree to disagree then. I can tell you one thing though, if you continue to advocate this it's going to hurt you (assuming you do this) professionally - and not because its against the norm -- because its just wrong on so many levels. You are going to find very, very few educated, experienced people that agree with you on this.
Anonymous
2007-04-07 20:32:09
Sheesh, why not write everything in assembler, and get rid of annoying complexities like the JVM. Oh, that's right somebody invented something easier to


1. Understand
2. Separate
3. Deploy
4. Maintain
5. Communicate
6. Divide amongst multiple developers


I'd say the author of pure servlets is about half of the way along the design realisations path, somewhere towards the end of the bit where you are the sole author and maintainer of the application. Pure Servlets probably could be more productive in this situation. May as well just stick your db access code in that servlet as well. Straight JDBC, naturally, since that ORM stuff is overly complex. What idiot thought of that - here, look, I can access the database directly from my servlet. 3 lines of code. Pucker mate. Software engineering is way over-hyped these days.


Seriously though - a point that seems to be lost here - JSP's are servlets - the conatiner compiles JSP pages into servlets. So why is that? Well, someone thought up servlets, and decided that writing your view in java was a real pain in the arse, and gave us an alternative way of writing a servlet that was supportive of view design. So when you write a JSP, you are writing a servlet, just in a way that is more conducive to page design.

John Zabroski
2007-04-08 14:44:03
I think the heart of this discussion centers around re-use.


We're still looking for the perfect way to re-use effort and save ourselves development time. The more effort we save, the more agile we become.


Tag libraries are not time-savers and their semantics are broken. Van Cleve's approach is kludge and although it may work for him, I refuse to try it because I have a complete lack of faith I could pull it off.


The coolest thing I've seen in this domain is the combination of using Groovy's built-in support for the GoF Builder pattern via the abstract base class BuilderSupport. A guy is working on WicketBuilder, and his work is part of the 1.3 branch of Wicket. Wicket, incidentally, is in Apache Software Foundation incubator phase. The example code of WicketBuilder's power is less than ideal, but you can already see how it simplifies re-use of effort.


Just my 02 cents; I have nothing bad directed towards Mr. Van Cleve and I wish everyone would stop snickering and instead start thinking about good solutions, however ludicrous and stop being afraid that others will sneer; some people are just incubated by the idols of cynicism.

Tim O'Brien
2007-04-09 04:26:58
The education comment was irrelevant, it is gone.


@John, "some people are just incubated by the idols of cynicism" - what? No, some people actually have enough sense to stand up and say" enough", we can't sit and let this one pass us by without saying *something*.

John Zabroski
2007-04-09 08:33:25
@Tim


I am adamant about constructive criticism, because it cuts straight to the truth.


Mr. Van Cleve states MVC "really isn't the panacea it's cracked up to be, and Web frameworks that support it tend to be unwieldy." However, the one thing he doe s not state is how many layers an architecture should be. No one here is even discussing this, either. Every time I look at a Web framework, I look for keywords and most tend to be missing them. Why are they missing? If you are going to build a Web framework from the ground-up, then be a true architect and identify its foundation.


When I talk about cynicism, I mention it because it is true. Programmers do not like things radically different from what they are used to. Developers of Web frameworks do not have to defend their decision to use a three layer architecture because everyone else is used to it. The biggest example in software engineering of this phenomenon: Bjarne Sjoustrup did not have to defend using the syntax of C when creating C++ because everyone else was used to it. Moreover, because everyone else was used to it more people were willing to adopt it. Suddenly, object-oriented programming did not seem so foreign. In fact, you could use C++ and ignore most of its OOP features. However, C++ inherited C's problems and its taken committees considerable time to go from being "based on C" to "diverging away from C."


However, Mr. Van Cleve is also exhibiting tunnel vision here. MVC is, at its core, an aggregate design pattern. Design patterns can be reified a myriad of ways. Making a design pattern REAL is what matters. Some implementations of design patterns are stupid. This is why "drag and drop" design patterns are a bad idea: Design patterns have to be tailored to the problem application domain, not shoehorned in based on examples given by GoF. Its difficult to say MVC is unilaterally bad because that opinion is based off how we've seen it apply.


I believe MVC is as much an anti-pattern as it is a pattern. I believe a three-tier architecture is probably the right approach, and I believe conceptually breaking them down into "Model", "View", and "Controller" is close to what we've needed thus far. Prior to AJAX, our web applications used "UI Projection" models. In fact, because the UI was simply projected to the client, smart application tuners could cache the UI descriptor and elide the View layer processing code in lieu of caching the UI descriptor. At that point, UI projection becomes store-and-forward. However, the rise of AJAX, XAML and XUL is challenging what we know about UIs on the web. Projection UIs are dying. Pre-AJAX web applications are dying. Traditional desktop UIs are dying.


We're seeing both web UIs and desktop UIs being rethought. Why? Two reasons: (1) We have the available hardware resources (over 90% of a modern GPU is dedicated to 3D processing) and software resources (Portable Network Graphics format) where APIs can provide sexy user interfaces with alpha channel blending modes and 3D desktops like Beryl. (2) The view is not a function of the data definition, so it should not be tightly coupled to it.


On the desktop side, this means more GridBagLayouts and FlowLayouts that let the rendering libraries decide how the content gets displayed with moderate guidance from the designer (just like we've been doing with HTML since late 90s). Run out of space in your application? You've got dockable windows and movable toolbars, CardLayouts, etc. About the only thing we haven't mastered is getting developers, like Eclipse project developers for instance, from using horrible "mystery meat navigation" menus in their applications.


What software engineers have effectively accomplished so far is stopped the Visual Studio "Project Wizard" madness, somewhat eliminating the complexity of Form1.Designer.cs (a code generation resource script that should not be touched lest the code generation wizard get confused and eat itself). Stopping this madness is a step towards removing "Dialog Editors" entirely from IDEs. What it also accomplished is it shielded us from the scrillions of API calls modern rendering interfaces have available. This is what Frank Sommers at Artima calls "The Real Lesson of Flex": He submitted that Flex's code generation shields us from the parts of the application we don't need to understand.


Of course, the flipside of this is that to some extent there is now a wall between us and the View layer. We don't fully comprehend the View layer because it is too complex for us with all its scrillion API possibilities. However, it is incumbent upon us to accept this. Why? Rendering modes. Modern web browsers support different rendering modes because not everyone is viewing the application on the same device. MVC was, as I said earlier, great for "Projection UI". At that point in time, we had one View. MVC proved to be very good for a one-to-one view to data store and there was nowhere near as much chatter about MVC in the mid 90s about MVC pros and cons. MVC's explosion is a "Web 2.0 Phenomenon", but we've yet to see a particularly good reification of the MVC aggregate design pattern that is acceptable for multiple views.


So, I therefore submit that we're not really talking about what really matters here. Start at the bare basics of architectural principles. Select your layer model. Then defend it. Then be honest about its benefits and don't succomb to sounding like a marketing department. Too much inferior technology gets used simply because people are good at marketing. Marketing exists for one purpose: to posit the good and cheekishly ignore the bad.

John Zabroski
2007-04-09 09:14:43
By the way, when I say, "Then be honest about its benefits", I mean that just because you chose a particular aggregate design pattern does not mean all the potential benefits will be realized. You might focus on certain benefits more than others, and completely leave out other benefits based on your implementation.


A great book on this subject is Henry Petroski's "Design Paradigms: Case Histories of Error and Judgment in Engineering". Petroski isn't a software engineer, either, but he seems to know exactly what it is like to be a Programmer/Architect. I feel Design Paradims is the natural complement to Christopher Alexander's Pattern Language.

Jason Van Cleve
2007-04-09 15:33:27
Anonymous the latter,


Quite a few people have taken that same hyperbolic tack, but I think it's a mistake. Simplifying the view does not imply doing everything at the lowest possible level. You (almost) always want to separate business and data-access logic, so that it's not tied to a particular presentation layer. Nor, by Occam's Razor, should you split things apart more than is necessary, and in a Web interface, control is very much bound up with the view. Rather than trying to abstract the view, such that it can be morphed to suit different client interfaces, I opt simply to keep it lightweight.


But you're right in this regard: my approach applies where it's Java developers who have to write and maintain the view, not where there is a competent design team. We know JSPs are servlets, but not all Java coders agree they're the best way to express dynamic page output. Reuse is a factor, as Mr. Zabroski has explained. I've also argued that expressing output logic without using scriptlets or logical taglibs is advantageous.

Michael Podrazik
2007-04-10 09:07:33
First let me say that I find the comments, (now removed), regarding educational institutions and what they have to say about a given individual's programming ability groundless and simpleminded, and the intended implication to be offensive. This industry should be a meritocracy, and your standing in the community should be governed by the strength of your ideas and proven experience rather than traditional credentials. That said, nobody has license to impertinently disregard established principles under the cover of throwing off the shackles of orthodoxy.


I'd like to bring it back to what Mr. O'Brien was getting at with his aviation engineering example. I think that the reason that most people here reject Mr. Van Cleve's approach, (and mock-dismiss it as a joke), is because the concept of separation of concerns is axiomatic in our field. The value of SoC, (and MVC as a manifestation of it), is not a personal opinion or individual style, but rather a self-evident truth to those who have been involved with large, complex systems developed by a team of people working in concert.


There is a difference between presenting a revolutionary alternative after questioning the status quo and offering a past-rejected model as a solution to a misrepresented problem.


As a community, we should encourage each other to stand up and not be afraid to say the emperor has no clothes when warranted. While Java web frameworks are not homogeneous, each having it's own advantageous and disadvantageous, it is fair to say that many if not most or even all of them suffer from undue complexity when their goal is the structuring and reduction of complexity. At risk of going off topic here, the revolutionary response and "emperor has no clothes" challenge to this is exemplified by Ruby on Rails and the influence that it is having to our collective thinking about the webapp problem. Note also that RoR is an increase in abstraction, which furthers the unmistakable trend in the entire history of programming from the low-level to the high-level.


The so-called "Pure Servlets" approach is like marveling at your overcoming of gravity by observing how high you can jump. That may sound flippant, but they actually bear some resemblance in the sense that both are extremely limited and rely solely on the effort expended by the individual. As jumping requires physical effort, the approach discussed here puts all of the onus on the individual programmer to manage the complexity intellectually with no assistance by the framework. And it is a framework of sorts, it just happens to be a roll-your-own rehashing of CGI in Java form. Note that this is a reduction of abstraction, which is on the wrong side of that same unmistakable historical trend mentioned above.


To address Mr. Van Cleve's question of me directly, I and numerous experienced colleagues of mine have worked on many systems with code resembling what you're advocating and have unanimously and unequivocally found them to be fragile, obtuse, not conducive to team labor and just plain unmaintainable. They are change-resistant, in the sense that opening them up to modify the presentation brings you face-to-face with what would be controller code in a MVC model, if not model/business-logic as well. It is limited in that the complexity is magnified the more involved the requirements become and it is rigid in that it is tightly coupled together. Furthermore, Java is a fine programming language but a terrible templating language. The idiosyncratic nature of this makes it unclear what the view looks like unless you have intimate knowledge of the magic constants and output stream methods.


A possible counter-argument to this is that for simple projects you don't need a full-blown framework; that that just adds more work than necessary and the labor involved in managing the framework would end up being a large percentage of the total work to implement the application. Agreed. There are some projects that do not require the full blown framework approach. I would not use this approach even in small projects though. It is possible to achieve SoC without the investment in a full featured framework. As I mentioned in a previous comment, it requires only a handful of lines to render a Velocity template, for example, which would give you an advantageous separation. Bottom line, there are any number of trivial, superior alternatives. There are trivial, superior, BAD alternatives. Why is this in a servlet again? Why not just use JSP and scriptlets if you must mix markup and code? Even that would be less obfuscated than this.


As I think someone stated before, this is not any kind of personal attack against Mr. Van Cleve, it is, however, an attack on the concept promoted, which I do not believe had any business being on developerWorks. Perhaps the most interesting part of this is the realization that nobody was minding the store at that publication, apparently. We should all be happy I suppose that there is no orthodoxy in attendance that we need to rebel against after all...

Jason Van Cleve
2007-04-10 14:56:56
Mr. Podrazik,


I appreciate the care you've taken here. In fact, you may be guilty of making too much of my article, as if I've couched my little design as a "revolutionary alternative" at all. Mine's a practical perspective, and it's not impertinent to suggest that SoC can sometimes drive us to needless complexity in practice. I have been involved in large projects, and even then I found myself writing my own view components, because our designers lacked the coding skills to handle JSP. Where this is not the case, I should not advocate pure servlets.


It seems fair that I should stand on my own experience here, in which developers almost invariably write the control modules together with their views, and in which the results of a simpler design have been providential. You misrepresent me, sir, in suggesting I question SoC in principle. What I question is merely its blind application (similar to "Design Paradigms"). Look again at the code sample Mr. O'Brien posted. The "control" there is four lines (which could be two) for getting the objects that are to be displayed. It's purely view code, and it makes no sense to try and derive a separate controller. I further posit that in Web interfacing, the concerns of control and presentation are tightly coupled by nature, and no design thus far has been able to pull them apart very effectively.


And you will stand on your experience. If you found pure servlets fragile and unmaintainable, well, stick to what you trust. I've found them to be the opposite. The example site, which was not done explicitly for the article, was very easy to write and to change, and it served its users without any problems whatsoever. Of course I was familiar with the library, but that says little after all.


I don't quite see your point about change-resistance. Servlets should not contain business logic, and I'm not sure how scrolling past those four lines in that example could be at issue. In fact it makes it clearer what data the view is presenting. Please qualify that "the complexity is magnified the more involved the requirements become". The *complexity* of selecting business objects for display should be kept out of the view layer altogether, so I don't see how that statement would apply any less to a UI framework. It seems to come down to the unfamiliarity of the syntax, which should not invalidate it by default. There's nothing "magic" about those constants, you know. I doubt you're pulling your beard over what "TD" and "END_TD" could possibly mean. Nor does the design hinge on those, but they do afford consistency and reduce typos, and I find them more readable than quoted literals. Any such API takes some getting used to, no more than dealing with dynamism in a templating interface. Where you argue that Java is bad at expressing static markup, I counter that it's good at expressing output logic and, more importantly, facilitating code reuse. That's why it's a servlet and not a JSP, in answer to your query. Show me a better, more concise means to reuse HTML output code than what I've demonstrated.


Reuse is the main idea. It's very explicitly *not* a framework. You may call the Servlet API a framework if you like (in the same way Java includes hundreds of "frameworks"), but to call my design a framework is to call every design a framework. It depends not on a servlet base class, but only on a simple library (which could be done better than I've done it).


"Why not just use JSP and scriptlets if you must mix markup and code?" Well, first, if by "code" you mean the output logic, that cannot be un-mixed. Conditions and iterations are ubiquitous in Web views, and every related Java technology supports that mixture. Second, as a developer, I find it even more obtuse trying to squeeze complex output logic into a declarative markup syntax (see the prickly table logic in the 'doBracket()' method in "Home.java", for example, and try to imagine what that would look like as a template). I agree it doesn't look like HTML, which is a disadvantage per se; but I don't think that overwhelms the advantages I've been trying to get across.


Of course my experiences with this sort of design or my own application of SoC doesn't invalidate anyone else's. I've written about this not as the "right way" to do things, not as a theory, but simply as a practical and effective means of getting things done, proven over several years and several projects. Sun has introduced JSP as "inside-out servlets". I think as Java developers, we have to be willing to invert our thinking back to a logical view syntax, long enough to understand its benefits, before we can damn it as outmoded. In this light, a normal servlet class that's focused on page output is as valid as a template, and the SoC applies to both the same.

John Zabroski
2007-04-10 16:10:09
@Michael Podrazik
@ There is a difference between presenting a revolutionary alternative after questioning the status quo and offering a past-rejected model as a solution to a misrepresented problem.


This is not an absolutism. For instance, functional languages have been around since the 60s but we are just starting to make use of them. The same goes for concepts which are inherently functional, like continuations pioneered by John C. Reynolds, which are being manifested under the guise of "passivation" in the Windows Workflow Foundation and other well-thought out Service Oriented Architectures.


The concept is this: How do we solve a problem we don't know how to solve? The answer to this enigmatic question is that we should turn back to what we already know. This includes the insane conclusion we should go back to concepts we casted away previously.


@ Jason Van Cleve
@ What I question is merely its blind application (similar to "Design Paradigms").


Are you suggesting my comments were blindly applied or that Petroski's book covers blind application? Petroski's book is about turning back to the past to solve present problems. That's it. It's not about blind application. It's the opposite. It shows us that we are usually not as blind and helpless as we think we are.


@ The "control" there is four lines (which could be two) for getting the objects that are to be displayed. It's purely view code, and it makes no sense to try and derive a separate controller. I further posit that in Web interfacing, the concerns of control and presentation are tightly coupled by nature, and no design thus far has been able to pull them apart very effectively.


Windows Presentation Foundation is probably the best concept I've seen so far with regards to Seperation of Concerns. I've said it before and I will say it again. All I care about is re-use of effort. WPF does the best job of this. Rails and WPF are not even comparable. I don't understand the interest folks have with comparing Rails with non-MVC concepts. Rails is a Web application framework. It's pretty good at what it does and most people who use it don't even understand the tricks involved. Every magician has an assistant. Rails is well-deployed code generation. What's WPF's? The run-time libraries! I said it earlier: The view is not a function of the data definition so it should not be generated at compile-time. Jason, your solution really doesn't address this need. Your making your view a static activation record. That's like programming user interfaces in FORTRAN. I think you'd get more credibility if you focused on how your data will be re-used. How does your approach make data a bigger asset than it already is in applications? Business leaders care about data. They don't care about pure servlets or any of this other stuff everyone here is discussing, including my menial points.


Additionally, Smalltalk programmers tend to wonder/joke about why Ruby on Rails copied the worst part of Smalltalk: MVC. MVC's biggest problem, which I alluded to in my rant above, is twofold: One is Allen Holub's rant about code-generated Views and maintenance. The other is that application logic and business logic get tightly coupled in the controller. Whatever good MVC buys you in getting off the ground fast, it doesn't help in maintenance. I want tools that help me finish projects faster. I want help in the last 20% of my schedule and I want help avoiding schedule slippage. I would love nothing more from my IDE than to give me that. Getting projects off the ground fast is supposed to be the job of the vision and scope, gathering the requirements, the project plan and the project schedule and the astute allocation of resources along that schedule. People who talk about Ruby on Rails being a great example of RAD miss the point behind separating Process & Structural Analyses. All application code is mortal and its going to die. All programs will meet their end. I tend to feel most RAD ideas are not realizing they are simply killing the application code faster. The eerie truth that "Each day in your life, you are one step closer to death" seems to apply well to RAD.


Microsoft is the one company who understands this better than any other company. Microsoft architects came up with the concept of the Model-View-Presenter. Now, I just want syntactic sugar on top of this and a smart way to build SOAs. (Wicket Groovy could be useful here).


I hope I don't sound like a Microsoft fanboy by any measure. I only bring up WPF and WFF because I believe they are the current best practices in software engineering. In truth, I am a Linux fanboy -- I am leaving right now to go to my Linux Users Group!


Note: Swing does not use an MVC framework. It uses a hybrid: Model + UI (View & Controller).

Jason Van Cleve
2007-04-10 23:30:33
Mr. Zabroski,


Regarding "Design Paradigms", I was referring to your remark on being honest about how well design patterns (and principles, I would add) solve the particular problems to which they're applied. I agree with that and with your views on MVC. As I mentioned in the article, developers using MVC frameworks too often implement business logic in their control modules, whose purpose in a Web application can be elusive.


But can you clarify your point on compiling the view? JSPs are compiled on-the-fly, and regular servlets can be hot-swapped with similar expedience; but this is a question of work flow, which I surmise isn't what you're talking about.

Federico
2007-04-11 06:26:09
Better to use Visual Basic Forms and Components design style, maybe composing portals with a page/portlet approach. Everything else seems to me just a poor way to waste time...
oldman
2007-04-11 07:22:36
You are a joke! Why did you bother to read it? And afterwards complain. To advocate this kind of solutions is kind done and sharing what one think can be useful for others. To call something a joke is the opposite. And why should anybody filter anything out. And the arguments against the 'joke' is by all means a joke. FreeMarker!! You must have bad dreams!
Kit
2007-04-11 08:29:43
I don't mind articles like this one appearing. Sure, I wouldn't do it this way, but from a out-of-the-box, brainstorming point of view, it has at least made many people think. Maybe one of those people will get some flash of inspiration and see a new path to improve on the well-worn MVC/templates path.


Life would be boring if everybody thought and acted just like me!


Kit