Dynamic UI Property Manipulation

[Former Member]

Hello,

In DOTNET I used to code in just one line if I had to change the property of some element in the form.

eg. textview.visible = false.

Here in WD, I have still not been able to find out a one line code to change the property of the UI element that I have used in my view.

I do not want to bind it to some attribute in the context. Just simple as DOTNET. Is it possible then please let me know. It would be of great help as I have put a lot of time into it but still have not been able to get through this.

Thanks,

Happy Coding,

Rahul

[thomas_jung · Accepted solution]

That is because .Net doesn't follow MVC (Model View Controller) in this regard and Web Dypnro follows the design pattern quite stictly. We don't suggest direct manipulation of the UI elements in code becuase this leads to a higher cost of maintainability of the code over time. Manipulating the context and then binding to the UI element properties leads to greater reuse and clearer maintainability.

However you can use the WDDOMODIFYVIEW event handler to more directly interact with UI elements. This approach is only recommended if you absolutely need dynamic processing (for instance the UI elements themselves are dynamically generated and therefore context bindings aren't appropriate).

[Former Member · Accepted solution]

I appreciate the response from your side and I have understood what you have been trying to convey.

Also, If possible can you explain me what actually do you mean by higher cost of maintainability?

If you can give me an example to help me understand better....

Thanks,

Happy Coding,

Rahul.

[thomas_jung · Accepted solution]

Lets say you have a button and an event handler for that button. Inside the event handler, you directly manipulate the visibility of part of the UI using coding.

Now you perform the same logic using binding to a context attribute.

Time passes.

Now the requirements have changed and you need to hide a different part of the UI under the same conditions. If you used context binding, you need only to reassign the bindings. You don't care where in the coding the context attribute was set. In the other case you have to find the code and you have to change which UI element IDs you are access.

Another example based upon the above. A developer comes in and renames the UI elements (maybe becuase he/she cut and pasted a section of the UI to rearrange it). This changes the UI element IDs and breaks the coding logic for changing the visibilty of the fields. However it doesn't harm the same requirement that is based upon context bindings because the bindings are independent of the UI element ID.