JSP integration Suggestions

[GoogleCodeExporter]

Hi Jeff.
I've been evaluating jmesa for some work I'm doing and for the most part
I'm very satisfied. I'm using Spring MVC with annotations, and JSP pages as
a view.

There are a few comments that i think would make things "flow" better.
1. I would expect that my controller provides one model to the view, and
the view just does what is needed to transform the data into an HTML table.
This is "somewhat" doable, by doing a "tableFacade.render()", but any
integration with other parts of the the page need to be coded in java.

2. Doing pagination is awkward. In order to know what page to request and
how many records, i need to pull data from
"tableFacade.getLimit().getRowSelect()", but on the initial request those
are blank since there is nothing in the HttpServletRequest object.

Original issue reported on code.google.com by mla...@gmail.com on 19 Apr 2010 at 8:16

[GoogleCodeExporter]

If I could get a little background that would be helpful...

Are you using the Limit object to only pull one page of data at a time?

Are you using the tag library or the API? If you want to pull one page at a 
time you
can still use the tag library. The only feature that requires you to use the 
API to
render the view is when using AJAX.

Original comment by jeff.johnston.mn@gmail.com on 19 Apr 2010 at 9:46

[GoogleCodeExporter]

Thanks for getting back to me. 

Ideally we would do something like the following.
1) user requests a blank request (ie just localhost:8080/foo/list).
2) the controller would call back to the DB and grab a default set of rows (ie 
it
would get the correct default number of rows). Lets say it gets rows 1-10.
3) User paginates to page two. The controller would get only the next rows, 
that is,
11-20.

It seems like this use case is pretty awkward. Here are some issues:
1) the developer needs to define the maxRows/maxRowsIncrement in the view as 
well as
the controller so that he knows what the default number of records is.
2) In order to do pagination you need to pass both a list and the limit object. 
The
only "real" way to make a Limit is to use the TableFacadeImpl to parse the
HttpServletRequest object. It seems like it would be much more logical if i 
extended
TableFacadeImpl and then just bound it directly in the "<jmesa:tableFacade >" 
tag.

One other comment, It would be great if the examples were more runnable out of 
the
box. For instance, it looks like you need to have the President table set up in 
a
database.

Thanks
--Matthias

Original comment by mla...@gmail.com on 20 Apr 2010 at 1:08

[GoogleCodeExporter]

The examples use an in-memory database and is populated when you fire up the
application. What kind of problems are you experiencing?

I do know what you mean by awkward regarding the pagination. On one hand I 
really
like the way that the Limit object encapsulates all the data about the 
pagination
(page number, rows, etc...). And then you can manipulate the Limit object to 
throw
the table into a different state. But when you add in the exports and a few 
other
features you really need the TableFacade in there to abstract out other details.

What I would say is remember that JMesa is an API and was written to be very
flexible. You can see that by the way there are so many plugable points. And 
also
that the TableFacade is a facade over the rest of the API that tries to hide the
complexity. Feel free to try building other abstractions and see what you come 
up with. 

I try to stay very open to suggestions though and work with other developers 
when
they want to add functionality. If you want to try working on other 
abstractions and
have questions you can email me at jeff.johnston.mn@gmail.com.

To get JMesa up and running locally you can follow the instructions here. It is 
an
easy way to get the libraries downloaded and into your project.

http://code.google.com/p/jmesa/wiki/ProjectBuild

Original comment by jeff.johnston.mn@gmail.com on 20 Apr 2010 at 2:21

[GoogleCodeExporter]

Original comment by jeff.johnston.mn@gmail.com on 9 Mar 2011 at 8:39

• Changed state: Invalid