cancel
Showing results for 
Search instead for 
Did you mean: 

WDA: How to enhance Interface / Component Controller

Former Member
0 Kudos

Hi there,

I'm facing an issue while implementing a customer specific requirement. In this requirement I need to pass certain data values from the lower embedded WD Component to an upper level parent WD Component.

These are all standard WDC's. The technique I'm using to realize these requirements is mainly through the Enhancement Framework. What I'm facing here is the (obvious) limitation of enhancing an interface controller or setting the component context node(s) as interface nodes. Nearly all is possible to be enhanced within WD4A as I found out... But it seems that enhancing the interface controller or setting the context nodes as interface nodes in enhancement mode isn't possible...

Is this really a limitation or are there other ways to achieve this? Maybe there are other ways to pass data values from lower level embedded Components to higher level embedded components? But without violating the MVC principals.

Many thanks in advance!

Kind regards,

Miroslav.

System information:

Issue: enhancing interface controller or setting component controller context nodes as interface node
Usage: Web Dynpro for ABAP
System: SAP EHP 1 for SAP NetWeaver 7.0
SP levels:

- SAP_ABA 701 0006 SAPKA70106 Applicatieoverkoepelende component
- SAP_BASIS 701 0006 SAPKB70106 SAP-Basis-component
- PI_BASIS 701 0006 SAPK-70106INPIBASIS Basis Plug-In

What? Enhancing standard Web Dynpro Components

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Hi,

How about enhancing the (used) lower level WD component with an event and the (user) higher level WD component with an event handler method. Fire a custom event and listen to it in the main WDC.

Regards,

George

Former Member
0 Kudos

Hi dudes,

Parallel to this thread I've shot in a message to SAP with the question what the limitation on this one really means. Is it correct behavior or is it simply a bug.

The answer can be found in the following note, which is also really a fresh note!

There is the limitation that interface components cannot

be enhanced.

See also the note 1476699.

I hope your German is ok, since the last time I checked there was no English translation

Enjoy reading!

Cheers,

Miroslav.

ashish_shah
Contributor
0 Kudos

Hi Guys,

This is how i would approach it,

thanks to Thomas for suggesting a way out.

[ABAP Class using Singleton pattern - used in WDA Enhancements|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/20671] [original link is broken] [original link is broken] [original link is broken];

Regards,

Ashish Shah

former_member678355
Participant
0 Kudos

Hi,

I've actually been wrestling with this same dilemma for over a week. I'm a bit rusty on my Dynpro, so could you elaborate just a bit more on how to actually implement this new class? Where exactly do you instantiate this class in each of the 2 standard components?

Any info would be helpful! Thanks guys!

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

>I'm a bit rusty on my Dynpro, so could you elaborate just a bit more on how to actually implement this new class?

I've described the private instantiation, private attribute, and static, public factory method already. I'm not sure how much more I coulld tell you about these parts. Was there something specific?

>Where exactly do you instantiate this class in each of the 2 standard components?

You don't instaniate the class. You just call the Factory method which will have a returning parameter with an instance of the class. You can probably do this in the WDDOINIT of each component. They will then each be able to store an object reference back to the same instance of this class.

thomas_jung
Developer Advocate
Developer Advocate
0 Kudos

I would suggest that you create a normal ABAP class with a singleton pattern. The class itself has private instaniation. It then has a private attribute TYPE REF TO itself. You have a FACTORY static, public method that both components can call that will return the same object reference to a single instance of this class. This way both components basically have a shared memory area via this single class instance. You can use this to share data between the two components without having to enhance the interface structure of the Components.

You see this approach used increasing in standard SAP applications even when we could use component interfaces. This is a lighterweight approach since cross component context binding has the overhead penalty of having muliple copies of the context data in memory. This approach also better allows UIBBs implemented via feeder classes to be integrated with WD Components within the Floorplan Manager. So this is a well respected approach.

Former Member
0 Kudos

Hi Thomas,

Thanks man! It works indeed. I forget to think of the option indeed. It's so obvious since in many classes (i.e. the BL facades) SAP does the same

Cheers,

Miroslav.

ChrisPaine
Active Contributor
0 Kudos

Although I like this pattern (I've used it myself on multiple occasions) there is a risk in the further usage of this type - it is in the breaking down of the MVC paradigm and the loss of potential reuse.

Using context and WD interfaces clearly keeps the code in the VC part - transporting component information via unlinked singleton references makes it much harder to trace where the data is coming from/going to. The breakdown of what is the controller - and potentially even view data, becomes much harder to trace. I could imagine a formatting interface being exposed through the resulting instance interface - and the code for that formatting being called happily within the assistance class.

Although performance is of great importance, the ability (especially within custom developed and therefore not supported by SAP) of code to be easily understood and traced by support at a later point in time is probably more important. I have often had to knock back great ideas (sometimes my own because they were just too complex for the limited support staff at the site.

ChrisPaine
Active Contributor
0 Kudos

split post due to formatting issues...

The use of this pattern also may lead to restrictions on the usage of the components further down the track.

For example - I cannot imbed one FPM layout within another (I would like to be able to have the ability to have tabbed panel within my guided activity floorplan). This is because (partly not wholly) the FPM reference exists as a singleton - I can call the static public method to retrieve the current instance - but I can't have two different instances.

Another example - the decoupled infotype framework. When you instantiate this framework using the factory it will start up in one of two modes (legacy or non-legacy). If you start it once in non-legacy mode and then some FM, method, routine somewhere in you code attempts to get a legacy reference to the framework - kerboom nice little assert failed dump. Were multiple instances of the framework allowed to co-exist we wouldn't have this issue. (but we'd loose a lot of advantage to cached data etc.)

Now the FPM example is an extreme one, and I wouldn't advocate to change the DIF either (unless it was to write out all legacy use and reference (huge project)), but it should be carefully considered when using this pattern if there is a potential future use case for multiple instances of the same interface.

Sorry this probably doesn't help the case you were working on - but I thought it worth sharing my view (which is my own and not neccessarily correct!)

Cheers,

Chris