Advantages / disadvantages of Web-Dynpro

Hello,
Can somebody tell me, what are the advantages and disadvantages of Web-Dynpro unlike JSPs?
Best regards

Hi ,
Check the links
Advantages of webdynpro
Why WebDynpro ?
Web Dynpro V/s other web technologis
Regards
Rohit
Message was edited by: Rohit Radhakrishnan

Similar Messages

Differences between compiling a VC model with Flash or Web Dynpro

Hello forum,
Is there anyone capable of telling me what are the main differences between compiling a Visual Composer model with Flash compiler or Web Dynpro compiler.
I've noticed that some important features aren't available when I use the WD compiler, such as creating a popup directly from the output of a table and I can't install a scroll bar to navigate through the table records (it only allows me to place some navigation buttons in the bottom of the table, and this is not a very user-friendly solution).
If you were me, would you choose the Flash compiler?
By the way, do you know a way to increase the performance of a report created with VC? When I execute the iView on the Netweaver Portal, I see that a iview compiled with Webdynpro consumes less 15MB of memory when running the report than a similar iview compiled with Flash.
Thank you.
Regards,
Ricardo Inácio

I found this old post while searching for something else. The main difference between Flash and Web Dynpro modes is that Flash works and Web Dynpro most emphatically does not. Some of the (many) disadvantages of Web Dynpro mode.
1. It will not let you design your own screens. The designer will let you resize and position your fields thus giving you the illusion of being in control, but at runtime it will resize your fields and position them where it thinks fit. This greatly increases development time since you can never be sure what any changes you make to your screen will look like until you run it.
2. You cannot include horizontally and vertically aligned fields in the same form; depending on the option you choose it will align them all vertically or horizontally. Which means that if you do need eg a horizonal row of pushbuttons at the top of your screen followed by a set of vertical fields, you have to use a separate form for each.
3. You cannot use the Editing mode = Read-only mode to make all the input fields in a form non-entereable. You can select it in the designer,but at runtime it doesn't take a blind bit of notice. The only way to make a field non-enterable is to check the Disabled box which turns it a very pale and almost invisible grey which looks awful.
4. You can't change the font or colour of texts.
5. Lots of the controls are not available eg the clock.
6. You cannot create toolbars on forms, or rather you can but at runtime it just ignores them.
7. Adding a hyperlink to a pushbutton does not do anything (this is my latest discovery).
All of the above work in Flash mode. We have to use Web Dynpro because we need the screens to work with screen readers for visually impaired viewers, but anyone who does not have this constraint should avoid using it like the plague.

Advantages and dis advantages of web dynpro java

Hi Guys,
May i know what are the advantages and dis advantages of web dynpro java?
Regards,
Madhu

Hi Madhu,
Web Dynpro (WD) is a proprietary web application user interface technology developed by SAP AG and exists in a Java (Web Dynpro for Java, WDJ or WD4J) and an ABAP (Web Dynpro ABAP[1] , WDA) flavor. Both have in general the same functionality, but usually one flavor is improved after the other, so temporary one flavor is more advanced than the other. Hence, the decision for one of the two flavors shall be based on organizational and business circumstances, but not on functionality.
WD follows an adapted MVC pattern and a model driven development approach ("minimize coding, maximize design") with a large number of dedicated hooks in generated code to place custom coding. It is intended for business applications that shall follow standardized UI principles, connect to backend systems and be scalable.
Main advantages of Web Dynpro over other technologies
typed access for design time checks, e.g. navigation links and messages are accessed via types instead of string keys like in JSF
diverse services for backend access, like aRFC, JEE and Web Service data models
integration with SAP Interactive Forms by Adobe, which are interactive PDF forms, during design (same IDE) and run time (data sharing)
integration with business process management and business rules management (since NetWeaver CE 7.1 EHP 1)
designed to support development big scale applications by adding multiple grouping layers on top of Java packages (DCs, SCs, products)
runs on different clients e.g. web browser, mobile device, widget engine
comes with a big collection of UI elements providing a wealth of functionality and only have to be configured but not programmed
Main disadvantages
proprietary, running only on SAP servers
less flexible due to support for multiple clients (i.e. custom html is not possible). To reduce the limitations, several measures have been taken. For example, WD supports so-called "islands" for e.g. flash applications that enrich the Web Dynpro UI element collection by rich UI elements. This disadvantage doesn't seem so serious but in fact basic features that user expect to receive cannot be implemented (e.g. coloured rows in table, colours in general, advanced aligning of simple UI elements (due to nonexistence of more complicated ones), selecting multiple rows in tree-like tables (this is due to preserving basic concept of WD) and many more). Having the flash feature means that developer completely avoids WD UI (And thus cannot use other features).
rendering speed in browser for larger tables (>1000 rows)
The designtime and runtime environment is part of SAP NetWeaver 7.0[2] (also known as Netweaver 2004s) and following releases.
The name comes after the original Dynpro library, whose name meant "Dynamic Program".
Regards,
Pradeep Kumar

