Declaring Rule Inputs in child interface

It simply is bad design to not declare inputs. It makes maintenance a hell. So yes, it is a best practice to do so.

It is suggested to declare the rule inputs in any of the interface/expression rule.. which can help to test it in the stage of development and easily maintainable.

Yes it is a best practice to declare the rule inputs. There are many reasons to that.
It will make easier to maintain
Defining rule input allows you to test the user interface.
Interface can be reused in many places and it will be easy for someone other than the developer who developed the interface to use it.
If we do not define rule inputs the context of the interface limits to the parent interface most of the time as this will have a tight coupling due to the way we set and use variables in child and parent interfaces.

So define your rule inputs that is a best practice.

Regards
Suresh

Hello!

I'm not sure I understood a single part of question. What is a child interface? Usually, interface display some data and collect some input from the user. What will be displayed on interface without incoming parameters? Where to input will be saved?

A child interface is a separate interface/rule called by a parent, which relies on the inherited variables (both local and ri!) from the parent. It will work since the interpreting engine simply assumes the local! and ri! variables called in the child are referring to those defined in the parent, but as others have noted here it's sloppy and not easy to test or maintain.

OMG! I tried and it works. The called interface took value from the calling interface. This is just ugly. In Java or other programming variable visibility is controlled by specific tools, but it is always clear on the level of the element being called what variable it is accessing. Here it will be just accessing nearest context available variable by name.

In this case I don't see any design issues if someone decided to not used any parameters when splitting an interface. But I assume such decision can be made in absolute certainty that the child will always be a child of this parent and no need in separate testing. Otherwise usual way is to parametrise a rule either it is interface or expression.

Usually it cannot cause any performance issues as the data for an interface is limited.

tirshar121 , Please refer docs.appian.com/.../SAIL_Performance.html for more details.

yes its bad design, it becomes very difficult to maintain when you many levels of child interfaces.

You should have to declare ri! variables in child interface its a good practice Some of the advantages of it are as below

1) If any operations need to be done on the variables before getting its final value, Then in that case u should just need to do this in the parent interface and simply pass the modified values in child interface. This makes code more feasible because next time when u are checking the logic, You don't need to dig inside each n every rules u created

2) If you are testing the interface and want to check what value your variables are storing, In that case your ri! variable helps you a a lot. Otherwise you have to create additional text box for storing and checking the local!variables value

3) In future if you need to enhance your code in such a way that some data needs to be taken from process model, Then you don't need to add any additional ri!variables under your interface(As it will already be available)

4)ri!variables also help to figure out the lifetime of a variable i.e upto how many interfaces/rule that variable exists

5) No chances of name Mismatch, That would be possible in case of local variable, etc

Hi trishar,

"A lot of child interfaces don't have variables(ri!) declared." where you saw this ? if this is the case then may it is requirement there.

we can not make anything best practice based on one rule or design. declaring rule input in child interface totally depend on the requirements.

If that child interface can be reused in any where in the entire application it is always good to declare the rule inputs so it can be reused by anyone without bothering the logic inside the interface.

if any child interface is created only for a specific requirement and it will never reused then you can avoid creating rule input.

regards
Abhay