cancel
Showing results for 
Search instead for 
Did you mean: 

Compile-time check identification of view elements

Former Member
0 Kudos

Hi all,

i've posted this as a reply to another post already, i post it again here.

I think, it would be a good idea to generate an (maybe inner) interface class for each view controller which could be used to identify the view elements, which where created at design time (of course this is not possible for the elements added at runtime). This would increase the maintainability of code significantly.

For example, if i create a view "WorkView" which contains a button "ExitButton" and a checkbox "AdvancedSearch", the framework could generate an interface "IViewElementsWorkView" or inner interface "IPrivateWorkView.IViewElements", containing something like:

public final static String EXIT_BUTTON_ID = "ExitButton";

public final static String ADVANCED_SEARCH_ID = "AdvancedSearch";

...

Then, in the wdDoModifyView method, i could do something like:

if (firstTime) {

IWDButton exitButton = (IWDButton) view.getElement(IViewElementsWorkView.EXIT_BUTTON_ID);

IWDCheckBox advSearch = (IWDCheckBox) view.getElement(IViewElementsWorkView.ADVANCED_SEARCH_ID );

}

The compiler will then be able to check, if a view element has been removed or renamed, just like it's possible using the component's messages by the IMessageXXX class. This would be helpful regardless the fact, that the view elements could have been removed or destroyed at runtime.

Best regards,

Stefan

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Stefan,

I already sent this to some people within the team. I'll come back to you as soon as we have an answer.

At this opportunity: Thanks for all your activities within this forum!

Karin

Former Member
0 Kudos

Hi Karin,

sorry for my impatience I guessed the posting might have gone lost somehow at the point of software change.

Best regards

Stefan

Former Member
0 Kudos

Hi Stefan,

I am very sorry for the delay. Now let's discuss your proposal:

Obviously we discussed this approach several times before and could not find a "good" solution. You run in the risk of increasing the .class-Files heavily, if you generate an ID for every UI element. We think that programmatic UI tree changes are rather an exception than the standard. Also the changes would not affect all UI elements only some of them. We then discussed the idea of having an ID for that purpose, so that the application developer can put the ID onto the UI element where he exactly needs it. The result is that you have two IDs, also. That is why we rejected that approach as well.

So we still have it in mind but have not found a good solution for it. Do you have an idea???

Best regards,

Karin

Former Member
0 Kudos

Hi Karin,

to be honest, i started thinking by myself about the risk of getting too many (external API/implementation class per view) or too complex (inner API/implementation per view) classes after making the proposal. And, even worse, the ID approach isn't the best possible for the application developer since she/he still has to cast the returned element to the requested IWD-API type. It would be better to generate getter methods to provide type-safe access to the elements instead.

1. The internal view controller API in "IPrivate<ViewName>" gets an inner static interface "IViewElements" which provides the getter methods API for each view element and a method named wdGetViewElements() which returns the instance of IViewElements.

2. The implementation in "Internal<ViewName>" uses the view element ids to get and return the elements (inner class ViewElements, implementing IViewElements). Of course, "IPrivate<ViewName>" does also implement wdGetViewElements().

3. In the corresponding delegate "<ViewName>" you can then call for example:

//@@begin wdDoModifyView

if (firstTime) {

IPrivateISView.IViewElements ui = wdThis.wdGetViewElements();

ui.wdGetCheckButton().setOnAction(wdThis.wdGetCheckAction());

}

//@@end

This has the following advantages:

1. The API provided by wdThis is not blown up by maybe 200 getters for the view elements. So if you don't need them, everything is as usual.

2. There is no risk of method name collisions since the methods are capsuled in their own inner class/interface.

3. If you need to perform programmatic UI tree changes for the UI elements created at design time, the desired compile-time check is done (including type-checking).

The disadvantages are:

1. According to the number of view elements, there might be many, many getters, which results in large classes leading to an increase of memory consumption and decreases performance on generation.

2. The elements added dynamically at runtime are not accessible by this mechanism.

To continue the discussion:

I agree, that the programmatic access is the exception, one should use context attribute binding for manipulating the UI element properties generally. So the developers should decide, if they activate this feature or not.

I do not agree to the argument, that it's a problem, that not all elements are accessible at runtime (assuming that you mean the dynamically added elements are not). I'm in the same situation for example accessing context attribute element infos, elements and nodes:

wdContext.getNodeInfo().getAttribute(IPrivateISView.IContextElement.STATIC_ATT);

vs.

wdContext.getNodeInfo().getAttribute("DynamicAttribute");

From my point of view, possible solutions are:

1. An option at View level (represented by a CheckBox in the View property tab), which, if activated, triggers the generation of the API. All elements of all containers in the view will be provided or not.

2. An option at UI element container level (represented by a true/false property in the properties view of the container). All elements of this container will be provided or not (if the container is the root container, this is the same as 1.).

3. An option at UI element level (represented by a true/false property in the properties view of the element).

The option values should be false by default to avoid the overhead, if not necessary.

But to be honest again, i'm also confused because we would extend the WD metadata model to store information which is used by the WD generator. Isn't that a problem on the other hand?

Best regards.

Stefan

Former Member
0 Kudos

Hi Stefan,

Just for your information: Your proposal still circles within the team. I will let you know as soon as we have some more ideas and thoughts on it.

Have a nice weekend!

Best regards,

Karin

Former Member
0 Kudos

Hi Karin,

thank you very much for the information. If you are interested, i would like to send you a mail with some more information.

Have a very nice weekend, too!

Best regards,

Stefan

Former Member
0 Kudos

Sure!!! I guess it is needless to tell you my e-mail address

Talk to you soon!

Karin