This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Passing parameters between JSF pages from a normal List object without using DataModel  RSS feed

 
Jay Tai
Ranch Hand
Posts: 222
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would like to know ihow to use the id parameter in my documents entity to download documents from a list of documents. Normally I use ListDataModel and the getRowData method. I would like to know how to achieve the same thing using an ordinary List object.

My list of documents is called List<CountryDocs> selectedDocs;



Clicking on the download link calls the following method in my managed bean:



Debugging shows the value for the id is 0 and this results in a NullPointerException. I've tried several methods for grabbing the document id in my backing bean, but no luck yet. I also read about the the ViewParams and ViewAction method but they caused validation errors to do with the <f:metadata> tags.

I'm surely missing something very basic and I don't know how to obtain this value using a normal List object. I would really appreciate some guidance on how to do this and where I"m going wrong. Thank in advance!
 
Tim Holloway
Bartender
Posts: 18709
71
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's an exercise in futility.

If you define a bare array or collection as a value in a dataTable tag, JSF will create an anonymous DataModel object and wrap the collection. It needs the DataModel to maintain its own internal state, so not explictly defining one saves you a miniscule amount of coding for no actual savings in resources.

But because it's an anonymous DataModel, your application code has no simple way to get the selected row, and adding code-like constructs (parameters) to your View Template actually makes it even more complex.

You're better off just constructing a ListDataModel, wrapping it around your List, and defining a "get" property for it in the backing bean.
 
Jay Tai
Ranch Hand
Posts: 222
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So if I understand you correctly Data Model is the default behavior of jsf when it comes to handling parameters. An anonymous ListDataModel will be created anyway so it's best to simply override the default behavior. So Data Model is simply the most reliable method for handling parameters in jsf?
 
Tim Holloway
Bartender
Posts: 18709
71
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not exactly. JSF is a fairly pure implementation of the Model/View/Controller paradigm, and MVC doesn't have "parameters". The Controllers bind the Models and View directly. In the case of a dataTable on a web page, the page definition (xhtml) is used to construct the primary View, and EL references in that View are used to bind Controllers to the backing bean(s) - which are the Models. The master Controller is the FacesServlet, the subsidiary Controller for the dataTable sub-View is the DataModel object which assists the Controller in keeping the sub-Model (List or whatever) in sync with the sub-View.

Conceptually, then, each row in the dataTable is itself a sub-sub-model and the rendered row on the displayed page is its corresponding table sub-View's sub-View. 3 layers, then: page, table, row, each with corresponding view and model components and JSF constructs and/or binds Controllers to look after them, so no parameters required.

Originally, JSF was very much bound up in the idea of the data being server-side, and only manipulated client-side, not resident there. Not everybody likes that idea, since it puts more load on the server and with many users, there's only 1 server (more or less), so the server can end up stressed.

On the other hand, putting the data on the client has issues. It's a big security risk, passing data to and from the server for processing is a lot of overhead, you do end up mucking around with parameters, there's the danger that comes when processing is splattered between 2 different systems, and if the data is long-term stored on the client... well, clients generally don't get backed up as reliably as servers do.

Which is why I prefer to stick with the original concepts, despite their occasional unwieldiness.

Even now, the primary reason for putting parameters in the View template is to enable being able to do GET-style JSF page references. Which is useful, since you can bookmark GET URLs. The normal JSF mode (POST) cannot be bookmarked with all the proper context needed. At the risk of repeating myself, however, client-side data can be hacked, so I prefer to limit this sort of thing to stuff that cannot do damage. For example, links to stuff in a shopping catalog as opposed to, say, a one-button click that sends in my income tax data.
 
Jay Tai
Ranch Hand
Posts: 222
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. Quoting from your prior post "It's an exercise in futility". Taking that into account plus your most recent post I want to make sure I'm following 'best practice' for jsf (if such a thing exists). I follow the client vs server content debate. What I'm not grasping is whether it's mandatory to use DataModel to handle parameters OR if it's possible to use alternative client side ways to pass parameters but those alternatives can be quite buggy and not secure?
 
Tim Holloway
Bartender
Posts: 18709
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe the term "Best Practices" isn't a good concept. There's good practice and bad practices and lots of practices in between, and sometimes what marks the position of something on that scale is what you're trying to do and even how you (or the people who inherit this stuff) think. My "Best Practices" aren't engraved in stone; I'm not into inflexible ideology. They're practical approaches that work for me, often learned the hard way, but they will be put aside if a problem works better some other way.

A datatable doesn't need "parameters". Parameters are data items supplied as variant data to a method invocation (function call, whathever). In the case of an MVC mapping, there's really nothing variant as such, because each sub-view has known corresponding sub-model. That sub-model (for example, a row in a tabular List), is often sufficient unto itself, although it may sometimes provide leverage into other spaces (for example, a summary row containing a detail record's database key).

The reason I don't like parameters on Views is it makes them more logic-like. Once they attain logic status, you no longer simply worry about what the View is, you also have to worry about what the View does. Keeping the view as a simple template and putting the logic in the UI Model objects means that there's "one-stop shopping" for functional behavior - no need to "treasure hunt" to find what gets done where. There's less coupling - and MVC was originally invented largely to decouple things to begin with. The decoupling makes it easier to recycle both Model and View for other needs and other environment. And it's a :censored: lot easier to debug POJO code than it is to debug EL or XML data expressions.

Mandatory DataModel? Well, like I said, if you use a dataTable, a DataModel will get built. The question is: do you want it done automatically at the cost of not being able to get at the goodies or manually at the cost of writing a little extra code? If you're doing a display-only table, an automatic DataModel will save you a little time, since there's no "parameters" and no model construction/access code to write. On the other hand, if the table rows have links or command buttons, you're better off having your own dataModel so that you can get the corresponding sub-model data with a simple method call.
 
Jay Tai
Ranch Hand
Posts: 222
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's so useful to understand this stuff from the ground up instead of getting quick code fixes on this forum. What I'm getting from your last post is that it's more 'natural' to use data models in order to derive the efficiency benefits and underlying, inherent advantages of jsf. But one alternative to the datamodel method is to embed parameters in the view object. This is neither advisable nor does is leverage a key purpose of jsf, which is to automate communication between views? If that is correct I guess I'm just intrigued about why you would describe alternative methods as an exercise in futility? Are you saying it would be messy and buggy to do that? I just want to ensure I have a sound understanding of these concepts
 
Tim Holloway
Bartender
Posts: 18709
71
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, it's a key property of MVC to automate syncing of Data and Model. JSF is simply one web-based implementation of MVC.

I used the phrase "exercise in futility" to mean that it's futile to use a raw collection as a dataTable value, since one way or another, a DataModel will get built, so for the "clever" people who think they're "being more efficient" by passing raw collections, they're deluding themselves. And losing a key benefit of having an explicit DataModel.

You can, of course, build up a table from brute-force efforts. For example, using the ui:repeat to create a raw HTML TABLE tag structure. And parameterize it all you like. But the dataTable provides an abstraction (a table is, after all, a 2-dimensional data display, not a loop), plus it's fairly clean to code and is supported by a well-documented standard (more or less. The Javadocs are pretty awful). And it provides that useful Separation of Concerns that's much harder to achieve when resorting to cruder methods.

 
Jay Tai
Ranch Hand
Posts: 222
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was trying to be one of the 'clever' ones by putting in my own parameters. It all makes sense now and the generic data model is probably more efficient than anything I could write. THANK YOU!
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!