Andre Moo

+ Follow
since Sep 29, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Andre Moo

Actually Kyle,
I hate to disagree with you since you are the author of a book and I am merely a little nobody without a job and without any prospects who hasn't even written a single Servlet but........
Page 4,5,6, Chapter 1 Design Patterns, Gamma et al talk about none other than MVC!!! It finishes the albeit brief introduction to MVC by saying which design patterns are used by MVC i.e Observer,Composite and Strategy which obviously are catalogued in more detail later in the book.
Yes, it might not be the best source of info on MVC in the context of Web Applications but the book itself is indispensible with regards to the concept of design patterns amongst other things which is primarily why I recommended it to the original poster
Oh, and before I forget, Advanced JavaServer Pages by David M. Geary (ISBN 0-13-030704-1) is also a good book which covers a Web Application framework for JSP/Servlets, specifically MVC based which is not too dissimilar to Apache Struts - this is hardly surprising since David M. Geary is one of the contributors to the Struts project!
19 years ago
Yes Struts is good but is not the only MVC based application framework out there. It's still quite young and there are many improvements to be made to it.
You might like to have a look at Turbine too (, also part of the Jakarta project. The Turbine people like to say their framework is Model 2 + 1!!!
If you're genuinely interested in MVC as well as other design patterns then obviously you have to buy probably the most popular computer science book of all time "Design Patterns" by Gamma et al (ISBN 0-201-63361-2)
Other than that, if you ask Google nicely, she will tell you the answers to the universe.
19 years ago
Someone asked that question here a only few days ago!!!
Please look at my response and try to get a BASIC understanding of HTTP and how the whole thing works before you start doing JSP/Servlet programming!!!
Try and use the search functionality of this forum before asking questions next time. You'll be surprised at how many times your question has been asked/answered.
19 years ago
Go to and look for their book "Java and XSLT" to download code from the book. Of course its better if you also have the book so you know what the hell is going on.
I really like the book.
Try setting the encoding as UTF-16(!!!
You can use Struts as the application framework to make things a little easier for you if you want
Keep your eye on MyCart because they might actually get it done one day.
Or check out this article:
Plus you can have a look at the Java Pet Store from Sun (look up the URL your self!) which illustrates what they think are "best practices" for J2EE applications. However, this might be overkill for what you want since it uses EJB's which aren't really neccessary for small scale developments amongst other things.
And of course there is which will find you about a million other examples if you ask it nicely.
19 years ago
Yes, that is a workable solution. As long as you know where your container stores the translated JSP's this is a snap. Also, you obviously don't need to do this for all the JSP's just the ones with sensitive information or IP.
Another approach which would not work in your case unless you wanted to start all over again, is to write a custom tag that lets you "include" encrypted jsp's. You would obviously take a performance hit at runtime though. Next time.
Yet another approach is to make your JSP's "difficult" to read without alot of effort by making them un-abridged i.e remove white space so that the contents of the whole JSP basically ends up on one line! Its not pretty and I'm not sure if this would actually work with JSP's but it works with other things e.g Javascript files, HTML files etc. and I see no reason why it would work with JSP's. Also the file size becomes smaller but this doesn't matter with JSP's.
19 years ago
Incase you were wondering, the session is maintained for you by the container across pages - you don't need to worry about any of that!
19 years ago
HTTP Compression is a method of sending information to the browser which has been compressed with the gzip deflate algorithm.
You achieve this by chaining the response OutputStream with a GZIPOutputStream in your Servlets e.g
OutputStream out = response.getOutputStream();
writer = new PrintWriter(new GZIPOutputStream(out),false);
//set the header
//your normal servlet output goes here...e.g.
writer.println("Compressed Hello World!");
This only works with browsers that can accept the compressed information. To find out if the browser does you check Accept-Encoding to see if there is an entry for gzip by inspecting request.getHeader("Accept-Encoding");
You'll be UNHAPPY to know that not all browsers support this feature!!! Especially if you want to use this for the same company as your other post.
Early versions of Netscape on Win platform and IE on non-Win platforms generally don't support this apparently, but it doesn't matter, you just use an if statement in the Servlet and depending on whether they have an appropriate "Accept-Encoding", you use the GZipped Stream or not. Make Sense?
Using HTTP Compression only really helps with larger page sizes - you have to remember there is a price to pay in getting smaller page sizes - the time it takes to perform the compression at the server and the time it takes to decompress in the browser.
Okey doke, confused? Well, lets make things really simple. You can buy the book "Core Servlets and JavaServer Pages" by Marty Hall (ISBN can't-be-bothered-to-look) and look at Chapter 4.
Or if you are really cheap and lazy you can download an example from the website
(HINT:You're looking for Chapter 4
OKAY! OKAY! Here's a bloody direct link to the source code of the servlet in question:
Some people are so lazy!
No rest for the wicked.
19 years ago
One more quick thing...
In my oppinion, for robust code its best to implement both client-side and server-side form validation for redundancy. Bugs appear quicker and you can't always guarantee that the user will have client-side scripting available/enabled. In your case this decision has been made for you.
As the guys said above, Struts is a good bet although, it is about a lot more that just form validation.
If you prefer to read things on paper than on the web then you might like to buy "Advanced JavaServer Pages" by David M. Geary (ISBN 0-13-030704-1)
This book covers OO form validation and a full blown form framework. It also covers a whole host of other indispensible topics on web application frameworks etc. The author David M. Geary is one of the Committers on the Jakarta Struts project and unsurprisingly the techniques described in the book are strikingly similar to the implementation of Struts!!!
However, it has the advantage of letting you read about and understand just the bits you want - form validation - and ignore the rest of the framework.
On a side note. The CURRENT version of Struts is far from perfect, especially when it comes to client-side validation - but you don't need to worry about that. There are also other viable application frameworks out there.
On your tech question, Struts might lead you to take a slightly different approach.
19 years ago

Originally posted by Dev Cunningham:
With ASP, using VBScript, you can create a function for each snipet and 'call' that function where you want to include the HTML code. What's the equivalent practice for JSP?

Well, Ignore my last post if you want.
What's the equivalent practice for JSP? Well you can create a "method" for each snippet and "invocate" that method where you want to include the HTML code!!! Just as you do with ASP.
19 years ago
Yes, Struts looks nice but I don't think the Template architecture used in Struts is the answer to what Dev is asking. Its the solution to another problem. However, Struts does deal with Internationalization also which gives me another idea.
You could use Java's resource bundles in combination with a custom tag to achieve what you want. Although strictly speaking, resource bundles are meant for Internationalization and Localization it could be put to work for your means and into the bargain you could Internationalize your web application at the same time!
There are two types Resource bundles to my knowledge
1) List Resource Bundle which lets you store the key/values in a Java class and...
2) Property Resource Bundles which let you store the key/values in a text file e.g
snippets.copyright=copyright mr.moo 2001
You can store any text you want and that includes HTML so you could have:
snippets.welcomemessage=<font size="30">Welcome!</font>
snippets.copyright=<b>copyright mr.moo 2001</b>
in the properties file.
This has the advantage of storing all those "snippets" in one file in a central place. Alternatively, you could have several different files depending on categorization - thats up to you.
Then, in combination with your custom tag (which hides accessing the resource bundle etc.) in your JSP's it would look something like this
<%@ taglib uri='/WEB-INF/tlds/snippets.tld' prefix='snippets' %>
<snippets:include key='snippets.welcomemessage'>
<snippets:include key='snippets.copyright'>
Internationalization then becomes a SNAP! you just create different properties files for the different languages and make your custom tag access the right resource bundle depending on the Locale of the browser etc. BUT THATS GETTING OFF THE POINT!
On short reflection, Resource bundles might be overkill or not appropriate for what you want - its just an idea! It depends on what kind of "snippets" you are talking about. As said by someone above, you could implement it using a class which has all snippets you want defined in it as String literals and then use a custom tag as above to access them in JSP's
Anyway, I've only read a few books and haven't actually written a JSP or Servlet yet so its best to ignore everything I've just said!
19 years ago
Erm, yes this is not the right place to ask questions about Jetspeed. Hey, here's a ground breaking idea - why don't you check the Jetspeed mailing list archives!!!
Ashik - Erm...
Scriptlets - read about JSP's
Portlets - mini Portals!!!
19 years ago
Yes, this is not a Servlet issue.
There is no way of knowing whether the user has closed the browser window regardless of the server-side technology you use - jsp/servlets/asp/coldfusion/php/perl etc.
Hence the introduction of "sessions" in languages like asp/servlets/coldfusion to try and overcome this inherent limitation due to the nature of HTTP. It is up to the developer to set a sensible session "time-out".
Technically, however, there is a very poor and very un-elegant way of determining when the browser is closed which is highly un recommended - it is possible using client-side scripting e.g JavaScript or JScript, to detect when the browser window is closing and then do something - like open another window!(you may have experienced this on annoying sites with advert popup windows) When you open up the new window, you could point it to a url which then signals to the server that the user had closed the original browser window. Make sense? I don't recommend you implement this!
19 years ago
That sucks. Almost happened to me too but I stayed until they fixed it.
Anyway, you can see your score (not the breakdown) once the results are posted to My Certification at Galton. Though, that takes a few days from when you sat the exam.
19 years ago