OLD FORUM - Use new one: https://www.CaptainCasa.online/forum

Hi,

as of now it is not possible to use any EL operators inside grids (e.g. .{x != ""}) . I do understand that this is because the actual EL is calculated by CC.

What I imagine is at least limited recognition of operators, for example those which include only one operand (-, ! not, empty). These could be put at the beginning/end of the resulting EL expression.
Operators with 2 operands are more difficult as constants and references to attributes must be differentiated.

Do you think you can put some effort into this? In my opinion it would be very convenient.

BR

Hi,

yes, first: you are correct - the ".{xxx}" notation means that the actual expression is calculated. Concrete: the expression of the grid's OBJECTBINDING (e.g. "#{d.abc.grid}") is combined with the row-access and then the expression of the cell. E.g. "#{d.abc.grid.rows[0].xxx}" for the cell of the first row.

Well, now to the operators...: the combination of strings that is done within the server side grid processing is also done, if the cell-expression contains operators. I just tested:

Code:

 <t:fixgrid id="g_5" objectbinding="#{d.Test604.grid}" width="100%">
 	<t:gridcol id="g_6" text="Odd" width="100">
 		<t:checkbox id="g_7" selected=".{odd}" />
 	</t:gridcol>
 	<t:gridcol id="g_8" text="Odd Expr" width="100">
 		<t:checkbox id="g_9" selected=".{odd == false}" />
 	</t:gridcol>
 	<t:gridcol id="g_10" text="Shoe size" width="100">
 		<t:label id="g_11" text=".{shoesize}" />
 	</t:gridcol>
 	<t:gridcol id="g_12" text="Shoe size Expr" width="100">
 		<t:label id="g_13" text=".{shoesize * 3}" />
 	</t:gridcol>
 	<t:gridcol id="g_14" text="Name" width="100">
 		<t:label id="g_15" text=".{name}" />
 	</t:gridcol>
 	<t:gridcol id="g_16" text="Name Expr" width="100">
 		<t:checkbox id="g_17" selected=".{name == "Harry"}" />
 	</t:gridcol>
 </t:fixgrid>

...and this worked fine. See attached screenshot.

Please note: "complex" expressions are always resolved via the default expression resolved. And this means that all their contained parts are processed every time from the root of the expression. Example: if there is an expression #{d.abc.grid.rows[0].xxx} and then with the next cell #{d.abc.grid.rows[0].yyy}, then the internal access is:
1. >d >abc >grid >rows[0] >xxx and then
2. >d >abc >grid >rows[0] >yyy
In grids (with a lot of cells this may take quite some performance during (each!) roundtrip.

When using "straight" expression there is an own CaptainCasa resolution. Here the expression resolution keeps in mind the last epxression resolved, so that the access is much faster. E.g. in above's example when processing "2." then we already know that we did access "d.abc.grid.rows[0]" in step "1." and immediately call the getter for "yyy", instead of re-processing the expression from its root.

I am not sure why it is not working on your side. Maybe this response contains some hint...?

Regards, Björn

Ah, I see. Then obviously I mixed up some things. Without explicitly testing (shame on me) I assumed that no operators are supported.

If I understand correctly: State now is that operators appended to the field .{attr >= 5}, but only iff they work with constants.
This means, no prepended operators (empty, which I often use) work and obviously a comparison with other dynamic content is also not possibly, correct?

...correct. - Björn

Any plan supporting any of this?

BR

...not yet! ;-)

OK, what needs to be done: a proper parsing of the expression ".{...}" and then a corresponding concatenation. Proper parsing means that the "access paths" within the string need to be identified. This is not really trivial, because there are so many combinations (e.g. ".{cols['abc'].name == (cols['def'].firstName + cols['def'].firstName)}").

And all this extra functions in front of the background of performance issues... - and in front of the fact that we are operaing in some core part of the server side processing.

So, it's some "by the way issue"...

Regards, Björn

Alright, thanks for the information!

...did send some mail in parallel... - Björn