Resolved Suitable method for accessing 1 single-dim array of 'int' and 1x2-dim 'int' array

[damo.gets]

Okay, I originally posted the following message on a small BBS system that I'm a member of, but never received any replies back to it due to their limited userbase. The full text of the question/problem is in there; I'm just explaining this in case it seems to be worded a little bit weird for posting on a forum like this.

----------------------
I think I'm going to be needing some advice about how to handle passing some complex data structures from a java Bean back to the calling JSP pages for processing in a table. Of course I suppose I can handle this by generating the HTML for the table right within the bean and just trying to pass the HTML back, but I'd like to leave the layout in the JSP if possible for clearer design and future extendability/code maintenance.

Now I've only passed data primitives, and no arrays between Beans 'n JSP previously. The data structures that I have to deal with are as follows:
int x []
int y [][]

Not sure if the easiest way to do this is by enclosing in a custom object or if I can do this with just the arrays, or if arrays are even accessible within the JSP. From that point I don't know how to access the arrays from within my JSP. Anybody have any advice and/or any pointers to references for issues like this?

----------------------
I then found what seems to be a probable answer through some more in-depth googling and posted the following continuation:

Okay, a bit of further googling and I think I may have a plausible answer...

I haven't yet had the opportunity to utilize anything from a Bean within a scriptlet embedded in my JSP, so I'm not sure if this is the right idea or not. Right now I'm thinking of the following method, though.

...  //unrelated .jsp code

...  //related .jsp processing and Bean calls to set up values within the Bean

<%
        .. //java conditionals to find out if we're currently displaying this
        for (... //java constructs to iterate through array dimentions
          {
                out.println("<%-- HTML/JSP formatting crap here --%>\n");
                out.println(x[counter], ": ", y[counter][counter2], "\n");
        }
%>

...  //etc, etc, etc

This should dump in the values of x[] and y[][] into the applicable HTML generated on the fly, no?

-=-=-=-
Damon Getsman
Programmer/IT Customer Relations
ITRx - http://www.itrx-nd.com/
-=-=-=-

[damo.gets]

My solutions (well I'll know for sure on that just as soon as I get this to compile [unrelated errors]) weren't too terribly hard to find once I figured out good google-fu for my issue. Here are my posts from the same system I was talking about before that show how I accessed the 1 & 2 dimensional arrays (set in a Bean, accessed from a .jsp fragment) in my project:

Okay, a bit of further googling and I think I may have a plausible answer...

I haven't yet had the opportunity to utilize anything from a Bean within a
scriptlet embedded in my JSP, so I'm not sure if this is the right idea or not.
Right now I'm thinking of the following method, though.

...  //unrelated .jsp code

...  //related .jsp processing and Bean calls to set up values within the Bean

<%
        .. //java conditionals to find out if we're currently displaying this
        for (... //java constructs to iterate through array dimentions
          {
                out.println("<%-- HTML/JSP formatting crap here --%>\n");
                out.println(x[counter], ": ", y[counter][counter2], "\n");
        }
%>

...  //etc, etc, etc

This should dump in the values of x[] and y[][] into the applicable HTML
generated on the fly, no?

----------------------
Reply from a more experienced JREE/JSP developer follows:

for ( dim1 from 0 to x.length ) {
out.print <tr><td>+ x[dim1] + </td><td>
for ( dim2 from 0 to y[dim1].length ) {
out.print y[dim1][dim2] + ","
out.print(</td></tr>)
}

yeah, you got the right idea i think. don't forget to manage yr inner loop
properly.

----------------------
Anyway, hope this helps some others in the future; the documentation on this issue was kind of tough to turn up.