Difference between Web Services and RFC (both Advantages & Disadvantage)

Hi All,
will you please explain the difference between Web Services and RFC (both Advantages & Disadvantage)
Thanks,
jyothi.

Hi,
If you want have a communications between SAP systems within a network, we can go for an RFC.
If you want have communication between SAP systems through a medium like internet, we can probably go for a webservice.
Please refer the following links:
What is the difference between RFC vs. Web service ?
Webservice
If you want to convert an RFC fuction module to an webservice, you can refer the following link,
Using RFC as WebService in WebDynpro
Hope this will help you.
Regards,
Jithin

Advantages of web dynpro java

Hi,
Can any one tell me what is the difference between web dynpro java and visual composer?
And how web dynpro java is avantages over the visual composer?
Regards,
H.V.Swathi

Hi,
Please go through the links
What is Visual Composer? User Guide
http://help.sap.com/saphelp_nw04/helpdata/en/01/4b7e40417c6d1de10000000a1550b0/frameset.htm
SAP NetWeaver Visual Composer - How to Guides
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/16244247-0a01-0010-3294-d81c21e7e86e
Creating Applications Using SAP NetWeaver Visual Composer
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/2456bf8a-0a01-0010-709a-ffc91ade9f42
How to Model Portal Content Using SAP Visual Composer u2013 No Programming Required!
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ff65b5a2-0a01-0010-5b97-e747192a1d49
Troubleshooting VC:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/8ee70a47-0a01-0010-d198-f94c2d7d320c
VC e-Learning:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5a35194b-0a01-0010-7598-a4bb10e0c5c9
VC
https://www.sdn.sap.com/irj/sdn/visualcomposer
Webdynpro Tutorials
http://help.sap.com/saphelp_nw70/helpdata/en/52/4c6c3e58d0d064e10000000a114084/frameset.htm
What is Web Dynpro? What is Web Dynpro?
Why WebDynpro ? Why WebDynpro ?
Benifits of using Webdynpro Benifits of using Webdynpro
Hope This helps
Santosh

Web Dynpro JAVA VS. Web Dynpro ABAP

Hi,
I'm interested in advantages and disadvantages of WD JAVA & WD ABAP. Could anybody give me some "detailed" information about it?
We need any information you can give us.
regards,
Sharam

Hi,
Web Dynpro for ABAP:
Web Dynpro for ABAP or Web Dynpro for ABAP (WD4A, WDA) is the SAP standard UI technology for developing Web applications in the ABAP environment. It consists of a runtime environment and a graphical development environment with special Web Dynpro tools that are integrated in the ABAP Workbench (SE80).
The use of declarative and graphical tools significantly reduces the implementation effort
1) Web Dynpro supports a structured design process
2) Strict separation between layout and business data
3) Reuse and better maintainability by using components
4) Automatic operation of the Web Dynpro application using the keyboard
5) User interface accessibility is supported
6) Full integration in the reliable ABAP development environment
for more see:
http://help.sap.com/saphelp_nw2004s/helpdata/en/77/3545415ea6f523e10000000a155106/frameset.htm
Web Dynpro for Java:
Web Dynpro is a client-independent programming model of the SAP NetWeaver technology platform for developing user interfaces for professional business applications. It is based on the model view controller paradim which ensures that the business logic is separated from the presentation logic. This architecture is visible in the Web Dynpro perspective of the SAP NetWeaver Developer Studio (NWDS).
Web Dynpro helps you with the development of Web applications by:
1) Ensuring platform-independence with the meta model approach
2) Minimizing the implementation effort through declarative programming
3) Supporting a structured design process by applying the model view controller paradigm
4) Providing reuse and better maintainability by using components
5) Providing graphical support with tools in the Web Dynpro perspective
6) Providing the SAP NetWeaver Java Development Infrastructure (NWDI) which supports team work with different services such as source code versioning and the Central Build Service.
for more see:
http://help.sap.com/saphelp_nw2004s/helpdata/en/15/0d4f21c17c8044af4868130e9fea07/content.htm
The concept of Web Dynpro ABAP is identical with Web Dynpro Java and offers more or less the same functions
hope it helps
regards

