Keep your WebDynpro node mappings simple
The underlying motto of what I have written is to keep things simple and I feel that, one way of doing this is to keep the model node away from the view. I tried it in my recent work and found it useful and worth sharing.
According to the above mapping model the View contains the screen layout which forms the presentation logic. It should contain the value nodes and value attributes which would assist in the creation of the presentation. Try to avoid mapping the model nodes into the view.Instead map the model nodes and the value node into the controller and write methods which would help in copying the values from the model node to the value nodes and vice versa.
Now suppose there is any structural change in the backend and the deletion of the model becomes a necessity. Then you can go ahead delete the model and then create it again. As the RFC do not have any mapping with any other components other than the component controller you need to bother only about change in the method which copies the values to the corresponding nodes. Thereby reducing many overheads you might have to come across.
This method of developing WebDynpro application was helpful in creating small components (one view and RFC as backend) and change in the model would mean only that a change in the component controller is required. This was not however tested in big applications containing numerous screens which would load the component controller heavily. Also the methodology in the light of dynamic programming is also to be tested for.

Can you elaborate with an example method? I personally feel that it is not a very good idea to break the mapping chain(model->controller->view) and insert custom code, especially if the methods are custom coded for each instance. That is, the method implementation is not generic and depends on the structure of the node being handled.
Regards,
Harsh
Also: do you know (I believe you do), that value/model node divide is a bit artificial, and exists at design time only? At run-time you have homogenous API for all nodes (hmmm, actually there is just one type 😉
Also in early builds of NW 7.1 there is no such divide even at design time 😉
VS
As I have already said I have not tested the above method too much. I used it just in one of the recent works of mine.
The work I did was,
I need to display a table, data comes from the RFC. I created the table by binding the table UI with the value nodes and in the controller, I wrote the function copying values from the model node from the RFC to the value nodes.
Later due to change in the RFC a re-import was necessary. Even the re-import was not working (even after the server restart )and I ended up re creating the model. Other than changing the method in the controller and a simple mapping to the controller, it did not affect the view.
I tried this because I have seen in may forum posts that they never wanted to delete the model just because the re-mapping was a complex work. So I felt that it was better to isolate the view from the back end model.
Regards,
Noufal
I have more often required to break the model -> controller ->view mappings than not,Several use cases have presented where model node object graphs are not appropriate for a UI control, Eg:Data in tables need to be populated to recursive node for a tree element, or if I had to use calculated attributes, or if a table control was used for both read and write.However I also use the WDDCopyService to do mass transfer of data wherever possible.
"Several use cases have presented where model node object graphs are not appropriate for a UI control." In such cases I totally agree that there is no choice, you need to do some sort of processing on the data coming from the model to make it suitable for the UI. However I was refering to the cases where a direct mapping would suffice. There again I could be wrong, but I've used direct mappings in such cases.
Also Pran/Gary can you tell us a bit more about the WDDCopyService and an instance where one should use it.
Thanks & Regards,
Harsh
PS: Did anyone get what Valery was saying about the "value/model node divide"? 🙂