cancel
Showing results for 
Search instead for 
Did you mean: 

Componentization

Former Member
0 Kudos

Dear all,

I attented a session @ SAP TechEd in Munich about componentization and I've also read some articles about it. I have a few questions though:

1. In the examples people still use the context at the interface level. However, i've read somewhere that in a future release (i think the 7.1) the interface will be more like Java interfaces... meaning only methods and no context anymore. The interface can then trigger the same method in the component controller that does whatever it needs to do (Bind something to the context maybe)

2. When using one or more child components in a root component, what is the preferred way for handling errors? Do the childcomponents just report their errors to their message manager, or do the messages need to be given to the parent component so he can handle then as desired?

3. When using a model in more than one component, what is the real benefit of using the reference mode? Is it a must?

4. Suppose i have a browser (for orders for example) screen and from that browser screen I can go to the details of an order, or to creating a new order... In this scenario there can be three components defined:

comp1 browser

comp2 order details

comp3 new order (comp2 and comp3 can be one comp maybe when they show the same data)

For these three components, a root component can defined that uses the three component. Does this mean that for every action you can do in comp1, comp2 or comp3 an event should be fired which can be handled by the root component? For example the "save" button in the details, should the saving code be in comp2, or should comp2 just fire an event and give the "order to be saved" to the parent so he can save it the way he wants?

Kind regards,

J.

Message was edited by:

Joren Crauwels

Accepted Solutions (1)

Accepted Solutions (1)

former_member181883
Active Participant
0 Kudos

Hi Joren

> 1. In the examples people still use the context at the interface level.

> However, i've read somewhere that in a future release (i think the 7.1) the

> interface will be more like Java interfaces... meaning only methods and no

> context anymore. The interface can then trigger the same method in the

> component controller that does whatever it needs to

> do (Bind something to the context maybe)

You should never put any business logic directly into a Web Dynpro Interface Controller. Not only is this poor OO design, you are correct about the changes coming in NW 7.1

In NW 7.1, any time you wish to give a Web Dynpro component a public method, you would declare the method's signature in the Interface Controller, but provide the implementation in the Component Controller.

Therefore, if you have been bending the rules in NW 7.0 and implementing business logic directly in the Interface Controller, then you will have a significant amount of rework to perform during the 7.1 upgrade.

In NW 7.0, the only coding that should really occur in an Interface Controller is that required to call a method of the same name in the Component Controller.

> 2. When using one or more child components in a root component, what is the

> preferred way for handling errors? Do the childcomponents just report their

> errors to their message manager, or do the messages need to be given to the

> parent component so he can handle then as desired?

This depends on how serious the errors are and whether you need to take a global approach to error management or not.

If errors need to be reported up to the root component, then the child components must raise events to which the root component subscribes. Then the parent (or root) component can perform error processing during the wdDoBeforeNavigation() or wdDoPostProcessing() methods.

This topic is covered in the new edition of my book "Inside Web Dynpro For Java" section 11.3 page 376.

> 3. When using a model in more than one component, what is the real benefit of

> using the reference mode? Is it a must?

It sounds like you are confusing two different things here. If two components both need to create an instance of the same child component, then it is possible for both parents to share a reference to the same child component instance. This is

known as using a child component "in referencing mode".

Using referencing mode is not mandatory, but it can help reduce the runtime size of your application. You should be careful when using referencing mode because either parent component could issue a statement to delete the child component instance. This could potentially leave one of the parent components with an invalid child component reference.

If two (different) components need to use the same model object, then both will share the same model object instance as long as the model's scope type is left at the default value of APPLICATION_SCOPE.

> 4. Suppose i have a browser (for orders for example) screen and from that

> browser screen I can go to the details of an order, or to creating a new order...

> In this scenario there can be three components defined:

> comp1 browser

> comp2 order details

> comp3 new order

> (comp2 and comp3 can be one comp maybe when they show the same data)

> For these three components, a root component can defined that uses the three

> component. Does this mean that for every action you can do in comp1, comp2

> or comp3 an event should be fired which can be handled by the root component?

Certainly not. This would make the component interaction excessively complex.

Remember that a component should be a reusable unit of business functionality. Therefore, it should be entirely able to process its own events raised from the views it contains.

> For example the "save" button in the details, should the saving code be in

> comp2, or should comp2 just fire an event and give the "order to be saved" to

> the parent so he can save it the way he wants?

No, because then comp2 would not be reusable without a parent component being available to handle the events it raises. These events (such as "save the order I've just changed") are critical to the business process; therefore, the functionality should be contained within a single component.

As I said during the session at TechEd, when designing components and considering how much functionality they should contain, always consider reuse. If you are making a decision that means the component cannot complete its step of the business process, then you are breaking the reuse case and therefore breaking the design.

Regards

Chris Whealy

Former Member
0 Kudos

Hi Chris,

Thanx alot for the information.

So assuming that i have a "new order" and a "change order" button in my browser component, firing a newOrderEvent or changeOrderEvent at clicking the button would be a good approach?

Kind regards,

J.

former_member181883
Active Participant
0 Kudos

That's one way to do it, but it would be much easier if when you pressed a "New Order" or "Change Order" button, you simply called a method in the interface controller of the respective child component.

Regards

Chris W

Former Member
0 Kudos

Isn't this call to a method of the respective child component only possible when my Browsercomponent is using my orderdetailscomponent?

The solution with the events would be where a separate root component is using Browsercomponent and OrderDetailsComponent...

Or am i seeing thing wrong?

Regards,

J.

former_member181883
Active Participant
0 Kudos

There are potentially two calls going on here:

1) Within the scope of the child component, when a method in its interface controller is called, the implementation of that method does nothing more than make a call to another method of the same name in the component controller.

2) If a parent component wants to invoke functionality in a child component, it does so by directly calling a method call in the child's interface controller

It sounds like you are greatly over-complicating the situation. Do not try use eventing to get one child component to invoke functionality in another child component via a parent component. This is poor design.

Either have your Browser component acting as the root component and invoking functionality in the OrderDetails component as required, or create a root component to manage the functionality of the Browser and OrderDetails.

It sounds like you are wanting to go for the second option, but then you are complicating the situation by trying to get the two child components to talk to each other via events caught by the root. KEEP IT SIMPLE!!

You must write the root component in such a way that it contains all the necessary functionality to make the Browser and OrderDetails components work together - yet at the same time, neither of these two child components needs to know about the existence of the other.

Regards

Chris W

Former Member
0 Kudos

Thx again for the answer.

They way i was working so far was by using the DetailsComponent in the BrowserComponent, but i thought this wasnt the good approach because then you cant use the browser without the details component.

The RootComponent approach that uses browsercomponent and details component would be the most modular approach, but this means that when I select an entry in the browser component, the rootcomponent needs to subscribe to this event and then just call a method on the details component interface controller... But still, maybe this is too complex (too much routing between components) for what we gonna need it....

I think i just continue with my current approach... Browser contains Details and calls methods directly on interface of details.

Thx.

Joren

Answers (0)