Enterprise Client Community

Hi community,

I've following problem!

I have a page with a combobox and and fixgrid, now I want to set the combobox' enabled property to false when there're no items in the grid!
The problem by now is that my check:
Code:

 public boolean isDetailFilled() {
 		return gridDetail.getItems().size()>0;
 	}

Is checked before my grid is filled!

Anybody out there who had a similar problem?

regards
Markus

hmm, it seems that this occurs when the page is handled as modal popup!
Although the items are filled before, the .size() return 0.
I think I check the grid on a wrong instance?

ok, I found the problem, but I don't understand!
When I use following expression in the enabled property it fails, because the wrong instance (from main dispatcher) is called:
Code:

#{d.ScheduleChangePopUp.creatorSight==true && d.ScheduleChangePopUp.detailFilled==false}

Is the syntax wrong?
When changing to:
Code:

#{d.ScheduleChangePopUp.detailFilled==false}

The method is called from subdispatcher, everythings ok?!

Knowing this it could do a workaround, but I'm interested in the cause for this behaviour?

Markus

Hi,

hmm, hmm, in general I would always use as straight expressions as possible (no logic within expressions). We are doing replacements (e.g. from #{d to #{d.d_1, within the workplace/sub-dispatcher management) which may fail otherwise.

Regards, Björn

Hi,

I'm also using expressions with "logic" - until now only to invert the value of a boolean property.
In the eclnt-log I see then the following entry:
"Expression detected for which non-optimized value expression is used: #{d.DemoUI.DemoBean.isCalculated == false}"

Using an expression like this is "very elegant" but obviously not considered as "optimized".

Why? Is it "only" because of the replacements being done?

Is there an optimized way, that ist still "elegant"?

Thanks, Thomas

Hi,

CaptainCasa uses an own expression resolver (this is something you can exchange in JSF) for simple expression "#{xx.yy.zz}" - i.e. straight expressions, without logic.

Only reason: performance... - the default resolvers always resolve an expression from its beginning. The CaptainCasa resolver keeps in mind the "expression stack" that was alread resolved. E.g. when having resolved "#{d.aaa.bbb.firstName}" and then resolving "#{d.aaa.bbb.lastName}" then the expression is resolved from "bbb" on.

As far as I see the problem that you had was because you had a syntax like "#{d.xxx.yyy && dd.xxx.zzz}". In this case the disptacher replace fails because of the second expression, not starting with "#{". - "Failing" means that the left side was properly replaced, the right side not.

Regards, Björn

...forgot to mention: if the CaptainCasa resolver sees that an expression is NOT a straight expression it delegates to the normal resolver. This is when the log message "non-optimized" appears...

Björn