I'd like to mix a little JSP into my JSF code here for logging purposes. I've got a dataTable and I'd like to annotate my log file with some of the information that is going out to the displayed page. (Yes, I do get that not much if any of this sort of thing should be done, but please humor me if there's an answer.)
How do I get the reoccurring (for each row of the table) value of JSF _title for use in JSP? (By the way, the code and page work fine as is, but I want to do a little logging for various reasons.)
A datatable is not a loop. In fact, it's not a logical construct at all. Logical constructs are generally not something that should appear on JSF Views, since unless they're only concerned with the presentation the way "render" EL expressions are, they corrupt the MVC architecture. At any rate, datatable is a 2-dimensional View Object, and the "loop variable" isn't technically a loop variable, it's a row reference. The difference may seem subtle, but it's critical. Incidentally, I don't recommend beginning an object/property name with "_". Sometimes JSF has additional name-format restrictions above and beyond the Java langguage ones, and in any event, "_" is conventionally reserved for system internal variable names.
In line with datatables not being loop constructs, what actually makes more sense is to log the datatable's backing datamodel that goes out to the view, if that's what you want. The best way to do that is simply to iterate the rows at the time you bind the datamodel.
Just for the record, I don't really recommend mixing HTML and JSF tags either, but it's an uphill battle on that one.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Feb 26, 2008
Copious thanks my friends. I only submitted this after poring over Geary/Horstmann Core JSF.
Pradeep, this question was really a bit broader underneath, but I thought this the best way to get it answered.
Thanks to Tim for the formal theory; it's very useful and I get it.
I found the underscore prefix as a suggestion out there in cyberland somewhere, it seemed reasonable and it served me well for the purpose of distinguishing the identifier from other, common identifiers which are a bit too numerous in such JSF constructs. Thanks for the warning, however.
On the HTML, I yesterday fought all day long to find h:panelGrid/h:panelGroup solutions that worked, not for this code, but for table groupings of mostly h:selectManyList, h:selectOneList and h:inputText (all with naming prompts--what in juxtaposition to the lists totally stiffed my use of a CSS class containing vertical-align: top), specifically to top-align data without success only to return to HTML, tried and true, through and through. Of course, alas, I'm arguably slower than the average bear, so I may have run back home to momma (HTML) a little too fast.
I can sympathise. panelGrid usually serves when you need a table, but thanks to the lack of a colspan attribute, it frequently requires creating a "lowest-common-denominator" parent panelGrid with embedded sub-panelgids. An additional aggravation is the lack of direct access to the "tr and td" elements where we like to hang attributes in HTML. Sometimes row and column classes won't give fine enough control on a cell, in which case I end up embedding something awful like a 1x1 panelGrid, or occasionaly cheat and do an HTML div, which I console myself in that div and span aren't as blatantly display-specific as some other elements.
Although HTML and JSF live together much more peaceably than back in the JSF 1.1 days, it's still good to avoid HTML if you reasonably can. You never can tell when a supposedly browser-only app is going to be required to run in a non-HTML environment like WAP. And you can get that working this afternoon. right? Our ace salesman promised the customer. Since All You Have to Do Is...