Forum:

Question on rendering

Ranch Hand

Posts: 327

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Let's assume I have a simple component structure as below:

Now, if "myBean" has no data, "hasData" returns false, so "someComponent" and "someOtherComponent" will not be rendered. In that case, I would expect that "someData" and "someOtherData" would never be called as there is nothing to be done with those values. But this is not what appears to be happening, I am seeing them getting invoked and it causes one or two minor problems.

What am I not understanding about the rendering process and is there a way to stop the needless calls? Nothing to render - nothing to do.

Thanks.

SCJP6

Jason Irwin

Ranch Hand

Posts: 327

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Please, is there anyway to stop this unnecessary evaluation in RichFaces? if the control is not going to be rendered, there is no need to get its value.

SCJP6

Kavita Tipnis

Ranch Hand

Posts: 177

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Jason,
I tried a similar snippet to yours and it does not seem to have any problem. You can post your code and I can try that

Jason Irwin

Ranch Hand

Posts: 327

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Thanks Kavita - I will see if I can strip down some code and provide an example. I can see somethings getting called three or four times when there is simply no need. No doubt I have done something simple/stupid.

SCJP6

Tim Holloway

Saloon Keeper

Posts: 28819

212

I like...

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Your definition of "need" and JSF's definition are 2 different things. It's common for the property accessors of a JSF backing bean to be called many times for many reasons when rendering a view - or to be more accurate, within the request/response lifecycle of a JSF request. That's one of the primary reasons why the accessors should neither have side effects nor attempt to do heavy-duty processing - and especially they shouldn't attempt to access persistent storage!

When a JSF tag element is selected for rendering, it determines if and how its children are rendered. That can vary, depending on what the tag is supposed to do.

Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer

Jason Irwin

Ranch Hand

Posts: 327

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

That's my main issue - I am getting multiple hits to storage; although not from an accessor, they're all simple get/sets with no real processing. It's as if the datatable or datascroller is getting the results multiple times.

My pages are a bit of a mess just now - but I'll try to get some code up.

SCJP6

Jason Irwin

Ranch Hand

Posts: 327

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

What I am seeing is "getResults" being his twice and I do not understand why
1) There are no results to get sometimes (panel will no render, no need to get results)
2) There should be no need to call it twice, ever

I've been messing around with regions to try and stop this extra processing from happening and all I have succeeded in doing is breaking my partial page updates, the double hits to "getResults" are still happening. I also realise I probably have a few too many panel/panelGrids....

<html>
	<body>
		[A tool bar with some buttons]

<a4j:form id="frmAttributes">
			<a4j:queue id="qNoName"/>

<a4j:region id="rgnAttributes">
				<rich:panel id="pnlAttributes" rendered="#{lookupData.hasLookupData}">
					<h:panelGrid id="pnlAttributesLayout" columns="2" border="0" styleClass="panelText">
						[A bunch of text boxes, combo, date pickers etc]
						<h:panelGrid columns="2" border="0">
							<a4j:commandButton id="runSearch"  actionListener="#{searchBean.runSearch}" value="#{res.search}" 
							   reRender="pnlResults,btnExportResults" limitToList="true"
								onclick="#{rich:component('mpProcessing')}.show()"
								oncomplete="#{rich:component('mpProcessing')}.hide()"/>
							<a4j:commandButton id="btnResetSearch" reRender="pnlAttributes" value="#{res.reset}" actionListener="#{searchBean.resetSearch}" />
						</h:panelGrid>
					</h:panelGrid>
				</rich:panel>
			</a4j:region>

<a4j:region id="rgnMessages">
				<rich:panel id="pnlMessages">
					<h:outputLabel value="#{res.searchFailed}" rendered="#{searchBean.searchFailed}"/>
					<h:outputLabel value="#{res.noResults}" rendered="#{!searchBean.hasResults}"/>
				</rich:panel>
			</a4j:region>

<a4j:region id="rgnResults">
				<rich:panel id="pnlResults" rendered="#{searchBean.hasResults}">
					<rich:dataTable id="results" rows="10" value="#{resultBean.results.rows}" var="row" styleClass="fullWidth">
						<f:facet name="header">
							<rich:columnGroup>
								[A list of column definitions]
							</rich:columnGroup>
						</f:facet>
						
						[A list of <h:column>]

