Strange Error with JSLT and JSON Taglib Array in JSP using "." (dot operator)

[Stephen Davies]

Hi,

Given the following class;

 import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class VisitNewWidgetTestTemplateClass
{
	public String widgetName, widgetAuthor, widgetDescription, loadUrl, objectName;
	
	public Map<String,String> parameters = new HashMap<String,String>();
	public List<Map<String,String>> thisWidgetParams = new ArrayList<Map<String,String>>();
	
	public void setParamter(String paramName, String paramValue)
	{
			parameters.put(paramName,paramValue);	
			thisWidgetParams.add(parameters);
	}
	
}

..and the following JSP Page (assume all taglib and other utilities and imports are OK, as there are some private company data API imports I don't wish to publish)

	List<VisitNewWidgetTestTemplateClass> allWidgets = new ArrayList<VisitNewWidgetTestTemplateClass>();

			
	VisitNewWidgetTestTemplateClass testWidget = new VisitNewWidgetTestTemplateClass();
	testWidget.objectName = "TestObjName";
	testWidget.widgetName ="testWidget";
	testWidget.widgetAuthor="Steve";
	testWidget.widgetDescription ="A Test Widget";
	testWidget.loadUrl = "new visit.testWidget";
	
	
	
	
	testWidget.setParamter("renderTo","widgetView");

		allWidgets.add(testWidget);
	
		request.setAttribute("allWidgets",allWidgets);
		
		
	%>
	
	<c:set var="atg.taglib.json.prettyPrint" value="${true}" scope="application"/>

	<json:object>
		
		<json:array name="widgetDetailsList" var="widget" items="${allWidgets}">
	
			<json:object>
			
				<json:property name="widgetName" value="${widget.widgetName}"/>
		    	<json:property name="widgetAuthor" value="${widget.widgetAuthor}"/>
		    	<json:property name="widgetDescription" value="${widget.widgetDescription}"/>
		    	<json:property name="objectName" value="${widget.objectName}"/>
		    	<json:property name="loadURL" value="${widget.loadUrl}"/>
		    	
			</json:object>
			
			
	  	</json:array>
	 </json:object>

Can some kind soul explain why I may be getting the following error?


Unable to find a value for "widgetName" in object of class "org.visit.web.widgets.widgets.VisitNewWidgetTestTemplateClass" using operator "."


Now after several debug runs all the variables given in the example are OK and contain values. However I read somewhere that the array var (in my case "widget") refers to an instance of String, but if this is so, how can any non String, object of a passed collection or Array be accessed in this way?

(Environment is OSGI running of a Jetty Server in Eclipse Galileo)

Thanks in advance!

[David Newton]

What makes you think ${widget} refers to a string? It'll refer to whatever is in the list: widgets. Is that what you meant?

[Stephen Davies]

David Newton wrote:What makes you think ${widget} refers to a string? It'll refer to whatever is in the list: widgets. Is that what you meant?

Well actually it doesn't make me think it refers to a String, as I mentioned, I had read it in passing from some obscure forum / mail thread following a google search. I write many JSON generating files regularly yet this is the first time I have encountered this issue. I'm not sure where you got 'widgets' from, so no that's not what I was referring to.

On the contrary I was certain that the var referenced the current iterated object on the passed list, in my case "${widget. ...}" should indeed refer to an instance of a VisitNewWidgetTestTemplateClass object within the list (in fact there is at present only one on the list for testing). Hence calling the "." operator and a resulting field should, in fact, return a value as specified. This issue is further confounded as subsequent debugging reveals no nulls or empty values for the related fields, to this remains a mystery to me.

Any further ideas?

[David Newton]

Stephen Davies wrote:I'm not sure where you got 'widgets' from, so no that's not what I was referring to.

Because you said:

However I read somewhere that the array var (in my case "widget") refers to an instance of String

Because neither the list, nor each item in the list, is a widget.

[Stephen Davies]

Because neither the list, nor each item in the list, is a widget.

Semantics aside, I understand, that var="widget" is not referring to a String, thought I was of the understanding that it was a reference to the current VisitNewWidgetTestTemplateClass object in the List, as that is what the List is declared to hold, and that is what I believe I had put in there. However if this is not the case, then herein lies my issue, indeed what does the "widget" variable actually refer to then?

[David Newton]

Not sure what I meant with the last sentence in my last message.

[Paul Clapham]

Stephen Davies wrote:... I was of the understanding that it was a reference to the current VisitNewWidgetTestTemplateClass object in the List, as that is what the List is declared to hold, and that is what I believe I had put in there. However if this is not the case, then herein lies my issue, indeed what does the "widget" variable actually refer to then?

The error message there tells me that the "widget" variable refers to an object of the org.visit.web.widgets.widgets.VisitNewWidgetTestTemplateClass class. And it also tells me that that class doesn't have a public, non-static, zero-parameter method named "getWidgetName".

[Stephen Davies]

Interesting, so as I don't have a public 'getWidgetName' method (non static, no argument), herein lies the issue? I was under the impression that having public instance variables was sufficient, perhaps not good OO due to the lack of encapsulation, yet still in that calling #Object.#variable name was enough, to provide the value?

So if I am understanding correctly, with in the JSON array even if my call to ${widget.widgetName} is dot notation, it is still necessary to provide a getWidgetName() method in my class? Is there some sort of implicit calling here, and if so how does the JSON determine between 'getWidgetName', or 'getwidgetName' for example? (Or have i indeed just answered my own question in that the standard getWidgetName would be the implicitly called behavior)!?

[Bear Bibeault]

These are basic JavaBean concepts. Properties are defined by the getter and setters. Classes that don't conform to the javaBean rules won't work.

[Stephen Davies]

Oh, thats certainly something new to me, thanks for the heads up, I was under the impression that the javaBean convention was a guide rather than a rule. So for JSP /JSLT in this example it is a rule rather than a simple convention?

Thanks again for the help all

[David Newton]

It's a rule if you want to use most reflection-based ELs/frameworks.

If you look at most any JSP EL tutorial (like this one) you'll read:

An expression language makes it possible to easily access application data stored in JavaBeans components.

So is making things JavaBeans a *rule*? Probably not in any strict sense, but if you want things to actually work, it's a good idea. (Annotations have replaced the necessity of setters in some frameworks.)

[Bear Bibeault]

In the same way that making sure to put gas in your car is a "rule". No one's going to force you to do it, but if you don't, things just don't work out too well.

[Stephen Davies]

Bear Bibeault wrote:In the same way that making sure to put gas in your car is a "rule". No one's going to force you to do it, but if you don't, things just don't work out too well.

Ok please bare with me here (no pun intended), I'm not usually a JSP JSLT person, so please excuse my ignorance. However, during my SCJA days I learnt that the JavaBean convention for e.g; 'suggests' among many other things, that you should name your getters and setters (which are good practice but not vital for basic functionality), with camel-case lettering, in my case, getWidget or some sort like this. Now it is my understanding that in usual Java practice, naming getters and setters 'get_widget', 'get widget', GetWidget', or even '$getWidget' whilst unbecoming, and poor code, nonetheless will still operate upon any 'explicit' call to them later in the program, in fact, I have come across many examples (not to pass any judgement upon them) where a public reference variable is indeed accessed not by a getter and setter but by the dot operator (as in #Object.#member#).

Now please, do not misunderstand me, this is what my understanding has been in regards to non web-based Java development, (though personally I favor the JB convention, as do I like clean simple and well commented code). My question therefore still stands, (though perhaps I'm a little nearer to an understanding). As you kind moderators Bear, David and Paul seem to be exemplifying, is that in regards to my posted predicament, within the JSP / JSLT Taglib domain, the functionality I'm trying to implement in my code, is that which requires javaBean 'rules'. So as doing so, I am lead to the new comprehension that the calls to the JSON via ${#var.#member} are in fact, an implicit call to a getter based on JB convention in my class in question?

Again, these things are new to me as I work predominantly in javaScript to Java where we have company written JSON producing java-API. We certainly use JSP as part of an MVC architecture, but most of the Taglib JSON production is simple Maps and Array iteration, less on object traversal. In this case, I was asked to change the implementation away from my posted example, but it is certainly refreshing to learn something new here and once more I thank you gentlemen.

[David Newton]

Stephen Davies wrote:Now it is my understanding that in usual Java practice, naming getters and setters 'get_widget', 'get widget', GetWidget', or even '$getWidget' whilst unbecoming, and poor code, nonetheless will still operate upon any 'explicit' call to them later in the program,

Sure--they're just methods.

in fact, I have come across many examples (not to pass any judgement upon them) where a public reference variable is indeed accessed not by a getter and setter but by the dot operator (as in #Object.#member#).

Assuming those "#" things are there for some reason other than being Java, sure, you can access public instance variables directly.

Now please, do not misunderstand me, this is what my understanding has been in regards to non web-based Java development, (though personally I favor the JB convention, as do I like clean simple and well commented code). My question therefore still stands, (though perhaps I'm a little nearer to an understanding). As you kind moderators Bear, David and Paul seem to be exemplifying, is that in regards to my posted predicament, within the JSP / JSLT Taglib domain, the functionality I'm trying to implement in my code, is that which requires javaBean 'rules'. So as doing so, I am lead to the new comprehension that the calls to the JSON via ${#var.#member} are in fact, an implicit call to a getter based on JB convention in my class in question?

Too many words.

There are no "calls to the JSON". JSP EL expressions ("stuff inside ${}") must follow JavaBean conventions [if you want it to work].

Of course, I *personally* don't believe this kind of work should be done in a JSP, especially when there are JSON libraries that would do this in a single line of testable Java code (delta any renaming/massaging you'd want to do).

Again, these things are new to me as I work predominantly in javaScript to Java where we have company written JSON producing java-API. We certainly use JSP as part of an MVC architecture, but most of the Taglib JSON production is simple Maps and Array iteration, less on object traversal. In this case, I was asked to change the implementation away from my posted example, but it is certainly refreshing to learn something new here and once more I thank you gentlemen.