Web Dynpro V/s other web technologis

Hi to all,
We are working currently on a system that uses BAPI call from ASP.Now planning to design new web applications using WebDynPro.Could anyone pls let me know how we can track the advantages/disadvantages or possible benifits from comparing current system.Also we are trying to minimize the usage of BAPIs from Web DynPros.Is is possible??Pls advise..
Thanks in advance
Regards
Vipin B

Hello Vipin B,
Check this first http://www.sappro.com/downloads/OptionComparison.pdf
And some material about dynpro itself and comparison of different available technologies:
http://help.sap.com/saphelp_nw04/helpdata/en/a5/1a1e3e7181b60ae10000000a114084/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/15/0d4f21c17c8044af4868130e9fea07/frameset.htm
http://help.sap.com/saphelp_nw04s/helpdata/en/bd/48fc3f8fc2c542e10000000a1550b0/frameset.htm
/people/thomas.jung3/blog/2005/10/02/sap-teched-2005-boston-a-look-back
POLL: Web Dynpro UI elements - enhancement proposals POLL: Web Dynpro UI elements - enhancement proposals
Web Application Development certification Web Application Development certification
Information on some terms used in Web DynPro Information on some terms used in Web DynPro
Brand New to Webdynpro Brand New to Webdynpro
What is with the "Web Dynpro project diagram"? What is with the "Web Dynpro project diagram"?
New to Web dynpro New to Web dynpro
What is Web Dynpro? What is Web Dynpro?
Why WebDynpro ? Why WebDynpro ?
Why webdynpro and not BSP or JSP? Why webdynpro and not BSP or JSP?
BSP to WEB Dynpro BSP to WEB Dynpro
Benifits of using Webdynpro Benifits of using Webdynpro
Advantages of webdynpro Advantages of webdynpro
Java vs. ABAP Java vs. ABAP
regarding Java related webdynpro regarding Java related webdynpro
Web Dynpro vs. Struts - a few questions Web Dynpro vs. Struts - a few questions
What kind of applications are being developed with Web Dynpro? What kind of applications are being developed with Web Dynpro?
Best regards, Maksim Rashchynski.

BSP - Web Dynpro - Interactive Forms by Adobe - Flex

Hi,
I am a student SAP from Belgium.
I am currenty developping an application and I am using BSP's, Web Dynpro's, Interactive Forms and Flex.
I have a good idea regarding to what the possibilities are of each User Interface, but I would like your opinions:
What are the main advantages/disadvantages of each of the named User Interfaces?
So what's good/not good about BSP, Web Dynpro, Interactive Forms, Flex?
What's the easiest to code, to make a layout,....
I know, according to the sitiuation, you can choose which UI to use, but I would really like to know what your opinions are about coding, easy-to-use, speed, logic,... (PRO/CONTRA'S)
Thanks a lot for your input, it would really help me!
Greetings,

Hi Mahamed,
I got your problem. You have not done anything wrong.
It is WebAS version which is not supported for this functionality.
But there is solution to this problem
Please refer to the SAP Note number - 1055738.
I think you will get the answer and the scenario described there will match your requirement.
This is a know issues with WebDypro ABAP but this works fine for Java Web Dynpro.
I have also tried for 2 months but finally came to know about it.
Regards
Satya

Accessing portal dictionary tables from Web Dynpro project

Hi
Am a new to whole portal and webdynpro thing, and I hope that you can help here
I created a new dictionary project through NWDS and created a table with columns and I successfully deployed it
I also created a web dynpro project and I added a TABEL UI to the layout
how can I connect or access the table I created in the dictionary project from the Web dynpro project so I can query all data to fill the TABEL UI in the web dynpro ?
is there a driver that I can use like JDBC where I can just write regular SQL queries ?
regards

Hi swathi
See the persistence API--Adv and Disadvantages what ever you mentioned come under the persistence API
Relational Persistence
=================
SQL-based coding: expressive!
SQLJ: for static SQL, checked at design time,
recommended
JDBC: for dynamic SQL, can be combined with SQLJ
=======================
Object-relational Persistence
======================
SQL-free! Portable!
JDO: light-weight object persistence, Java-like dynamic
query language
EJB CMP: part of J2EE standard, relatively heavy-weight,SQL-like static query language
Regards,
Venkata Kalyan Karanam

How do i pass parameters to a web dynpro application ?

Hi all,
how do i best possible pass (serverspecific) parameters to a web dynpro application ?
i wrote a web dynpro application that, among other things, sends an email and stores files on a server directory. Therefor i need parameters like e.g. "mailhost" or "directory".
The way i chose is to make a *.properties file. But from my point of view there are some disadvantages.
1) When i deploy the WD App to a new server, i have to edit the properties file before. I don't know how to do that. Do i have to edit the *.properties file again, before i make a new ear-Archive with NWDS ?
2) When the properties a wrong or change for a deployed app, i have to restart the J2EE Engine. Thats not convenient for a production server.
Is there a better way ?
Thanks
Andreas
(And I promise to return and reward the answers)

