|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 53
Messages: 53
Messages: 53
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Pure servlets: Designing Web UIs for Simplicity
JSP was designed to keep Web developers' tasks separate from those of the nondevelopers who design dynamic webpage UIs. Unfortunately, JSP is a bit too complicated for many designers. This article demonstrates the advantages of an unorthodox alternative: using simple helper objects to build a Web interface based on servlets alone. This is an invitation to think outside the framework, if you will, and imagine a Web interface built directly on the Java Servlet API.This article has been an invitation to think outside the framework, if you will, and imagine a Web interface built directly on the Java Servlet API. The astonishing number of frameworks and templating systems available to Java Web developers makes them seem indispensable, yet they're often astonishingly complex and hard to use. While thinking about which one best suits a particular type of Web application, you might also consider what could be accomplished with built-in language features such as extension and encapsulation. As Bruce Tate puts it, "it's usually better to solve problems with simplicity and finesse rather than muscle."
The muscle of Web frameworks has its place, and JSP/templates are great when projects include designated HTML designers who can produce and maintain them. But for some projects, the simplicity of pure servlets is a valid alternative with its own peculiar advantages. It offers control and flexibility, and it doesn't require you to pack all your dynamic content into request objects. You can unit-test pure servlets without performing any gruesome contortions. And reusing HTML output is as simple as adding or overriding a method. Does anyone remember htmlKona (deprecated by BEA in WebLogic 6.1), or the Element Construction Set from Apache?
Message was edited by: joeo@enigmastation.com
|
|
|
Message #230099
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
it is only feasible with no dhtml or ajax features. otherwise..
This only seems to work with only server side generated pages only. but if dhtml, ajax come into play it would be unthinkable to take this approach.
|
|
|
Message #230103
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
JSP was designed to keep Web developers' tasks separate from those of the nondevelopers who design dynamic webpage UIs. Unfortunately, JSP is a bit too complicated for many designers.
Plain JSP is indeed too complicated for some designers. Fortunately, when combined with JavaServer Faces, JSPs can now be designed by Web authors in a visual, drag-and-drop manner.
The "programmatic UI" approach will not gain adoption in the UI design community for one simple reason: most designers are visual by nature.
Ian
--
JavaServer Faces for Dreamweaver
http://www.jsftoolbox.com
|
|
|
Message #230108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
Plain JSP is indeed too complicated for some designers. Fortunately, when combined with JavaServer Faces, JSPs can now be designed by Web authors in a visual, drag-and-drop manner.
Have You ever seen, proffesional web designer using visual, drag-n-drop tools?!? Me never.
Artur
|
|
|
Message #230110
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
You had me at "Rethink the view"
OK... A bit long winded. In fact, I couldn't get through it all.
I have recently been having a similar discussion with my colleagues. I'm not sure that any of us would go so far as to revert back to only using pure servlets though.
The problem is that collectively, the Java community has gotten obsessed with making our jobs easy. Tools are supposed to simplify one's work. If you need to put firewood away for the winter, you could do it with a pocket knife, or you could do it with a chainsaw. Obviously, the chainsaw is the right tool for the job. But if you are looking to harvest some wild flowers to bring to your mother on Sunday afternoon, don't fire up the chainsaw. I don't know how many projects I've worked on now where the powers that be have instructed us to pull out the chainsaw to gather flowers!
There are some tasks, like the authors example sports page where a simple servlet approach is the right answer. My hat goes off to the author for reminding us that we don't always HAVE to use the (insert flavour of the month) toolkit to do every job.
Love your work? KISS it!
|
|
|
Message #230116
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Professional Web designers
Have You ever seen, proffesional web designer using visual, drag-n-drop tools?!? Me never.
Hi Artur,
I do it all the time, and so do my customers.
Our product, JSFToolbox for Dreamweaver, is designed to support just this workflow.
Ian
--
JavaServer Faces for Dreamweaver
http://www.jsftoolbox.com
|
|
|
Message #230117
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This entry isn't even worth posting.
I won't make an effort to bash the author, since he makes his own life a living hell. If we were going back nine years ago, I’d say "Hey, this isn’t a bad idea.", but since god gave us Wicket, Tapestry and other solutions that are cleaner, I'm going to say "This entry sucks."
I see absolutely no benefit in this idea, besides it's an excellent way to say "I hate my job and everyone I work with." Please restrain yourself from posting such hogwash.
Best regards,
Richard L. Burton III
|
|
|
Message #230119
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What's the difference between this with Echo?
I think the Echo has done a great job to implement server-side design to generate web UI automatically. Could anybody tell me what is the different of them?
|
|
|
Message #230122
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Hmm..umm..no
March Madness indeed, this is indeed madness.
Frankly, with JSP 2.0 introduction of Tag Files, plain 'ol JSP has more than enough power to let people with few skills abstract and make their pages easier to author.
The example provided with the simple security wrapper and creation of the URL is a perfect example. If this is a common occurence in their application, it takes almost no time at all to create a "hasPermission" tag and a JSP URL aware anchor tag.
And once you have that, you're on your merry way pounding out HTML and a handfull of JSP tags to finish off your site, without using toolkits to use methods to generate your HTML in a spectacularly "unnatural" way.
It's fast and easy.
If you want to forego a framework for your action servlets, then fine, be my guest. Inevitably you'll end up writing some library to handle the binding, validation, and data conversion if nothing else, but if that's what you're comfortable with rock-n-roll.
But any excuses to bring HTML into your application are getting fewer and farther apart.
Things like the component frameworks are different, as they're more than simply rendering HTML.
|
|
|
Message #230125
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
I don't see the point. Sure, you don't have to buy into the latest craze and you can pick the tools that make sense for your particular environment but this as a general approach is just... bad.
This approach will not help people split their team work better, it won't facilitate 'designers' and it *will* encourage spaghetti code. I don't know, maybe this should have been posted a couple of days later :)
|
|
|
Message #230130
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
why not go back to CGI ?
If you have some big memory ( memory is really cheap these days and so are servers) CGI is good too. Why need servlets ?
I cant believe we are posting this article here.
So now your servlet is V and a C too.
Why not put member variables in servlet, use single threaded model and hey your servlet can be all - MVC.
What a post on TSS.
|
|
|
Message #230133
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
I was using pure servlets back in 1998 and guess what - I started adding flexibility by using a generic base class called 'Page' and then extending that to make specialized page classes.
Pretty soon I was adding all kinds of weird and wonderful constructs and implementing really cool patterns. Was it still a 'pure servlet' approach anymore? No, it was starting to look more like a framework and that is what eventually happens with any pure servlet approach when a proficient programmer is working on it - the logical extension of this is that pretty soon you will end up with your very own framework with its own peculiar learning curve and you'll be commiting a certain amount of your company's resources to maintaining a framework that noone else in the world may ever use.
While this might be 'cool' I say "Let it go man". Don't reinvent the wheel. There is now an incredible range of mature Java UI frameworks out there with communities behind them.
A while ago I spent a lot of time analysing the most well known UI frameworks out there and we decided on a combination of Echo2 for AJAX intensive stuff and Wicket for classical markup based pages.
I feel these both 'rock massively' and have very elegant component based models. In both cases a component based architecture was envisioned on day one and not retrofitted to a traditional framework in an attempt to get the 'Component based architecture' tick on the side of the box.
|
|
|
Message #230135
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Bah! We don't need any of these fancy tools!
Back in my day we didn't need Tapestry, or Wicket or WebObjects, or even Servlets, or for that matter Java! We just coded in plain assembly language. And before that we had to just type in 1's and 0's. Sometimes we didn't even have 1's. I once had to code for an entire month, barefoot, in the dead of winter, using just 0's. I you didn't hear me complaining.
|
|
|
Message #230138
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Bah! We don't need any of these fancy tools!
Back in my day we didn't need Tapestry, or Wicket or WebObjects, or even Servlets, or for that matter Java! We just coded in plain assembly language. And before that we had to just type in 1's and 0's. Sometimes we didn't even have 1's. I once had to code for an entire month, barefoot, in the dead of winter, using just 0's. I you didn't hear me complaining.
But now you spoiled by civilization ;)
|
|
|
Message #230143
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
nothing wrong with wheel reinvention, however...
...I do put a tighter leash on what I describe as 'rock massively'. :)
I think people should reinvent wheels on a whim, but I feel that working with raw servlets is not it. It's like saying "I don't like these chrome wheels with diamond encrusted spinners on them... I think I'll try making some more from a block of stone with a hatchet"
I'm typically in the "yay, more wheel invention means we may get a cooler thing in the long run"... but I feel this isn't it.
|
|
|
Message #230152
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: why not go back to CGI ?
If you have some big memory ( memory is really cheap these days and so are servers) CGI is good too.
FastCGI is even faster
Why need servlets ?
None of the PHP developers needs servlets.
I cant believe we are posting this article here.
'Design for simplicity' is really unbelievable on TSS.
|
|
|
Message #230153
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSP and Web Designers
Just to point that in my previous job we had the web designers develop the storyboards (html pages) of what the interface should look like. They did not have to deal with JSPs and so they concentrated on developing the look and feel. After they were done and the business approved of what they saw, we took the html pages and added the dynamic functionality.
Why does it have to be that web designers deal with the JSP pages why can't we just get the final html product and add the necessary functionality later?
Once again it isn't always the technology's fault but rather our development processes. We really should take a good look at how we develop web applications and say "is this the right approach?"
|
|
|
Message #230155
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSP and Web Designers
Just to point that in my previous job we had the web designers develop the storyboards (html pages) of what the interface should look like. They did not have to deal with JSPs and so they concentrated on developing the look and feel. After they were done and the business approved of what they saw, we took the html pages and added the dynamic functionality.
Why does it have to be that web designers deal with the JSP pages why can't we just get the final html product and add the necessary functionality later?
Once again it isn't always the technology's fault but rather our development processes. We really should take a good look at how we develop web applications and say "is this the right approach?"
In my experience an html page is never done and always buggy so unless you adhere to a very strict waterfall process, you will always have to synchronize two different types of web resources the html pages and the jsp pages. And just because of that it's a no go for most peoople : two copies of the same things is always a nightmare in maintenance. Therefore, I believe tat web designers have to work on the real pages and not on some sort of prototypes (well except in the early inception of the project of course).
|
|
|
Message #230156
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
I was using pure servlets back in 1998 and guess what - I started adding flexibility by using a generic base class called 'Page' and then extending that to make specialized page classes.
Pretty soon I was adding all kinds of weird and wonderful constructs and implementing really cool patterns. Was it still a 'pure servlet' approach anymore? No, it was starting to look more like a framework and that is what eventually happens with any pure servlet approach when a proficient programmer is working on it - the logical extension of this is that pretty soon you will end up with your very own framework with its own peculiar learning curve and you'll be commiting a certain amount of your company's resources to maintaining a framework that noone else in the world may ever use.
While this might be 'cool' I say "Let it go man". Don't reinvent the wheel. There is now an incredible range of mature Java UI frameworks out there with communities behind them.
Exactly. I am developing using a pure based servlet approach here at the moment (not my choice) and this is exactly what is happening.
|
|
|
Message #230157
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
I can only weep for TSS. I claim this day the 'Java Community Mourning Day'.
|
|
|
Message #230159
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
The HTML output methods result in servlet code that is straightforward and compact -- hence highly maintainable, given that code-maintenance costs are more or less directly proportional to code size. By rewriting JSP interfaces as pure servlets, I've been able to reduce the code by two thirds.
I can't believe some people will buy this kind of stuff.
|
|
|
Message #230160
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Good anti-pattern example ?
As far as I know desgin patterns, the main goal of the MVC pattern is to decouple presentation aspects of the application from the model and business logic. Putting all these presentation aspects in the servlet seems to be a very good example of anti-pattern, IMHO. It hardly ties the UI to the model and business logic so that you have to deeply change your Java code each time you change the UI. It also makes impossible the separation of the Java developer work and the web designer work. Strange idea from an IBM article...
|
|
|
Message #230161
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
On a side note, I think the author has some good points but make some very bad conclusions
Contrary to the author I actually think that most MCV action based frameworks are not enough abstract and too close to the http request/response cycle.
For instance, they don't explicity separate and make it easy to actually mix together the input controller (the event handlers) and the application controller (the application flow controller but not as the C in MVC) together.
Also as the author, I am not a big fan of templating languages the way they are used at the moment. People put out way too much logic in there to handle user actions and the page become complety bloated to handle different possible cases. But I believe this is mainly due to frameworks lacking a component abstractions not the other way around. Manipuling directly rendering code instead of component is cumbersome and mix too much responsabilities at the same place (event handling and rendering logic for one). For instance, in a rich client application, would you call the OS rendering API directly or would you using Swing components? Tapestry/JSF/Wicket/... allow you change the component properties in a event handler in reactions to user actions where it really belongs and I think this is the way to go. I strongly believe general and powerful template languages should be used at the component level and not anywhere else as in Struts or any other MVC action based frameworks. Other than that stick to a Html templating language like Facelets.
Just my two cents.
|
|
|
Message #230176
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wow
So one guy gets frustrated with the complication of all the web frameworks out there are creates Ruby on Rails. Another guy reverts to 1997.
Hmmm.
|
|
|
Message #230178
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wow
So one guy gets frustrated with the complication of all the web frameworks out there are creates Ruby on Rails. Another guy reverts to 1997.
Hmmm.
So what, the entire web programming model with input->request->input was something where someone reverted to 1972 programming models in 1992 :-)
unfortunately, it took over. The next kludge we currently have to deal with is ajax, broken by design pushed into the market by marketing millions.
So now we have a guy which goes back to a broken design of 1997 because he does not want to deal with broken designs which try to fix a broken design which was introduced as something totally different in 1992. Somehow I have the eery feeling this guy will not succeed as ajax did, he needs more marketing millions.
Sorry for being so sarcastic, it has been a long day.
|
|
|
Message #230180
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
Excellent Article and a good reality check. One size never fits all, and the myriad of frameworks and approaches touted religiously in this forum prove that. It's definitely healthy to stop and rethink the value a particular approach brings to your projects. Sometimes folks get caught up in absolute truths such as ‘the world is flat’, or ‘the universe spins around the earth’, that when someone says ‘the world may be round’ or ‘the earth actually might spin around the sun’ their whole belief system gets challenged and they react accordingly. It is an unfortunate over reaction, especially in this case. The author here is not challenging the value of frameworks. He is challenging the absolute truth ‘frameworks are always good and are always the correct approach’. He is right to make the challenge. In our industry there is no such thing as an absolute truth.
|
|
|
Message #230189
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
Excellent Article and a good reality check. One size never fits all, and the myriad of frameworks and approaches touted religiously in this forum prove that. It's definitely healthy to stop and rethink the value a particular approach brings to your projects. Sometimes folks get caught up in absolute truths such as ‘the world is flat’, or ‘the universe spins around the earth’, that when someone says ‘the world may be round’ or ‘the earth actually might spin around the sun’ their whole belief system gets challenged and they react accordingly. It is an unfortunate over reaction, especially in this case. The author here is not challenging the value of frameworks. He is challenging the absolute truth ‘frameworks are always good and are always the correct approach’. He is right to make the challenge. In our industry there is no such thing as an absolute truth.
Right. But what does the author do? Propose *another* half baked framework! What do you think you end up with if you follow his approach? Something very simple whereas by using framework X it would be something very complex? No, reactions on this thread have nothing to do with people thinking you should employ 'big fat' frameworks and you can't go back to the bare basics. They have to do with the his proposal being a recipe for disaster.
|
|
|
Message #230214
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: What's the difference between this with Echo?
+10
Echo is really very nice.
+100 :)
But Echo (and Echo2) doesn't have any relation with the article : Echo is much like a Swing for developing web applications. The developer doesn't have to think UI in terms of HTML pages or to directly deal with HTML tags Java code.
|
|
|
Message #230220
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Shoot me now
The problem here is we're thinking in Java ... we could be thinking in Flex ;-)
|
|
|
Message #230241
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Leave the egos at the door, quick and clean please
So one guy gets frustrated with the complication of all the web frameworks out there are creates Ruby on Rails. Another guy reverts to 1997.
And why shouldn't he get frustrated with complicated frameworks. I for one believe that all these 'frameworks' are a result of egotistical engineers who are more interested in outdoing the latest framework and trying to convert the world to their way of thinking on a certain idea of how to implement a solution. Old school development techniques, such as plain HTML from graphic designers, converted into simple JSP with display tags only for dynamic data and then a good model design (POJO) and a light persistence framework will do the trick for the 'majority' of what is out there on the web.
This Java lark is all about keeping up with the Jone's, thats all. Oneupmanship and nothing else.
And before I get flamed, yes 'some' applications need these frameworks, but in most cases a project is not seen as valuable to sell predominantly if it doesn't have some heavy-weight framework behind it in order to justify the huge development costs charged to clients!
|
|
|
Message #230272
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Leave the egos at the door, quick and clean please
So one guy gets frustrated with the complication of all the web frameworks out there are creates Ruby on Rails. Another guy reverts to 1997.
And why shouldn't he get frustrated with complicated frameworks. I for one believe that all these 'frameworks' are a result of egotistical engineers who are more interested in outdoing the latest framework and trying to convert the world to their way of thinking on a certain idea of how to implement a solution.
Always this ego argument... where do you base that on? I know where my involvement and that of my team members come from, and it has nothing to do with inflated egos.
Old school development techniques, such as plain HTML from graphic designers, converted into simple JSP with display tags only for dynamic data and then a good model design (POJO) and a light persistence framework will do the trick for the 'majority' of what is out there on the web.
You can come far with that, but it really depends on the complexity of your user interface etc. If you have followed this approach and you didn't run into problems, well good for you, maybe *you* don't need a framework after all!
This Java lark is all about keeping up with the Jone's, thats all. Oneupmanship and nothing else.
And before I get flamed, yes 'some' applications need these frameworks, but in most cases a project is not seen as valuable to sell predominantly if it doesn't have some heavy-weight framework behind it in order to justify the huge development costs charged to clients!
What a load of pessimistic BS. Maybe you have a particular framework in mind? What exactly do you define as being 'heavy weight'? Do you truly believe *all* frameworks out there are heavy weight? And if you do this 'light weight' thing - I've been there - are you saying you *don't* end up writing a million hacks and custom 'frameworky' code? You will end up with something that's just as hard or harder to maintain as when you used one of the frameworks that after all were started to provide solutions to common problems?
Of course, everything stands or falls by choosing the framework that fits your needs/ solves your problems. And that's the main problem with the original article and remarks like these: it makes no distinction. All frameworks are heavy weight without merrits and they were incepted because of the author's inflated egos. It like saying all program languages suck because you have programmed in Pascal and didn't find it helpful.
|
|
|
Message #230279
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Different tools are for different requirements
I agree with the author that the existing Java Web frameworks are way too complicated.
And we (developers) must do something about it.
However, I don’t agree that falling back to pure Servlet will solve the problem of Web developments.
JSP pages are for views, and Servlets are for controllers.
Of course, you can use all JSPs for both views and controllers; however, in this case, you will have data access code and logic code embedded in the pages.
Or you can use all Servlets for both views and controllers, but in this case, you have to hard code all the HTML and Style generations in to Java code.
Both are not good.
So if you develop simple-enough apps, you can always use Servlets for controllers and JSPs for views, ad they are really good, if you can define a consistent way to communicate between different pages and servlets, and a consistent way to maintain conversation states between different requests.
Many developers blame that JSP/Servlet are not good enough, but they don’t recognize that it is because they are too generic, so you have to form the communication and state maintenance very well, or else …
And most of the developers don’t have enough experience and design knowledge to do just that.
But if you are building a real large application that needs a lot of well-defined services, frameworks such as Struts, Webwork, Tapestry … and the newest of all, JSF, will help you fare better.
Not only they have a lot of built-in features for Web development, but they are also maintained by a dedicated community. So you don’t have to spend your time on infrastructure code, and you can spend more time on the business at hand.
But those frameworks require quite a learning curve for sure.
So, make your choice based on the business requirements. Don’t make your choice because the tool is easy or difficult to use. Difficult problems (sometimes) require difficult tools.
If you have a simple enough problem, for example some Web pages to baby-sit a simple database, and you choose a complex framework – and God save us – EJBs as well => It only means that you are stupid and should not touch any computer in the first place.
Likewise if you use only Servlets to develop a Web-based Enterprise Application.
|
|
|
Message #230306
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Frameworks complicated?
I agree with the author that the existing Java Web frameworks are way too complicated.
Define complicated. I believe there are a variety of reaons why a person might deem a framework to be 'complicated'. Some of them are quite valid:
1. This framework has a learning curve and I'd rather write my own than go to the trouble of learning how to use someone else's framework.
If there are good frameworks around that do what you want and are supported by active communities then this definition of complicated is really just the result of a closed mind or a misguided sense that your employer wants you to write frameworks instead of applications.
Most people don't mind putting up with a short term learning curve because they believe that they can leverage that small investment and make huge productivity gains in the future.
It doesn't take more than a day or two before you can tell whether a particular framework is going to pay off. Some will and some won't. I'm all for light weight, concise well focussed frameworks that are a great fit for a particular need but I have heard of certain "framework junkies" who go after a new framework just because it's cool or seems to be flavor of the month.
A slap in the face to the attitude of framework junkies maybe what the article's author has actually (perhaps unintentionally) achieved here rather than taking us all back to the dark ages or pure servlet coding.
2. This framework doesn't seem to be implemented or designed very elegantly. It feels too cumbersome and inefficient to use for the payback that it brings me.
Sometimes frameworks are just complicated because they're crap. Be sure you understand that the level of success of a framework can sometimes have little to do with it's level of quality or ease of use. Just like marketing in the commercial world, marketing and penetration of open source frameworks is affected by euphoria, FUD, and 'buzz' and so success doesn't necessarily indicate quality.
Take a look around for a better framework and only if you can't find a better one should you write your own. Frustration with a current framework is the mother of all framework inventions but first make sure you're just not suffering from number 1 above.
3. This framework includes everything, including the kitchen sink but all I wanted was a can opener. A large framework often has many jar dependencies, has a higher memory footprint and can introduce new configuration requirements such as extra XML files to worry about.
Spring appears to be a quality product and seems to be used by a lot of developers for a variety of functions but when we came across it all we needed was a way to do dependency injection. We found it hard to 'purchase' the whole kitchen when all we needed was a can opener (dependency injection).
We were already using our, at that time, in house, lightweight exPOJO framework to implement an 'exposed domain model' architecture and provide a wrapper over Hibernate/JDO to provide ORM independence (I'm pretty sure we weren't suffering from #1 above as there were (still are?) no other ligthweight frameworks satisfying these requirements). Adding dependency injection to that merely involved adding a couple of lines of Java code to attach and detach the ModelExposer to/from the current thread.
I'm sure Spring performs a huge range of different functions that many web app developer's might need but in our particular case we only needed one of them so we couldn't warrant the extra jar dependencies, memory footprint, learning curve and an extra XML to configure when all we needed to do was add a couple of lines of Java code to our app instead.
And we (developers) must do something about it.
What do you suggest?
|
|
|
Message #230322
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Pure servlets: Designing Web UIs for Simplicity
Don't read this and do not suggest this article to anyone.
|
|
|
Message #230327
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: jyog dot com Spam
You really are a very annoying person. Stop abusing this forum. I see that no one is bothering with yours.
|
|
|
Message #230328
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Disaster
No way am I going back to pure-servlet approach. hell there must be some reason why people "invented" Struts, Spring, JSF, etc. etc.
|
|
|
Message #230335
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: wow
You got a point there. Things are going back and forth. One day there's fat client, then request-response, then fat client, then client-server, then fat client..
Every time that switch happens, there are some people blindly believing that the "new" thing is superior to all other solutions. I think those people are simply too lazy or too stupid to understand the different benefits and drawbacks of different solutions.
I just go with the masses, because any other road just seems to lead to frustration. After all, unless you're one with big money or one with your own successful application framework, you basically cannot make any change. Just do your own cool stuff and let the world make their own choices. And remember, there are always people, who will think that Your choice is the stupid one ;)
|
|
|
Message #230344
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSP and Web Designers
Just to point that in my previous job we had the web designers develop the storyboards (html pages) of what the interface should look like. They did not have to deal with JSPs and so they concentrated on developing the look and feel. After they were done and the business approved of what they saw, we took the html pages and added the dynamic functionality.
Why does it have to be that web designers deal with the JSP pages why can't we just get the final html product and add the necessary functionality later?
Because, with just a little bit more experience, you will understand that NOTHING on this earth is written once and then just used. Those pages _will_ have to be revisite both by designers and programmers. Once code and design is merged it will be very hard to change anything.
But, don't worry, you don't need to know any of that. Nowdays, it's much more fashionable to chat pointlessly on "forums" like TSS, than to listen, do and learn, which used to be the mantra of understanding before. Seems like - not anymore.
|
|
|
Message #230353
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ego Part Deux
Always this ego argument... where do you base that on? I know where my involvement and that of my team members come from, and it has nothing to do with inflated egos.
Well maybe I have been unlucky in the companies where I have worked but there was always at least one guy that thought he had it all figured out, and varying levels of smugness was shown when anyone dared disagree, question his idea/design/code. You would usually find that this guy is the owner of hugely over-engineered code, that only succeeds in 'stretching his development muscles'. And heaven forbid if you had two or more of these types, all you get then is a stand-off in the middle of the office. That says ego to me.
This can be an issue in any industry, so why is software development any different.
But the main point I was trying to get across is that, we as developers/architects whatever will always have the urge to do things 'our own way', that comes from the creative side of what we do, it's just that need is put before the good of the project that the problems arise.
|
|
|
Message #230359
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
condescending
But, don't worry, you don't need to know any of that. Nowdays, it's much more fashionable to chat pointlessly on "forums" like TSS, than to listen, do and learn, which used to be the mantra of understanding before. Seems like - not anymore.
Eh, bit condescending I think, with regard to listen, do and learn, who should we be learning from, the resident ego who know it all?
|
|
|
Message #230374
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: This entry isn't even worth posting.
...but since god gave us Wicket, Tapestry and other solutions...
So God is a developer now?
|
|
|
Message #230376
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSP and Web Designers
I have to disagree. The web designer should be free to design using the tools that are best for his job. It can be as simple as a whiteboard or even him telling you to left justify a set of labels. If you expect him to know CSS, javascript, html, Java, JSP, and whatever framework you use, you call that guy a developer. I've always had the designer do a mockup and we then translate it with code. (like all models, right?) I've never had a problem modifying my JSP/HTML/CSS code (like all code, right?) through countless iterations. I've found it's only a "nightmare" if your code is a mess.
|
|
|
Message #230379
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSP and Web Designers
I have to disagree. The web designer should be free to design using the tools that are best for his job. It can be as simple as a whiteboard or even him telling you to left justify a set of labels. If you expect him to know CSS, javascript, html, Java, JSP, and whatever framework you use, you call that guy a developer. I've always had the designer do a mockup and we then translate it with code. (like all models, right?) I've never had a problem modifying my JSP/HTML/CSS code (like all code, right?) through countless iterations. I've found it's only a "nightmare" if your code is a mess.
Depends of the type of application you're writting I guess. I used to work in a governemental organization where every web site had to respect a very strict business image, support firefox, internet explorer and sometimes even opera (each one interpreting css and html very differently) and a very high level of accessibility (we had to test the application using a vocal reader). All of this was the responsability of the web designer and I was glad it was!!! I had enough to deal with in Java and had no time to understand all the trickiness of IE. Actually, I hate when the designer only do a mock up (especially if it isn't even in html, good luck reproducing all of this afterward) and you're on your own for the rest of the development. But fortunately because of the html/css separation isn't as much of a problem as it once was.
|
|
|
Message #230381
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JSP and Web Designers
I've always had the designer do a mockup and we then translate it with code. (like all models, right?)
I forgot to mention that I'm a big fan of DDD so I believe in having only one single model and no translation phase so I disagree with this statement.
|
|
|
Message #230407
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ego Part Deux
Always this ego argument... where do you base that on? I know where my involvement and that of my team members come from, and it has nothing to do with inflated egos.
Well maybe I have been unlucky in the companies where I have worked but there was always at least one guy that thought he had it all figured out, and varying levels of smugness was shown when anyone dared disagree, question his idea/design/code. You would usually find that this guy is the owner of hugely over-engineered code, that only succeeds in 'stretching his development muscles'.
Yeah, I definitively agree that there are many of such people around (in any industry really). I just don't think that this is something that applies for all frameworks ever written. I'm also quite sure there are situations where people are bullied out of using framework X because the senior guy on the block (who just wrote a fancy article?) got it all figured out that all frameworks are evil ;)
|
|
|
Message #230413
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: condescending
But, don't worry, you don't need to know any of that. Nowdays, it's much more fashionable to chat pointlessly on "forums" like TSS, than to listen, do and learn, which used to be the mantra of understanding before. Seems like - not anymore.
Eh, bit condescending I think, with regard to listen, do and learn, who should we be learning from, the resident ego who know it all?
Dude, you are kidding, right? You must be. You can't publicly declare there is nobody to learn from and still have the nerve to blame somebody else in having ego? hehe
I find it very funny that obvious mantra of "listen, do, learn" has apparently become alienated for certain people :) Ok, then....
|
|
|
Message #230745
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSP, JSF, Tapestry, and so forth - all a mess
This quote from the article is right on -
"Working with JSP and other view technologies can be the most treacherous aspect of Web development. JSP pages aren't HTML or XML, Java code, JavaServer Pages Standard Tag Library (JSTL) code, or expression language (EL), but a confused hodgepodge of all those and more. Not only is this a grotesque amalgamation, but each layer of abstraction creates new obstacles to development."
I tend to say it is Byzantine, but "grotesque" is good too! That is the problem. The Java community has created a monster (several actually) that relegates Java web page development to an esoteric specialty requiring a huge up front learning curve investment. At the very least you need a whole group of designers who can translate designs from HTML/CSS to JSP. JSF is way worse unless you want to be dependent on drag and drop tools that put you into a design straight jacket. Frameworks like Tapestry with really geeky object models are not even on the radar if you look at skills that companies are hiring for.
For a similar viewpoint see -
http://www.jotobjects.com/JOTlinksaboutjsp.html
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, 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)
|
|
