cancel
Showing results for 
Search instead for 
Did you mean: 

WebDynpro Layout Question

0 Kudos

Hi everybody!

I just have the problem that I have two different web dynpro components and I need a data exchange between this two components after an event fired on one of those.

Is it the correct way to do that over the model? Or is it better to send the data with an event? One thing I have to think about that in future more components can be developed who needs this data. How can I do that best?

Bye Markus

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Well, it's a topic for tutorial what is a better option, but anyway some guidelines:

1. If you are sharing fairly large amount of data you need context mapping between components (as opposite to passing data via plug/event arguments)

2. If you need to perform visual navigation use plugs but avoid navigation via plugs where eventing is more suitable (notifications this doesn't lead to layout changes). WD Navigation has some nitty-gritty details these could surprise you when you try to apply it as eventing mechanism (rules when plug event handler is called is quite restrictive).

3. Use eventing from embedded components to achieve decoupling.

4. Use to define WebDynpro component interfaces for your components and refer to interfaces from embedder rather to concrete components. The benefits besides obvious decoupling include modularity & improved build time. You can define interfaces in one DC, embedder in other one, and split all your implementations among several others DC (grouping in this case is completely up to you -- by use case, by business objects to process, etc)

Hope this helps,

VS

0 Kudos

Hi Valery!

I have three different areas. A menu area (unfortunately I need a menu) from which I have to manage the other two areas. In this area different components can be displayed and both of them can manipulate the data. So my idea was to build up a common model where I manipulate the data. So each component gets the data from there. If I need to fill up data for a BAPI I would also take it out from this model. Does it make sense to do it this way? I am not even sure if I should work with different components or just work with views ...

Pretty new to all of this and it still keeps me confusing but just want to make for sure that I start on the wrong path

Bye Markus

Former Member
0 Kudos

It seems that you are choosing complex path where WD provides simpler.

Instead of custom models (BTW, what is it internally -- POJO???) you can use WD context mapping between components.

First, as far as you have several components on the same level you need something like Container component that embeds anything else (menu [MNU] & data processing components [DPC]). DPCs should define input nodes on their external component interface with necessary structure. Container should have custom controller with node that encapsulate your "model data", and have mappings between this node and component usages of DPC.

Regarding BAPI. If you are using Dynamic RFC, then you can apply the same technique as above with only difference that you have to use model nodes bound to generated Dynamic RFC model classes.

This way you get one centralized components that holds data (probably retrieve / store), and specialized components these manipulate data (probably retrieve / store). All data shared between DPCs due to WD context mapping "magic".

Next, handling events. If I understand you correctly, your menu trigger some navigation flow inside Container. So I'd recommend the following approach:

1. MNU fires event, and Container handle this event (event will have very primitive parameters, something like commandID)

2. In event handler Container you may map commandID to plug this will lead to navigation to specific DPC (assuming that navigation to all possible DPC was created at design time)

Regards,

VS

0 Kudos

Hi!

Thanks for your answer. I think now the way I have to go

Bye Markus

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Markus,

since you fire an event already, i suggest to transport the data via the event. This has the positive side effect of achieving a more loose coupling between the components as by context mapping. You could create a component C, which acts as a listener to the event firing component A and transports the received data to component B (and B2, B3...). Using this scenario, only C knows something about A and Bx while A and Bx are totally decoupled.

On the other hand, you have to do some more manual programming to transport the data from C to the receiving components. Well, it's like always, what you like most is what's fitting best

Hope that helps.

Regards

Stefan