Hi Andreas,
You can't use something like portalapp.xml because this is not supported by webdynpro, but ... you can add this parameters at the end off the webdynpro address line. like http://<host>:<port>/webdynpro/dispatcher/local/<Webdynproproject>/<webdynproApplication>?host=yourhost
In your application you can get these variables:
String host = WDWebContextAdapter.getWebContextAdapter().getRequestParameter("host");
when you create a webdynpro iview you can specify the default value for the variables in the URL in the properties of the iview and i think you can personalize them later.
kind regards,
Joachim

Using EJBs in Web Dynpro

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Thanks for your reply and your suggestion. I have posted in the Web Dynpro Java forum... and suggest those wishing to participate in this thread to refer to the Web Dynpro Java forum.
As for your answer, I'm afraid it doesn't satisfy me.
Reuse is hardly an issue, since the CommandBean is specifically tailor-made for the Web Dynpro application that needs to use it. I could hardly imagine building another application that would just happen to have the exact same needs as far as data structure and processing is concerned...
As for the right Eclipse environment... the CommandBean is not an EJB artifact - it is an EJB client. The aforementioned tutorial in fact suggests creating it in the Java perspective.
But thanks anyway for your time and suggestion

Using EJBs in Web Dynpro Applications

I have recently started to develop Web applications using the Web Dynpro framework. Coming from a pure J2EE world, I must admit that Web Dynpro has a few innovative features that I find interesting for user interface development. The use of component & view contexts, for example, is not unlike the ActionForms that one may find in a Struts application, but pushed a bit further. No complaints here.
What I do have some problems with is the whole CommandBean paradigm that is put forth by SAP (refer to the document <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/webdynpro/using%20ejbs%20in%20web%20dynpro%20applications.pdf">Using EJBs in Web Dynpro Applications</a>).
I do understand the usefulness of defining a model that will be used to generate and eventually bind to Context data structures. That's fine. What I do object to is the use of a so-called CommandBean to play that role. Again, coming from a J2EE world, I am familiar with the BusinessDelegate pattern - which would typically be used by a client application to invoke business logic on the server side. I would propose that a better, cleaner way of integrating EJBs with the Web Dynpro framework would be to use a BusinessDelegate for invoking business logic, and importing a separate and distinct ModelBean (instead of a CommandBean) to be used for defining and binding to Context data.
I have built one Web Dynpro application thus far. Instead of using a CommandBean, I created a ModelBean that extends my business object DTO (Data Transfer Object) (which is quite appropriate for that role, given that it implements all the get & set methods that are required for the business data that I need to model). My Web Dynpro application also makes use of an independant BusinessDelegate that is packaged with my EJB DC - this is a standard best practice on J2EE projects. I have been asked by the people working with me to modify this architecture to bring it more in line with the SAP way of doing things. I am open-minded and willing to learn and accept new ways of thinking and doing things. However, I fail to understand the usefulness of merging structure and behaviour by resorting to CommandBeans:
- It violates the MVC paradigm by having one object (the CommandBean) serve as both model AND controller as far as the Web Dynpro application is concerned. The CommandBean is obviously a model - since it is literally imported as such into the Web Dynpro application. It is ALSO a controller from the Web Dynpro's application perspective, since all calls to the back-end go thru the CommandBean via one or more of its execute_xxx methods. In contrast, the use of a business delegate by the Web Dynpro application clearly separates the model (the CommandBean... or rather, a more suitably named ModelBean) from the controller (BusinessDelegate).
- Doesn't carry its own weight. In other words, I haven't yet been provided with any valid justification for going thru the extra effort of coding the CommandBean's execute methods. It's been proposed to me that it somehow serves as an abstraction layer between the Web Dynpro application and the business logic. I would argue that it is the BusinessDelegate's role to abstract away the back-end logic from clients. If one does have a BusinessDelegate available, I would argue there's no need to code execute methods in a separate CommandBean. To prove my point, I would simply point out that all of the CommandBean examples that I have seen so far, either in How-To documents, or in production code, all follow the same pattern....
CommandBean.execute_doSomething() calls BusinessDelegate.doSomething()
Not a heck of an "abstraction" layer... I would in fact argue that it is worse than useless. If some major change occurs in the business logic that requires changing the doSomething() operation, we expect of course to modify the BusinessDelegate. The Web Dynpro client will also presumably need to be modified - that's to be expected, and unavoidable. But then, we'll also need to go about and change the CommandBean's execute_doSomething() method - again, extra work for no apparent benefit. Adding and removing business methods has the same implication. All this for an layer that simply adds the prefix execute_ in front of all business method calls... Is this "abstraction layer" worth the cost of creating and maintaining it ??
- Unnecessarily complicates error handling. I have been told that for technical reasons, it is recommended that all exceptions thrown by the CommandBean be of type WDException or WDRuntimException. But what if the client application needs to react differently to different failure scenarios ? When I create a business object, I might wish to provide the user with an error messages if connection is lost to the backend, and with a different error message if an object already exists in the database with the same attributes. In order to do that, I will have to catch the WDException, extract the cause, and continue processing from there... possible, yes, but clearly less standard and more labor intensive than the classical try/catch mechanism.
To say nothing about the fact that SAP's own API documentation clearly states that applications using Web Dynpro can reference and catch WDExceptions, but THEY MUST NOT THROW OR EXTEND IT !
- Produces unnecessary DCs. Page 6 of the aforementioned document presents an architectural view of a Web Dynpro project that uses a CommandBean. Why an extra DC for the CommandBean ?? I created my ModelBean class right inside the Web Dynpro project (in the Package view). That, to me, is where this class should reside, because it is created for no other reason that to be used by this particular Web Dynpro application. What is the benefit of placing it in its own independant DC ?
- Not a typical application of the Command pattern. The well-documented command pattern (Design Patterns - Gang of Four) has been devised mainly to enable encapsulation of request as objects, thereby making it possible to:
- specify, queue and execute requests at different times
- decouple execution of a command from its invoker
- support undo operations
- support logging changes so that they can be reapplied in case of system crash making it possible to assemble commands into composite commands (macros), thereby structuring a system around high-level operations built on primitive operations.
None of this applies to the way the SAP CommandBeans are being used. Not that much of an issue to people new to J2EE and/or OO development... but quite confusing for those already familiar with the classic Command pattern.
At this point, I fail to understand the advantage of merging structure (model) and behaviour (execute methods) through the use of a unique CommandBean object. Am I missing something ?

Hi Romeo,
You would be disappointed, this reply ain't anywhere nearby to what you are talking about...
I wanted to mail you, but you have not mentioned your email in your profile.
I am really impressed by your flair for writing. It would be far better had you written a blog on this topic. Believe me, it would really be better. There is a much wider audience waiting out there to read your views rather than on the forums. This is what I believe. To top it, you would be rewarded for writing something like this from SDN. On the blogs too, people can comment and all, difference being there you would be rewarded by SDN, here people who reply to you would be rewarded by you. Doesn't make much a difference.
Anyways the ball is still in your court
As far as I am concerned, it has still not been much time since I have started working on Web Dynpro. So can't really comment on the issue...
Bye
Ankur

Difference between ITS and web dynpro abap

Hi Experts.
Can any explain me what is the main difference between EWT/ ITS and web dynpro abap. Basically i am going to developed some existing EWT in webdynpro ABAP , so i want to know what are the advantage of WD ABAP over ITS .
Thanks in Advance.
Satya

Closing thread, thanks for your help.
Thanks,
Satya

In web dynpro i want explanation/definition for the following things

Hi dudes,
I want explanation *** definition for the following
(1) web dynpro
(2) Cardinality
(3) methods
(4) Nodes
(5) Attributes
(6) Interface
(7) Views
(8) Windows
(9) Mapping
(10)Binding
(11)Model
(12)Controller

Hi,
Here are the defintions for the terms you hav requested-
Web Dynpro Architecture
Definition
Web Dynpro is the SAP NetWeaver programming model for user interfaces (UIs).
The Web Dynpro model is based on the Model View Controller paradigm, and has the
following features that build on the classic dynpro model:
Clear separation of business logic and display logic
Uniform metamodel for all types of user interfaces
Execution on a number of client platforms
Extensive platform independence of interfaces
Web Dynpro provides support for developing Web representation of a business application.
You use specific tools to describe the properties of a Web Dynpro application in the form of
Web Dynpro metadata. The necessary source code is then generated automatically and
executed at runtime. In addition to the events offered by the framework, you can also define
your own events for a Web Dynpro application. However, the event handling must always be
programmed in separate source code areas which are executed automatically when the event
is triggered at runtime.
In Web Dynpro, each user interface is always made up of the same basic elements. These
elements of the metamodel can be statically declared using Web Dynpro tools.
It is also possible to implement elements of the metamodel at runtime and to change them or
reintegrate them at runtime. Using these implementations, you can make any changes or
enhancements to a user interface that has been created by declarative methods by
generating new interface structures at runtime.
This means that you can combine declarative processes and the implementation of source
code.
A Web Dynpro component is a reusable entity. It summarizes all components that are
required as part of this programming unit for an executable Web Dynpro application.
The Web Dynpro component concept offers a number of advantages:
Structuring of the programming
Creation of easily manageable application blocks
Reusability of whole components
Decoupling of software projects in both time and space
The Web Dynpro component contains any number of windows and views and their
corresponding controllers. Additional Web Dynpro components can also be referenced.
View
A view describes the layout and behavior of a rectangular area of a user interface.
Every Web Dynpro application has at least one view. The layout of a view is made up of
different user interface elements, which can be nested in each other. The positioning of
interface elements in one view is supported by the supplied layout variants.
In addition to the visible part, the layout, a view also contains a controller and a context. The
data to which the elements of the view can be bound are stored and managed in the view
context, enabling them to be represented or used on the screen. The view controller can
contain methods for data retrieval or for processing user input.
Window
A window is used to combine several Views and View Sets (the concept of view sets is only
offered in Web Dynpro for Java). A view can only be displayed by the browser if it has been
embedded in a window. A window always contains one or more views, which are connected
by navigation links. One of these views, or a view set, is specified as the start view and is
displayed the first time the window is called.
Windows have inbound and outbound plugs.
Inbound Plugs and Outbound Plugs
A window has one or several inbound or outbound plugs. Using these plugs, a window can be
included into a navigation chain. The concept of these plugs corresponds to the concept of
the plug for a view. Each plug of a window is visible within the entire window and can be used
for navigating within this window. In addition, one or several plugs can be made accessible to
the component interface so that they are visible even beyond the limits of the component in
question. They thus belong to the interface view of the relevant window.
They are used to navogate from one view to other and pass the data between the views. Which view to be called next from current view - the flow of views is descriebd here using Plugs.
Controller
Controllers are the active parts of a Web Dynpro application. They define how the user can
interact with the Web Dynpro application. The data that a controller can access is defined in
the corresponding context. Different instances of controllers and contexts exist within a Web
Dynpro application.
View Controller
Each view has exactly one view controller, which processes the actions performed by the user in the view.
A view also has exactly one view context, which contains the data required for the view.
Interface Controller
Each Web Dynpro component contains exactly one component controller. This controller is a
global controller that is visible also outside the component. It is thus part of the interface of a
Web Dynpro component.
Context
Definition
The data used in the component or in the view are stored in the context. Read-write access to
this data is available using the controllers as a starting point.
Structure
The data from the contexts is managed in a hierarchical structure. Each context has a root
node, underneath which the individual data fields (attributes) are stored in a tree structure.
You create this tree structure according to the structure of your application.
CONTEXT is generally called as a ROOT Node.
Each context has nodes and attributes also.
Cardinatlity
Each node contains data fields that represent one of the following:
u2022
An individual instance of an object type
u2022
A table of instances.
This property of a node is known as its cardinality. The following table summarizes the
possible cardinalities for a node:
Cardinality Description
1:1 The node contains only one element instance, which is instantiated automatically.
0:1 The node contains only one element instance, which must not be instantiated.
1:n The node can contain multiple element instances, of which at least one must always be
instantiated (and is instantiated automatically).
0:n The node can contain multiple element instances, of which none have to be instantiated.
Further information about this and other properties of context nodes is available in the section
Context-Nodes: Properties.
Recursion Nodes
Dynamic node nesting is possible within a context, creating what is called a recursion node.
The node that is used for recursion is always a predecessor of the new node. The newly
created recursion node is a reference to a predecessor node and therefore cannot be
processed separately. Instead it takes on the structure of the node to be repeated.
Data Binding and Mapping
Within the Web Dynpro architecture, the contexts of the different controllers can be linked in
different ways:
u2022
A UI element of the user interface of the view can be linked with an element of the view
context.
u2022
A mapping can be defined between two global controller contexts, or from a view
context to a global controller context.
The context of a global controller can be linked to a Web Dynpro Model.
Defining Mapping Between Two Contexts
The elements of a view context can be locally defined. In this case (represented in the graphic
below as a "Local Node"), all the contained attributes are only visible within the relevant view.
When the view disappears, the attribute values are deleted.
Event
The component controller allows you to create events.
Events are used to communicate between controllers and enable one controller to trigger
event handlers in a different controller.
Cross-component communication can be implemented using the interface controlleru2019s events.
Events that were created in the component controller are visible within the component only.
Inbound Plugs
Inbound plugs in a view also react like an event. Therefore, when a view is called using an
inbound plug, the event handler that is optionally available for the inbound plug is always
called first. In this case event handling takes place within the current view controller.
UI Element Events
Some UI elements, such as the Button element have special events that are linked with user
actions. These events are predefined and have to be linked with an action at design time.
Actions for UI Element Events
Some UI elements such as the button element can react to a useru2019s interaction: clicking on
the corresponding pushbutton can trigger a handling method to be called within the view
controller. Such UI elements are equipped with one or several general events, which can be
linked with a specific action at design time (switching to a subsequent view, for example). If
such an action is created, an event handler method for this action is created automatically. In
this way, you can equip a UI element event (which has been inserted several times into a
view) with different actions as necessary. The event is then processed by the corresponding
event handler depending on the action that is linked.
Interfaces of Web Dynpro Components
Each component has an interface in order to enable communication between Web Dynpro
components and to enable a component to be called up by a user. This interface consists of
two parts:
Interface View of a Window Contained in a Component
The interface view of a Web Dynpro window is used to link a window with a Web Dynpro
application that can be called by the user.
Reward if helpful.
Best Wishes,
Chandralekha

ABAP Objects and Web Dynpro

Hello everyone,
I would like to know if it is possible to have instances of a class as a part of a controller context. You know, like if you added a service call to a BAPI or a function group, but with method calls to an object instead.
I have a feeling, that it is uncommon to bring Web Dynpro and the object orientation of ABAP Objects together.
For example, i don't want the event handling code of my controllers to call function groups, which in turn make calls to my object oriented model. Is there a way to skip that nasty imperative step?
Sorry for asking questions which may sound vague or naive, I'm kind of a beginner regarding Web Dynpro and ABAP.
cheers,
Jens Barthel

There's no need at all to have function modules in the way.
You can have either controller attributes or context attributes defined as object references, and then call methods from those objects instead...
In both cases, you just have to use TYPE REF TO instead of TYPE when defining the attributes.
Furthermore, if you have a central class through which you interact with your OO model, you can define it as Assistance class and then you'll have an instance automatically in all the controllers...the drawback / advantage is that you do not control its instantiation which is done by the framework.
Regards
Edited by: Alejandro Bindi on Oct 14, 2008 6:23 PM

Advantages / disadvantages of Web-Dynpro

Similar Messages

Maybe you are looking for