<f:facet name="footer">
							<rich:datascroller />
						</f:facet>
					</rich:dataTable>
				</rich:panel>
			</a4j:region>
			[A modal panel]	
		</a4j:form>
	</body>
</html>

From what I can see here, "pnlResults" will not render if "searchBean.hasResults" evaluates to false. This means that there should be no call to "resultBean.results". If there are results, there should only ever be one call to "resultBean.results".

At the moment searchBean is in session scope and resultsBean is in request scope.

Thanks for any help - this is driving me crazy!

SCJP6

Tim Holloway

Saloon Keeper

Posts: 28819

212

I like...

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Like I said, JSF's ideas and yours may not always be the same.

I would reasonably expect getResults NOT to be called when hasResults is false, but when it's true, there are a number of times/reasons to call it.

Don't forget that the JSF lifecycle isn't just about rendering. Stages include restoring the view, invoking the validators, applying updates and so forth. Although your particular dataTable is read-only, it's probably expecting too much that the JSF framework - at least for now - is smart enough to know that. So expect JSF to enumerate the rows in the model in the validate and update phases as it checkt to see if there's actually anything to validate or update.

Experience keeps a dear School, but Fools will learn in no other.
---
Benjamin Franklin - Postal official and Weather observer

Jason Irwin

Ranch Hand

Posts: 327

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Ah...OK. That sort of makes sense I guess. Is there anyway way for me to detect what part of the lifecycle I am in and then do less work in "getResults", or to skip validation of the datatable or soemthing?

I have got to find a way to stop/control these repeated hits.

SCJP6

Kavita Tipnis

Ranch Hand

Posts: 177

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Tim is right , you can try a simple sandbox code snippet just to check when the getters and setters are called
and at what stage of the JSF processing lifecycle.
Here is a sandbox that I tested right now

If there are results, there should only ever be one call to "resultBean.results".

Your code points to resutBean.results.rows (I think this might just be a typo

)

Jason Irwin

Ranch Hand

Posts: 327

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

Thanks Tim and Kavita. Hopefully that will give me some pointers on where to look at stop this unrequired processing. Or at least, mitigate its effects.

is there any way I can tell what phase in it's lifecycle the JSF is in? Perhaps putting "immediate" (or soemthing similar) in the correct place would solve the problem; or even placing logic in the backing bean.

Thanks again.

SCJP6

Kavita Tipnis

Ranch Hand

Posts: 177

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

You can add a faces lifecycle listener by creating a class that implements PhaseListener.
and then add the listener to the faces-config file
faces-config.xml

FacesLifeCycleListener

You can google for 'Phase Events' or read up in Core JSF by Geary&Hortsmann

As for the immediate attribute- it is used to skip validation for other input components.
Typically value change events are processed after the 'Process Validations' phase
but by specifying immediate=true for a component ,these events will occur after Apply Request Values phase
and you can bypass the rest of the JSF lifecycle

Jason Irwin

Ranch Hand

Posts: 327

posted 16 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

I implemented a PhaseListener just to see what was happening when in the log file. In "RENDER_RESPONSE" I could see the double output from the request-scope Result bean. So it is something in the rendering that was causing my double hit.

When I deleted the rich:datascroller the double his stops. So that is what is happening. One hit for the datatable, another for the datascroller.

That double hit makes sense now. Obviously the datascroller needs to work out its pages etc. But I can tell from the log that the Results bean is having to refetch data that it should have already worked out. So I looked a bit closer at the Results bean and there, sat at the beginning of "getResults" was a bug that I must have looked right through 100 times.

I had convinced myself I was not understanding Faces and that's where the problem lay - what I actually needed was a strong cup of tea and a sit down.

Thanks Tim and Kavita - your comments and advice got me look at and think about the problem the correct way.

SCJP6

The government thinks you are too stupid to make your own lightbulb choices. But this tiny ad thinks you are smart:

Clean our rivers and oceans from home

https://www.kickstarter.com/projects/paulwheaton/willow-feeders