Conditional GUI using tags

[guyr]

In our environment, users have different capabilities based on permissions assigned to their logon ids. Our existing implementation is JSP, and including or excluding different parts of the GUI is pretty straightforward; basically, you can define an "if" condition in a scriplet (chunk of Java code) that surrounds the HTML to conditionally include.

From searching the forum, the way to build such a conditionalized GUI in OL4 today is by building the interface in script instead of with tags. But as the OL4 documentation itself states, OL was designed primarily as a tag-based platform, and indeed in my short time with it the declarative form of the interface definition is straightforward and powerful. A further impetus in this direction is for teams with dedicated GUI designers; tag-based interfaces are more intuitive for the creative types.

So this wishlist item is to figure out some way to be able to conditionalize the GUI while still maintaining the declarative implementation as much as possible. I haven't really thought up a mechanism to do this. I found the following idea in a forum post:

What you mention is pretty much how databinding works in Laszlo. For example, the below "Next" button will ony be displayed if its datapath matches what's in the dataset.

<button datapath="dsInterview:/Page/Navigation[@Type='Next']" text="Next" />


But this doesn't appear to be generally extensible. The content of a component is typically independent of it's visibility. Perhaps an "if"/"unless" attribute can be added to all components derived from view:

<view id="x" if="condition"/>

If the run time condition is false, the view and all it's children are not instantiated. The condition would be Javascript.

[senshi]

Perhaps an "if"/"unless" attribute can be added to all components derived from view:

<view id="x" if="condition"/>

If the run time condition is false, the view and all it's children are not instantiated. The condition would be Javascript.

What about using "<state>"? So you can define the layout based on arbitrary expression just like your proposed "if"-condition and you'll still stay in a declarative programming manner:

<canvas debug="true" >
<attribute name="user_role" value="admin" type="string" />

<simplelayout axis="y" spacing="10" />

<view width="150" height="100" bgcolor="0xeaeaea" >
<state apply="${canvas.user_role=='admin'}" >
<text text="Current role 'admin'" />
</state>
<state apply="${canvas.user_role=='user'}" >
<text text="Current role 'user'" />
</state>
</view>

<button text="Switch user-role" >
<handler name="onclick" >
canvas.setAttribute( "user_role", canvas.user_role == "admin" ? "user" : "admin" );
</handler>
</button>

</canvas>

[guyr]

Senshi, I greatly appreciate your participation in these forums. I did not know about the state tag. I just read it, and I'm happy to see this:

"States can also contain views or classes that are only created when the state is applied."

From a security standpoint, not creating the nested elements is important. We don't yet know what the hackers are going to be able to do with Laszlo apps, so I prefer to keep excluded items out of the browser entirely, as opposed to creating them but making them not visible.

Thanks again.

[senshi]

From a security standpoint, not creating the nested elements is important. We don't yet know what the hackers are going to be able to do with Laszlo apps, so I prefer to keep excluded items out of the browser entirely, as opposed to creating them but making them not visible.

From this point of view, you should also think about using "<import>" to load libraries at runtime.
Using "<state>" you can avoid instantiation of your tag-defined components, but the class-definition will still be included in the downloaded application, so instances can be instantiated resp. created at any time by a "hacker", provided he can execute i.e. script-code.
If you use "<import>", the class-definitions can be loaded on demand. So in this case, the "hacker" can't instantiate the security-relevant classes, because they are not available at all.

I've just written some code which might be useful for secured-applications, just look at the attached resources:

"include_vs_import.lzx": the main-application
"include_vs_import_class.lzx": a test-class
"include_vs_import_class_2.lzx": another test-class
"include_vs_import_error.lzx": dummy error-library
"include_vs_import.jsp": acts as a server-side control for loading libraries (it's just more difficult to compromise the server in comparison to the client)