Re: Problem displaying data on a jsp (from a database) using logic:presenttag
Saturday, February 4, 2006 10:10 PM
works fine. if you really do have a bean in request or session or application scope under the exact specified attribute name "formname", and if it really does have a "getFieldname" method (with "f" replaced by "F"), and if that method really returns a non-null object, then the logic:present should fire, and the contents of it should get executed.
(note that I don't think a form-bean, declared by name "formbean" in struts-config, will actually be found in request or session scope under attribute name "formbean" !..... I could be wrong about this?
Recently I found that you can use the little-known "html:struts" tag, to get the actual attribute name under which your form bean is actually set, so you can feed that to your logic:present name="" if necessary.
I think the default request scope attribute name, for the form bean associated with the action specified by your html:form on your jsp, is something like "org.apache.struts.action.BEAN"? though it's different in session scope, where there may be multiple form beans hanging around).
Similarly a "logic:notPresent" should fire if the "getFieldname" method returns null (but the "formname" bean still has to be there, or you'll get a servlet exception).
I usually pair any "logic:present" tag with a matching "logic:notPresent" tag just before or just after it, on the same exact name + property, so I can see that one or the other has definitely fired (have it just write out an html comment, perhaps, so you can look for it via "View Page Source" in the browser).
One tip: enclose your "logic:present" tag (the one with the property="fieldname") in another outer "logic:present" tag, with just the name="formname". That guards against the possibility that there IS no "formname" attribute in any scope (either because something failed, or because you are specifying the wrong name!!).
And of course match that with a "logic:notPresent" tag for just the name="formname" too, and see which one fires... you may be surprised by what this kind of careful defensive coding can tell you. It comes under the category of "this should never happen" in PRODUCTION, but in development/debugging it can be invaluable, and save you lots of time.....