Hunny Lee

Go to www.atg.com, click on the small "developer" link at the bottom right-hand corner. After you log-in (I am not sure of you can register if you're not an actual customer/client), you will see a menu on the left-hand side. Go to "Product Resources" -> "Product Manuals". Select your ATG version, and there you have it.

Their site/searh is soooo slow online. You should have a local copy on your box. Contact your marketing/technical contact from ATG and they should provide you with the documentation.

Good luck

Hi Larry,

I just read the HSFJ. I then took my sharpie, wrote some notes & samples per chapter on a big post-it and then posted it on my wall.

That way, every time I wake up, I get to notice one of the post-its and try to remember it by heart.

Worked out pretty well for me.

Good luck!

HFSJ is a good book. That's the only book I read for SCWCD 1.4. I read the book and wrote down some notes on a flash card. I got a pretty decent score on the exam (93%).

Good luck!

Thanks Richard. I hope you convince them to reevaluate.
Good luck!

${list.['listIdx'+1]}
Will fail to compile since you should use one or the other (dot or []), and not both at the same time.
If you remove the dot, i.e. ${list['listIdx'+1]}, it will still fail, since 'listIdx' is a String.
If you remove the quotes, i.e. ${list[listIdx+1]} -> this will be evaluated to ${list[2]}, then the output is "c"

${list[list['list']]}
'list' (the 3rd) is String, so it will fail since you can't retrieve values from a list using a String that cannot be converted into an integer. (e.g. '1')
If you remove the quotes in the 3rd 'list', i.e. ${list[list[list]]}, it would still fail since list is an ArrayList, and can't be converted to an integer.

As most of he replies have pointed out, read HFSJ. It's a really good book especially for beginners.
You may find that this is not the book for you if you are experienced on servlets and JSPs though, like when you want a quick answer if you forgot something. For that purpose, you have the Servlets and the JSP Specs.

Originally posted by praveen sainath:

...
ServletContext context = ContextStorage.getContext("/contextUrl");
...

I do not know any ContextStorage in the servlet API. I'm interested, where did your friend get that?

You cannot use request.getRequestDispatcher to access a URL outside of the current servlet context.

You may use response.sendRedirect(url) to redirect to any page you like, if you don't mind that you lose your current request data.

The answer is actually #1.
<jsp:useBean id="mystring" class="java.lang.String" />

-this looks for a "mystring" attribute on page scope, which should be of type String. If it does not exist, the container will create it.
At this point, mystring is "".


<jsp:setProperty name="mystring" property="*" />

-this tries to set the properties of String, if the properties exist. The container iterates over the request parameters, and looks for anything that matches the bean's property names. Since String doesn't have properties anyway, nothing happens.

<%=mystring%>
-so this prints an empty String.


Line 2 would throw an exception, something like:
"Can't find information on property 'notARealProperty' in bean 'java.lang.String'" only if you specify the property,

e.g.<jsp:setProperty name="mystring" property="notARealProperty" />

Originally posted by M Burke:
...
<c:choose> <c:when test="requestScope.formEvent ==applicationScope.DServiceGlobalForms.FORM_EVENT_PROFILE" > <jsp:include page="${applicationScope.DServiceGlobalForms.FORM_TYPE_MAIN_USER_PROFILE}"/> </c:when> <c:otherwise> </c:otherwise> </c:choose>

Try adding ${} to your test (on c:when). That should work, assuming that formEvent and DServiceGlobalForms are set correctly.

Originally posted by Vinod Iyer:
Correct me if i am wrong.

When user servlet does not set character encoding then

a . servlet uses default encoding ( ISO-8859-1 )
b. servlets do not set the character encoding to ISO-8859-1 , its still null both a & b are correct , right ??

some one please confirm this

The default encoding of a request and response is "ISO-8859-1" if it was not set by the client request and the servlet programmer, respectively.

However, in the request, getCharacterEncoding() returns null if the encoding was not set by the client request.
and in the response, getCharacterEncoding() will return "ISO-8859-1" if this was not set.

So I'd say that A is correct if you replace "servlet" with request and response, and
B is correct only if you replace "sservlet" with request.

list['listIdx'] will throw an exception since 'listIdx' is a String, and not an integer used to retrieve the values in the list [i.e. get(int index)]

I checked the errata of HFSJ at http://www.oreilly.com/catalog/headservletsjsp/errata/headservletsjsp.confirmed and it looks like the correct option was
${list[list[listIdx]]}
[ February 21, 2007: Message edited by: Hunny Lee ]

Originally posted by Sahul Yasin:
What will be the values of the below expressions:
1.${person.name}
2.${person[name]}
3.${person["name"]}

[/QB]

1 - Arnold
2 - Throws an Exception. Something like "Unable to find a value for 'TomCruise' in class Person". This is because "name" is evaluated first. So the EL would be something like ${person["TomCruise"]} afterwards. Since TomCruise does not exist as a property, this will throw an exception.
(Note: Even if you had getTomCruise() in your Person bean, this would still not work, since the "name" attribute has a capital T in "TomCruise". To make it work, set the attribute as "tomCruise" [lowercase t]. It will then print out whatever getTomCruise() returns)
3 - Arnold


I hope that helps.

great work!

cheers!

Originally posted by Ghazala Islam:


HTTP STATUS 405:HTTP method GET is not supported by this URL.
The specified HTTP method is not allowed for the requested resource.

Most probably you did not implement the doGet() method.
Try doing that first and tell us how it goes.

Originally posted by Bear Bibeault:
A great argument for moving to Model 2! :thumb:

Yes, we are!
It will take months and months to refactor the code (+PM, +QA, etc). (I'm fairly new to this company, and I tell you, their legacy system is bad!)
Therefore, the need to 'hide' the JSPs on the old system while that one's still running.