Can't access methods declared in Interface Controller

[Former Member]

I have a DC that implements a simple search function. I would like to expose this search function through the component interface, so I've done the following:

DC 'a' is the used component that implements the search function, and DC 'b' is the calling component.

In DC 'a' I've added a method to the interface controller to kick off the process - the method delegates the 'window open' function to the component controller. I've also created an event that indicates a selection was made. When an item is selected in the view, the controller fires the event in the interface controller.

Here's my first question: this creates a cycle between the interface controller and the component controller, but I'm not sure how else to do this. Is this correct, or is there a better way to do this?

Second question:

Once I add the component to the public part of DC 'a' and do a DC build, I tried to use the DC from another DC, DC 'b'. I've added the interface controller to the list of required controller in the component controller of DC 'b', and I've created an event handler for the event published in the interface controller of DC 'a' - that works just fine.

However, I CANNOT get at the method I defined in the interface controller of DC 'a'. No matter what I do, I cannot get at it. This is very strange to me, since I CAN see the event. Even though I've added the interface controller to the list of required controllers, I can't see it in the editor when I try to do command completion via wdThis.wdGet....all I can see is the DC 'a' component usage object, which is of no use in this situation.

Can someone explain to me why I can't see the method?

Lastly, I think the proper way to do this is to use the 'Web Dynpro Component Interface', and to create a proper interface that exposes only what I want to expose in a very controlled manner. However, after creating the interface, and indicating that the component controller of DC 'a' implements the interface, I'm at a loss - what do I do next to bridge the gap between the Component Interface, and the component controller?

Sorry for the long note, but this was a difficult problem to describe.

[Former Member · Accepted solution]

Ken,

First question: <i>this creates a cycle between the interface controller and the component controller, but I'm not sure how else to do this. Is this correct, or is there a better way to do this?</i>

Sometimes such cycles in controller references simply inevitable in WD. Typical case if you have both context mapping and delegating method call between interface/component controllers. Your case is just another example.

Second question: usage and non-visible method.

Actually, when you add required controller usage you may add both usage and used controller. Make sure you select both check boxes. So in your code wdThis.wdGet<UsageName>InterfaceController() should be available.

Also if you do not see method use "Build DC" (not a "Rebuild Project"!!!) on first DC, then reload second DC. Or re-open second DC project. Or restart IDE. Build, reload... Build, reload...

Plus if you can see usage of interface controller but method is still not available, check corresponding IExternal* Java interface generated for used component. If it misses method, then this is well-known IDE bug. Try to remove method from interface controller, then build, then restart IDE, then add method again, build restart. I know how this sounds These tricks are necessary to flush out wrong designer metadata.

Too long reply, probably third question should be discussed separately.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[Former Member · Accepted solution]

Valery,

Your advice worked - I cleaned everything up, closed the IDE, restarted, rebuilt, and gee, guess what - I'm now able to fetch both the interface usage and controllers - the method is now accessible. I'll be sure to check the IExternal* classes next time.

What a truly annoying bug. Hopefully this is fixed in SP17 or SP18 - unfortunately, we're stuck with SP16 for the time being.

Thanks once again.

[BeGanz]

Hi Ken,

I adapted your third question to my understanding.

<i>Lastly, I think the proper way to do this is to use the 'Web Dynpro Component Interface Definition', and to create a proper interface that exposes only what I want to expose in a very controlled manner. However, after creating the interface definition, and indicating that a Web Dynpro component of DC 'a' implements the interface definition, I'm at a loss - what do I do next to bridge the gap between the Component Interface Definition, and its component implementation?</i>

Is this what you meant? What do you mean with "bridging the gap between 'Component Interface' and 'Component Controller'? Do you want to know how a component can use a component interface definition at designtime which is represented at runtime with a certain component instance implementing this interface?

Regards, Bertram

[Former Member]

Bertram,

Well, perhaps I'm confused. I don't think I fully understand how the "Web Dynpro Component Interface" is to be used. I understand that you can create an interface and define events and methods, and make the component interface visible via a public part - then, any methods that you define are visible outside the component. I also understand that you take an internal component and say that it implements the interface. However, I don't understand what the 'implemented interfaces' for a component actually means.

In the context of a Java class and Interface, implementing an interface means you implement the various method signatures defined in the interface. But how does this work in a Web Dynpro component?

[Former Member]

Ken,

As with programming languages, WD interface is necessary if you want to define certain contract, assuming that several implementation of this contract possible.

In WD "contract" may include:

-- methods of interface controller

-- events of interface controller

-- context structure of interface controller

-- interface controller view (with corresponding plugs)

If certain component implements interface, it must fulfill this contract, i.e. has all methods implemented, has all events declared, has matching context structure (all nodes with same cardinality/selection cardinality as in interface, all attributes with same names and types as in interface), has all necessary interface views and hence all windows that are declared by interface.

Embedder may declare component usage based on interface (rather then concrete component), and then create concrete implementation explicitly via

wdThis.wdGet<UsageName>().createComponent(qualifiedComponentName);
wdThis.wdGet<UsageName>().createComponent(qualifiedComponentName, dcName);

Typically, such name are externalized to property files or database. Sure, you may have several options hard-coded and just select between necessary one.

Btw, it's not mandatory to expose interface to public part. You may have interface internal to your DC and have components within same DC that implement interface.

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[Former Member]

Hi,

Great Explanation to say the least.

Can you just give me a real life example in detail of the implementation of an interface controller.

Rgds

Shashank