Container definition for Abstract Synchronus Interface
I am trying the simple scenario where the bpm process consumes soap request message (opens S/A bridge). After it queries another web services and sends back synchronously soap response, closing S/A bridge.
I've walked through different weblogs and forum posts but still not getting how the interface variables should be created in this case.
All my abstract interfaces are synchronous, and container definition for category "Abstract type" is only for Asynchronous interfaces.
Should I create two additional asynchronous interfaces with the same request/response message names to be able create interface variables?
And if message names are different in both soap calls should I create 4?
Thanks,
Evgeni
scenario is similar to the one described in the weblog https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1403 [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken]
but without call to the legacy system and instead of JDBC it is another webservice.
Hi, thanks for replay,
>So this Abstract interface is used in the Receive step of the BPM(opening of the Sync/Async Bridge).
I've created Abs Sync interface and used it in the Receive step. My problem is I can not assign value to the Message Name in the step Properties.
To assign value I need first create container. To create container I need provide Type, which can be selected from the list of the "Message interfaces". But the list displays only Async Abs interfaces not Sync. How I should create container for Sync Request message?
Looking on the help link you provided. How I should create following:
Container
Request
BpmPatternBridgeRequest
Response
BpmPatternBridgeResponse
Kind regards,
Evgeni.
Similar Messages
-
Idoc as external definition for occurance change - interface use
Hello,
never used this.
Found this blog from Michael
/people/michal.krawczyk2/blog/2005/12/04/xi-idoc-bundling--the-trick-with-the-occurance-change
Question is...
When I import the Idoc as external definition then I need to add it into a message interface because it cannot be used
like original Idoc which is used as message interface?
Thank you in advance !
Best regards
DirkWhen I import the Idoc as external definition then I need to add it into a message interface because it cannot be used
like original Idoc which is used as message interface?
You dont have to use it in Message interface....the standard IDOC can be used in the Interface Mapping Directly....even Michal mentioned the same in the blog Step 6....in case you missed it.
Regards,
Abhishek. -
Requirement of a abstract message interface
Hello,
I wonder when to use abstract message interfaces?
The documentations says:
An abstract message interface has no implementation in an application system. You cannot generate a proxy for this interface type. You use abstract interfaces in business processes, for example, to receive or send messages from application systems. You can use the same abstract interface to receive or to send.
What does IMPLEMENTATION mean in this context? Can anybody discribe a concrete need for abstract message interfaces?
Thank YouHi Mario,
you only use those interfaces inside a BPM:
send step, receive step, transformations etc
(no other use)
- you cannot create proxies from it
- you must have an normal (not abstract) interface
to send data to XI or to receive data
(so once you create everything inside your integration process - with the use of abstract interfaces)
inside ID you still have to use standard interfaces
(outbound or inbound)
Regards,
michal
Message was edited by: Michal Krawczyk -
Help Solving: Does not contain a definition for 'Select'.....
Hi,
Need help solving a Task that returns a Task<IEnumerable<Writing>> so I can fill ObservableCollection<ViewModels.IWritingItemViewModel> Writings for my
Design Time Data Page:
<d:Page.DataContext>
<designTimeData:MainPageViewModel />
</d:Page.DataContext>
My constructor does this:
public MainPageViewModel()
var writings = this.GetGroupsAsync();
this.Writings = new ObservableCollection<ViewModels.IWritingItemViewModel>();
var viewmodels = writings.Select((x, i) => new WritingItemViewModel
Writing = x,
VariableItemSize = (i == 0) ? Common.VariableItemSizes.Writings : Common.VariableItemSizes.Normal,
My var writings = this.GetGroupsAsync(); is:
public async Task<IEnumerable<Writing>> GetGroupsAsync()
await this.GetMenuDataAsync();
return this.Groups;
which in turn gets data from:
private async Task GetMenuDataAsync()
Uri dataUri = new Uri("ms-appx:///DesignTimeData/MenuData.json");
StorageFile file = await StorageFile.GetFileFromApplicationUriAsync(dataUri);
string jsonText = await FileIO.ReadTextAsync(file);
JsonObject jsonObject = JsonObject.Parse(jsonText);
JsonArray jsonArray = jsonObject["Groups"].GetArray();
foreach (JsonValue groupValue in jsonArray)
JsonObject groupObject = groupValue.GetObject();
Writing group = new Writing(
groupObject["UniqueId"].GetString(),
groupObject["IsHeaderInteractive"].GetBoolean(),
groupObject["ViewType"].GetString(),
groupObject["ModelType"].GetString(),
groupObject["Page"].GetString(),
groupObject["Title"].GetString(),
groupObject["Subtitle"].GetString(),
groupObject["ImagePath"].GetString(),
groupObject["Description"].GetString(),
groupObject["GroupId"].GetString()
foreach (JsonValue itemValue in groupObject["WritingMenus"].GetArray())
JsonObject itemObject = itemValue.GetObject();
group.WritingMenus.Add(new WritingMenu(
itemObject["UniqueId"].GetString(),
itemObject["Page"].GetString(),
itemObject["Title"].GetString(),
itemObject["Subtitle"].GetString(),
itemObject["ImagePath"].GetString(),
itemObject["Description"].GetString(),
itemObject["Content"].GetString(),
itemObject["WritingsId"].GetString(),
itemObject["GroupId"].GetString(),
Convert.ToInt32(itemObject["Item"].ValueType)
this.Groups.Add(group);
and I get this Error:
Error 5 'System.Threading.Tasks.Task<System.Collections.Generic.IEnumerable<App1.DesignTimeData.Writing>>'
does not contain a definition for 'Select' and no extension method 'Select' accepting a first argument of type
'System.Threading.Tasks.Task<System.Collections.Generic.IEnumerable<App1.DesignTimeData.Writing>>'
could be found (are you missing a using directive or an assembly reference?)
I'm creating collections of:
public interface IWritingItemViewModel : Common.IVariableSizedItem
Models.Writing Writing { get; set; }
and my class for creating data is:
public class Writing
public Writing(
string uniqueId,
bool isHeaderInteractive,
string templateType,
string viewModelType,
string page,
string title,
string subtitle,
string imagePath,
string description,
string groupId
this.UniqueId = uniqueId;
this.IsHeaderInteractive = isHeaderInteractive;
this.TemplateType = templateType;
this.ViewModelType = viewModelType;
this.Page = page;
this.Title = title;
this.Subtitle = subtitle;
this.ImagePath = imagePath;
this.Description = description;
this.GroupId = groupId;
this.WritingMenus = new ObservableCollection<WritingMenu>();
public string UniqueId { get; private set; }
public bool IsHeaderInteractive { get; private set; }
public string TemplateType { get; private set; }
public string ViewModelType { get; private set; }
public string Page { get; private set; }
public string Title { get; private set; }
public string Subtitle { get; private set; }
public string ImagePath { get; private set; }
public string Description { get; private set; }
public string GroupId { get; private set; }
public virtual ObservableCollection<WritingMenu> WritingMenus { get; private set; }
How can I solve or successfully complete this code?
Thanks!...
Code is like a box of chocolates!...I looked into your error message again, I found something interesting:
Error 5
'System.Threading.Tasks.Task<System.Collections.Generic.IEnumerable<App1.DesignTimeData.Writing>>'
does not contain a definition
for 'Select'
and no extension method
'Select' accepting a first argument of type
'System.Threading.Tasks.Task<System.Collections.Generic.IEnumerable<App1.DesignTimeData.Writing>>'
could be found (are you missing a
using directive or an assembly reference?)
That means: Task does not contain the definition for Select. This was reasonable, Task does not inherit IEnumerable interface.
var viewmodels = writings.Select((x, i) => new WritingItemViewModel
Writing = x,
VariableItemSize = (i == 0) ? Common.VariableItemSizes.Writings : Common.VariableItemSizes.Normal,
public async Task<IEnumerable<Writing>> GetGroupsAsync()
You need get the IEnumerable<Writing> for Select use. See this for more information:
How to: Return a Value from a Task
--James
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey. -
Unable to view Abstract Message Interface(Sync) in Container Step of BPM
Dear Friends,
This is IDOC---SOAP Sync Communication Interface
I have created the External Def by exporting & importing the Standard Idoc
and Imported the WSDL File which has the Request & response Structure
I have created the Outbound Sync message Interface for Idoc side
and Abstract Sync message Interface for the same to use in BPM
and also created Inbound Sync Message Interface for Webservice side
and Abstract Sync Message Interface for the same to use in BPM
Problem is::::
While creating the Container varible inside the Integration Process, i have to select the Abstract Message Interface which i created for Idoc.
But it is not at all visible in the list.
What might be the problem
REgards
SeshagiriHi,
I have created
For Idoc side
1) Create O/b Sync by having request of Idoc and response structure of Idoc
2) Create ABS Sync by having the request of Idoc and response structure of Idoc
3) Create ABS Async by having the Request of Idoc Only
For Webservice side
1) Create I/b Sync by having the request of webservice and response of that
2) Create ABS Sync by having the request of webservice and response of that
3) Create ABS Async by having the Response of Webservice only
I created the Steps inside the Integration Process as showed in the screens.
1)Integration Process graph
http://img145.imageshack.us/img145/4848/ipviewwv1.jpg
2)Receive Step
http://img293.imageshack.us/img293/1756/receivepropng8.jpg
3)Send step1
http://img179.imageshack.us/img179/2200/send1bd0.jpg
4)Send Step2
http://img182.imageshack.us/img182/8468/send2wl1.jpg
When i check the F7, it is throwing the error like
http://img247.imageshack.us/img247/4356/errortx3.jpg
Regards
Seshagiri -
Hi All,
I have a cube in which i'm using the TIME DIM that i created in the warehouse. But now i wanted a new measure in the cube which is Average over time and when i wanted to created the new measure i got a message that no time dim was defined, so i created a
new time dimension in the SSAS using wizard. But when i tried to process the new time dimension i'm getting the follwoing error message
"Errors in the high-level relational engine. The data source view does not contain a definition for "SSASTIMEDIM" the table or view. The Source property may not have been set."
Can anyone please tell me why i cannot create a new measure average over the time using my time dimension? Also what am i doing wrong with the SSASTIMEDIM, that i'm getting the error.
ThanksHi PMunshi,
According to your description, you get the above error when processing the time dimension. Right?
In this scenario, since you have updated the DSV, it should have no problem on the table existence. One possibility is that table has been specified for tracking in the notifications for proactive caching, but isn't available any more for some
reason. Please change the setting in Proactive Caching into "MOLAP".
Reference:
How To Implement Proactive Caching in SQL Server Analysis Services SSAS
If you have any question, please feel free to ask.
Best Regards,
Simon Hou
TechNet Community Support -
EWS/Services.wsdl does not contain a definition for ConnectingSID.ItemElementName in Exchange 2013
We're using EWS (unmanaged) in a .NET app to access Exchange Server. After moving from 2010 to a server with Exchange 2013 and updating the web reference, I get error messages stating ConnectingSIDType does not contain a definition
for ItemElementName or PrimarySmtpAddress.
If I point the ExchangeServiceBinding object url to the new server, but do NOT update the web reference to the new server, everything still works. How do we fix this issue? The 2010 Exchange server will go away within a few days.This is the 2010 version
public partial class ConnectingSIDType {
private string itemField;
private ItemChoiceType itemElementNameField;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute("PrimarySmtpAddress", typeof(string))]
[System.Xml.Serialization.XmlElementAttribute("PrincipalName", typeof(string))]
[System.Xml.Serialization.XmlElementAttribute("SID", typeof(string))]
[System.Xml.Serialization.XmlElementAttribute("SmtpAddress", typeof(string))]
[System.Xml.Serialization.XmlChoiceIdentifierAttribute("ItemElementName")]
public string Item {
get {
return this.itemField;
set {
this.itemField = value;
/// <remarks/>
[System.Xml.Serialization.XmlIgnoreAttribute()]
public ItemChoiceType ItemElementName {
get {
return this.itemElementNameField;
set {
this.itemElementNameField = value;
2013 version
public partial class ConnectingSIDType {
private object itemField;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute("PrimarySmtpAddress", typeof(PrimarySmtpAddressType))]
[System.Xml.Serialization.XmlElementAttribute("PrincipalName", typeof(PrincipalNameType))]
[System.Xml.Serialization.XmlElementAttribute("SID", typeof(SIDType))]
[System.Xml.Serialization.XmlElementAttribute("SmtpAddress", typeof(SmtpAddressType))]
public object Item {
get {
return this.itemField;
set {
this.itemField = value;
And here is the impersonation code
ExchangeImpersonationType impersonate = new ExchangeImpersonationType();
impersonate.ConnectingSID = new ConnectingSIDType();
impersonate.ConnectingSID.Item = _email;
impersonate.ConnectingSID.ItemElementName = ItemChoiceType.PrimarySmtpAddress;
this.ExchangeService.ExchangeImpersonation = impersonate;
ConnectingSID.ItemElementName doesn't exist in the 2013 version. Is there a different way to do impersonation without going to the managed API?
-
PropertyInfo does not contain a definition for 'GetCustomAttribute' ?
Hello,
I inherited a .Net 4 Asp.net web application . I did a build and got the error below. According to MSDN, PropertyInfo doesn't have a GetCustomAttribute method. (It does have a
GetCustomAttributes method). Am I missing a extension method? Or using wrong version of .net framework? Thanks, Peter
xxx= property.GetCustomAttribute<JsonPropertyAttribute>();
Error 1 'System.Reflection.PropertyInfo' does not contain a definition for 'GetCustomAttribute' and no extension method 'GetCustomAttribute' accepting a first argument of type 'System.Reflection.PropertyInfo' could be found (are you missing a using
directive or an assembly reference?) C:\projects\DotNetDemo\WebSite\CreateIncident.aspx.cs 357I think that you need a “using System.Reflection” and the .NET 4.5:
http://msdn.microsoft.com/en-us/library/hh194315(v=vs.110).aspx. -
Hello experts,
I'm totally new to C#. I'm trying to modify existing code to automatically rename a file if exists. I found a solution online as follows:
string[] allFiles = Directory.GetFiles(folderPath).Select(filename => Path.GetFileNameWithoutExtension(filename)).ToArray();
string tempFileName = fileName;
int count = 1;
while (allFiles.Contains(tempFileName ))
tempFileName = String.Format("{0} ({1})", fileName, count++);
output = Path.Combine(folderPath, tempFileName );
string fullPath=output + ".xml";
However, it gives the following compilation errors
for the Select and Contain methods respectively.:
'System.Array' does not contain a definition for 'Select' and no extension method 'Select' accepting a first argument of type 'System.Array' could be found
(are you missing a using directive or an assembly reference?)
'System.Array' does not contain a definition for 'Contains' and no extension method 'Contains' accepting a first argument of type 'System.Array' could be
found (are you missing a using directive or an assembly reference?)
I googled on these errors, and people suggested to add using System.Linq;
I did, but the errors persist.
Any help and information is greatly appreciated.
P. S. Here are the using clauses I have:
using System;
using System.Data;
using System.Windows.Forms;
using System.IO;
using System.Collections.Generic;
using System.Text;
using System.Linq;Besides your issue with System.Core, you also have a problem with the logic of our code, particularly your variables. It is confusing what your variables represent. You have an infinite loop, so the last section of code is never reached. Take a look
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.IO;
namespace consAppFileManipulation
class Program
static void Main(string[] args)
string fullPath = @"c:\temp\trace.log";
string folderPath = @"c:\temp\";
string fileName = "trace.log";
string output = "";
string fileNameOnly = Path.GetFileNameWithoutExtension(fullPath);
string extension = Path.GetExtension(fullPath);
string path = Path.GetDirectoryName(fullPath);
string newFullPath = fullPath;
string[] allFiles = Directory.GetFiles(folderPath).Select(filename => Path.GetFileNameWithoutExtension(filename)).ToArray();
string tempFileName = fileName;
int count = 1;
//THIS IS AN INFINITE LOOP
while (allFiles.Contains(fileNameOnly))
tempFileName = String.Format("{0} ({1})", fileName, count++);
//THIS CODE IS NEVER REACHED
output = Path.Combine(folderPath, tempFileName);
fullPath = output + ".xml";
//string fullPath = output + ".xml";
UML, then code -
Usage of Abstract Message Interface for non-BPM
Hi,
I have a message that I am using as both as an inbound and an outbound for 2 different mapping. I am not using BPM. Is it better to create 2 message interfacesone for outbound and one for inboundor should I just create 1 abstract message interface that can be used in both mappings? What are the advantages and disadvantages of using 2 message interfaces (1 inbound and 1 outbound) against 1 abstract message interface? Would using abstract cause a lot of problems or performance problems in the future?
Thanks in advance.
Regards,
Elberthi,
abstract messages are only used for BPMs
so I suggest creating 2 instead if you don's use a BPM
http://help.sap.com/saphelp_nw2004s/helpdata/en/e3/3355d5617d0a4cb0fe8e042c752caa/content.htm
Regards,
michal
<a href="/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions"><b>XI / PI FAQ - Frequently Asked Questions</b></a> -
Why BPM contains only ABSTRACT messgae interfaces
Hi Forum,
Can u please help me in finding why BPM can only support ABSTRACT Message Interfaces.....
thanks
Edited by: sudeep dhar on Jan 16, 2008 9:28 AMSudeep,
Refer to http://help.sap.com/saphelp_nw04/helpdata/en/4b/d26b3d32390968e10000000a114084/frameset.htm for a description of the Communication Parameters
Alternatively, from the SDN SAP on DB2 for Linux, UNIX, and Windows you can pull up the SAP documentation for SAP XI 3.0 and enter the search term 'Abstract message'
Hope this helps,
Mike -
Can I assume that Windows will be able to handle my physical interface device if I follow the "Device Class Definition for Physical Interface Devices" specification while writing the firmware?
I'm trying to develop a device which handles rumble output from applications such as games. Applications would include e.g. racing games or simulators. I'm hesitant to just clone Xbox 360 Gamepad or Sidewinder USB reports. I'd like to correctly declare my
device as something on its own while still making use of already implemented OS-specific drivers. The purpose of the mentioned specification is exactly that as far as I can tell. I wasn't able to find concrete information about its level of support though.
The "USB device class drivers included in Windows" page (sorry I'm not allowed to post links yet..) seems to link to WinUSB which I'm not sure what to do with.Thanks for your response. Well if everything was implemented at that time and it's still available it should be fine since the specification document's last version is dated 1999. I was just hoping there would be any form of documentation whether it's
supported and by which degree so I don't go through the trouble of figuring out how the firmware should be written according to the specification just to find out there is no OS driver implementation for it which would render my work more or less useless.
So I suppose I'm forced to go the trial and error path? -
Microsoft.identitymodel.claims.claimsidentitycollection doesnot contain a definition for "first"
I am getting the problem mentioned in subject : Microsoft.identitymodel.claims.claimsidentitycollection doesnot contain a definition for "first"and no extension method "First" accepting an argument of type Microsoft.identitymodel.claims.claimsidentitycollection
could be found
Here is my line in my code which is throwing error:
var identity = handlers.validatetoken(token).first();Hi,
Is your custom development code related to SharePoint ?
As I saw the "Microsoft.identitymodel.claims.claimsidentitycollection" is the Windows Identity Foudation API, I suggest you can create a new thread in the MSDN.NET forum:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/home?category=netdevelopment&filter=alltypes&sort=lastpostdesc
Thanks
Best Regards
TechNet Community Support
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact
[email protected] -
Hi ,
I have a fundamental doubt regarding Abstract Class & Interface!!!
What is their real benefit...whether we implement an interface or extend an Abstract class we have to write the code for the abstract method in the concrete class.Then where the benefit remained....
And it is said that Abstract class provide default behaviour...what is the actual meaning of that?
Thanks & Regards
SantoshIn this section we will redesign our OneRowNim game to fit within a hierarchy of classes of two-player games. There are many games that characteristically involve two players: checkers, chess, tic-tac-toe, guessing games, and so forth. However, there are also many games that involve just one player: blackjack, solitaire, and others. There are also games that involve two or more players, such as many card games. Thus, our redesign of OneRowNim as part of a two-player game hierarchy will not be our last effort to design a hierarchy of game-playing classes. We will certainly redesign things as we learn new Java language constructs and as we try to extend our game library to other kinds of games.
This case study will illustrate how we can apply inheritance and polymorphism, as well as other object-oriented design principles. The justification for revising OneRowNim at this point is to make it easier to design and develop other two-player games. As we have seen, one characteristic of class hierarchies is that more general attributes and methods are defined in top-level classes. As one proceeds down the hierarchy, the methods and attributes become more specialized. Creating a subclass is a matter of specializing a given class.
8.6.1. Design Goals
One of our design goals is to revise the OneRowNim game so that it fits into a hierarchy of two-player games. One way to do this is to generalize the OneRowNim game by creating a superclass that contains those attributes and methods that are common to all two-player games. The superclass will define the most general and generic elements of two-player games. All two-player games, including OneRowNim, will be defined as subclasses of this top-level superclass and will inherit and possibly override its public and protected variables and methods. Also, our top-level class will contain certain abstract methods, whose implementations will be given in OneRowNim and other subclasses.
Generic superclass
A second goal is to design a class hierarchy that makes it possible for computers to play the game, as well as human users. Thus, for a given two-player game, it should be possible for two humans to play each other, or for two computers to play each other, or for a human to play against a computer. This design goal will require that our design exhibit a certain amount of flexibility. As we shall see, this is a situation in which Java interfaces will come in handy.
[Page 376]
Another important goal is to design a two-player game hierarchy that can easily be used with a variety of different user interfaces, including command-line interfaces and GUIs. To handle this feature, we will develop Java interfaces to serve as interfaces between our two-player games and various user interfaces.
8.6.2. Designing the TwoPlayerGame Class
To begin revising the design of the OneRowNim game, we first need to design a top-level class, which we will call the TwoPlayerGame class. What variables and methods belong in this class? One way to answer this question is to generalize our current version of OneRowNim by moving any variables and methods that apply to all two-player games up to the TwoPlayerGame class. All subclasses of TwoPlayerGamewhich includes the OneRowNim classwould inherit these elements. Figure 8.18 shows the current design of OneRowNim.
Figure 8.18. The current OneRowNim class.
What variables and methods should we move up to the TwoPlayerGame class? Clearly, the class constants, PLAYER_ONE and PLAYER_TWO, apply to all two-player games. These should be moved up. On the other hand, the MAX_PICKUP and MAX_STICKS constants apply just to the OneRowNim game. They should remain in the OneRowNim class.
The nSticks instance variable is a variable that only applies to the OneRowNim game but not to other two-player games. It should stay in the OneRowNim class. On the other hand, the onePlaysNext variable applies to all two-player games, so we will move it up to the TwoPlayerGame class.
Because constructors are not inherited, all of the constructor methods will remain in the OneRowNim class. The instance methods, takeSticks() and getSticks(), are specific to OneRowNim, so they should remain there. However, the other methods, getPlayer(), gameOver(), getWinner(), and reportGameState(), are methods that would be useful to all two-player games. Therefore these methods should be moved up to the superclass. Of course, while these methods can be defined in the superclass, some of them can only be implemented in subclasses. For example, the reportGameState() method reports the current state of the game, so it has to be implemented in OneRowNim. Similarly, the getWinner() method defines how the winner of the game is determined, a definition that can only occur in the subclass. Every two-player game needs methods such as these. Therefore, we will define these methods as abstract methods in the superclass. The intention is that TwoPlayerGame subclasses will provide game-specific implementations for these methods.
[Page 377]
Constructors are not inherited
Given these considerations, we come up with the design shown in Figure 8.19. The design shown in this figure is much more complex than the designs used in earlier chapters. However, the complexity comes from combining ideas already discussed in previous sections of this chapter, so don't be put off by it.
Figure 8.19. TwoPlayerGame is the superclass for OneRowNim and other two-player games.
To begin with, note that we have introduced two Java interfaces into our design in addition to the TwoPlayerGame superclass. As we will show, these interfaces lead to a more flexible design and one that can easily be extended to incorporate new two-player games. Let's take each element of this design separately.
[Page 378]
8.6.3. The TwoPlayerGame Superclass
As we have stated, the purpose of the TwoPlayerGame class is to serve as the superclass for all two-player games. Therefore, it should define the variables and methods shared by two-player games.
The PLAYER_ONE, PLAYER_TWO, and onePlaysNext variables and the getPlayer(), setPlayer(), and changePlayer() methods have been moved up from the OneRowNim class. Clearly, these variables and methods apply to all two-player games. Note that we have also added three new variables, nComputers, computer1, computer2, and their corresponding methods, getNComputers() and addComputerPlayer(). We will use these elements to give our games the capability to be played by computer programs. Because we want all of our two-player games to have this capability, we define these variables and methods in the superclass rather than in OneRowNim and subclasses of TwoPlayerGame.
Note that the computer1 and computer2 variables are declared to be of type IPlayer. IPlayer is an interface containing a single method declaration, the makeAMove() method:
public interface IPlayer {
public String makeAMove(String prompt);
Why do we use an interface here rather than some type of game-playing object? This is a good design question. Using an interface here makes our design more flexible and extensible because it frees us from having to know the names of the classes that implement the makeAMove() method. The variables computer1 and computer2 will be assigned objects that implement IPlayer via the addComputerPlayer() method.
Game-dependent algorithms
The algorithms used in the various implementations of makeAMove() are game-dependentthey depend on the particular game being played. It would be impossible to define a game playing object that would suffice for all two-player games. Instead, if we want an object that plays OneRowNim, we would define a OneRowNimPlayer and have it implement the IPlayer interface. Similarly, if we want an object that plays checkers, we would define a CheckersPlayer and have it implement the IPlayer interface. By using an interface here, our TwoPlayerGame hierarchy can deal with a wide range of differently named objects that play games, as long as they implement the IPlayer interface. Using the IPlayer interface adds flexibility to our game hierarchy and makes it easier to extend it to new, yet undefined, classes. We will discuss the details of how to design a game player in Section 8.6.7.
The IPlayer interface
Turning now to the methods defined in TwoPlayerGame, we have already seen implementations of getPlayer(), setPlayer(), and changePlayer() in the OneRowNim class. We will just move those implementations up to the superclass. The getNComputers() method is the assessor method for the nComputers variable, and its implementation is routine. The addComputerPlayer() method adds a computer player to the game. Its implementation is as follows:
[Page 379]
public void addComputerPlayer(IPlayer player) {
if (nComputers == 0)
computer2 = player;
else if (nComputers == 1)
computer1 = player;
else
return; // No more than 2 players
++nComputers;
As we noted earlier, the classes that play the various TwoPlayerGames must implement the IPlayer interface. The parameter for this method is of type IPlayer. The algorithm we use checks the current value of nComputers. If it is 0, which means that this is the first IPlayer added to the game, the player is assigned to computer2. This allows the human user to be associated with PLAYERONE if this is a game between a computer and a human user.
If nComputers equals 1, which means that we are adding a second IPlayer to the game, we assign that player to computer1. In either of these cases, we increment nComputers. Note what happens if nComputers is neither 1 nor 2. In that case, we simply return without adding the IPlayer to the game and without incrementing nComputers. This, in effect, limits the number of IPlayers to two. (A more sophisticated design would throw an exception to report an error. but we will leave that for a subsequent chapter.)
The addComputerPlayer() method is used to initialize a game after it is first created. If this method is not called, the default assumption is that nComputers equals zero and that computer1 and computer2 are both null. Here's an example of how it could be used:
OneRowNim nim = new OneRowNim(11); // 11 sticks
nim.add(new NimPlayer(nim)); // 2 computer players
nim.add(new NimPlayerBad(nim));
Note that the NimPlayer() constructor takes a reference to the game as its argument. Clearly, our design should not assume that the names of the IPlayer objects would be known to the TwoPlayerGame superclass. This method allows the objects to be passed in at runtime. We will discuss the details of NimPlayerBad in Section 8.6.7.
The getrules() method is a new method whose purpose is to return a string that describes the rules of the particular game. This method is implemented in the TwoPlayerGame class with the intention that it will be overridden in the various subclasses. For example, its implementation in TwoPlayerGame is:
public String getRules() {
return "The rules of this game are: ";
Overriding a method
[Page 380]
and its redefinition in OneRowNim is:
public String getRules() {
return "\n*** The Rules of One Row Nim ***\n" +
"(1) A number of sticks between 7 and " + MAX_STICKS +
" is chosen.\n" +
"(2) Two players alternate making moves.\n" +
"(3) A move consists of subtracting between 1 and\n\t" +
MAX_PICKUP +
" sticks from the current number of sticks.\n" +
"(4) A player who cannot leave a positive\n\t" +
" number of sticks for the other player loses.\n";
The idea is that each TwoPlayerGame subclass will take responsibility for specifying its own set of rules in a form that can be displayed to the user.
You might recognize that defining geTRules() in the superclass and allowing it to be overridden in the subclasses is a form of polymorphism. It follows the design of the toString() method, which we discussed earlier. This design will allow us to use code that takes the following form:
TwoPlayerGame game = new OneRowNim();
System.out.println(game.getRules());
Polymorphism
In this example the call to getrules() is polymorphic. The dynamic-binding mechanism is used to invoke the getrules() method defined in the OneRowNim class.
The remaining methods in TwoPlayerGame are defined abstractly. The gameOver() and getWinner() methods are both game-dependent methods. That is, the details of their implementations depend on the particular TwoPlayerGame subclass in which they are implemented.
This is good example of how abstract methods should be used in designing a class hierarchy. We give abstract definitions in the superclass and leave the detailed implementations up to the individual subclasses. This allows the different subclasses to tailor the implementations to their particular needs, while allowing all subclasses to share a common signature for these tasks. This enables us to use polymorphism to create flexible, extensible class hierarchies.
Figure 8.20 shows the complete implementation of the abstract TwoPlayerGame class. We have already discussed the most important details of its implementation.
Figure 8.20. The TwoPlayerGame class
(This item is displayed on page 381 in the print version)
public abstract class TwoPlayerGame {
public static final int PLAYER_ONE = 1;
public static final int PLAYER_TWO = 2;
protected boolean onePlaysNext = true;
protected int nComputers = 0; // How many computers
// Computers are IPlayers
protected IPlayer computer1, computer2;
public void setPlayer(int starter) {
if (starter == PLAYER_TWO)
onePlaysNext = false;
else onePlaysNext = true;
} // setPlayer()
public int getPlayer() {
if (onePlaysNext)
return PLAYER_ONE;
else return PLAYER_TWO;
} // getPlayer()
public void changePlayer() {
onePlaysNext = !onePlaysNext;
} // changePlayer()
public int getNComputers() {
return nComputers;
} // getNComputers()
public String getRules() {
return "The rules of this game are: ";
} // getRules()
public void addComputerPlayer(IPlayer player) {
if (nComputers == 0)
computer2 = player;
else if (nComputers == 1)
computer1 = player;
else
return; // No more than 2 players
++nComputers;
} // addComputerPlayer()
public abstract boolean gameOver(); // Abstract Methods
public abstract String getWinner();
} // TwoPlayerGame class
Effective Design: Abstract Methods
Abstract methods allow you to give general definitions in the superclass and leave the implementation details to the different subclasses.
[Page 381]
8.6.4. The CLUIPlayableGame Interface
We turn now to the two interfaces shown in Figure 8.19. Taken together, the purpose of these interfaces is to create a connection between any two-player game and a command-line user interface (CLUI). The interfaces provide method signatures for the methods that will implement the details of the interaction between a TwoPlayerGame and a UserInterface. Because the details of this interaction vary from game to game, it is best to leave the implementation of these methods to the games themselves.
Note that CLUIPlayableGame extends the IGame interface. The IGame interface contains two methods that are used to define a standard form of communication between the CLUI and the game. The getGamePrompt() method defines the prompt used to signal the user for a move of some kindfor example, "How many sticks do you take (1, 2, or 3)?" And the reportGameState() method defines how the game will report its current statefor example, "There are 11 sticks remaining." CLUIPlayableGame adds the play() method to these two methods. As we will see shortly, the play() method contains the code that will control the playing of the game.
[Page 382]
Extending an interface
The source code for these interfaces is very simple:
public interface CLUIPlayableGame extends IGame {
public abstract void play(UserInterface ui);
public interface IGame {
public String getGamePrompt();
public String reportGameState();
} // IGame
Note that the CLUIPlayableGame interface extends the IGame interface. A CLUIPlayableGame is a game that can be played through a CLUI. The purpose of its play() method is to contain the game-dependent control loop that determines how the game is played via a user interface (UI). In pseudocode, a typical control loop for a game would look something like the following:
Initialize the game.
While the game is not over
Report the current state of the game via the UI.
Prompt the user (or the computer) to make a move via the UI.
Get the user's move via the UI.
Make the move.
Change to the other player.
The play loop sets up an interaction between the game and the UI. The UserInterface parameter allows the game to connect directly to a particular UI. To allow us to play our games through a variety of UIs, we define UserInterface as the following Java interface:
public interface UserInterface {
public String getUserInput();
public void report(String s);
public void prompt(String s);
Any object that implements these three methods can serve as a UI for one of our TwoPlayerGames. This is another example of the flexibility of using interfaces in object-oriented design.
To illustrate how we use UserInterface, let's attach it to our KeyboardReader class, thereby letting a KeyboardReader serve as a CLUI for TwoPlayerGames. We do this simply by implementing this interface in the KeyboardReader class, as follows:
public class KeyboardReader implements UserInterface
[Page 383]
As it turns out, the three methods listed in UserInterface match three of the methods in the current version of KeyboardReader. This is no accident. The design of UserInterface was arrived at by identifying the minimal number of methods in KeyboardReader that were needed to interact with a TwoPlayerGame.
Effective Design: Flexibility of Java Interfaces
A Java interface provides a means of associating useful methods with a variety of different types of objects, leading to a more flexible object-oriented design.
The benefit of defining the parameter more generally as a UserInterface instead of as a KeyboardReader is that we will eventually want to allow our games to be played via other kinds of command-line interfaces. For example, we might later define an Internet-based CLUI that could be used to play OneRowNim among users on the Internet. This kind of extensibilitythe ability to create new kinds of UIs and use them with TwoPlayerGamesis another important design feature of Java interfaces.
Generality principle
Effective Design: Extensibility and Java Interfaces
Using interfaces to define useful method signatures increases the extensibility of a class hierarchy.
As Figure 8.19 shows, OneRowNim implements the CLUIPlayableGame interface, which means it must supply implementations of all three abstract methods: play(), getGamePrompt(), and reportGameState().
8.6.5. Object-Oriented Design: Interfaces or Abstract Classes?
Why are these methods defined in interfaces? Couldn't we just as easily define them in the TwoPlayerGame class and use inheritance to extend them to the various game subclasses? After all, isn't the net result the same, namely, that OneRowNim must implement all three methods.
These are very good design questions, exactly the kinds of questions one should ask when designing a class hierarchy of any sort. As we pointed out in the Animal example earlier in the chapter, you can get the same functionality from an abstract interface and an abstract superclass method. When should we put the abstract method in the superclass, and when does it belong in an interface? A very good discussion of these and related object-oriented design issues is available in Java Design, 2nd Edition, by Peter Coad and Mark Mayfield (Yourdan Press, 1999). Our discussion of these issues follows many of the guidelines suggested by Coad and Mayfield.
Interfaces vs. abstract methods
We have already seen that using Java interfaces increases the flexibility and extensibility of a design. Methods defined in an interface exist independently of a particular class hierarchy. By their very nature, interfaces can be attached to any class, and this makes them very flexible to use.
Flexibility of interfaces
Another useful guideline for answering this question is that the superclass should contain the basic common attributes and methods that define a certain type of object. It should not necessarily contain methods that define certain roles that the object plays. For example, the gameOver() and getWinner() methods are fundamental parts of the definition of a TwoPlayerGame. One cannot define a game without defining these methods. By contrast, methods such as play(), getGamePrompt(), and reportGameState() are important for playing the game but they do not contribute in the same way to the game's definition. Thus these methods are best put into an interface. Therefore, one important design guideline is:
[Page 384]
Effective Design: Abstract Methods
Methods defined abstractly in a superclass should contribute in a fundamental way to the basic definition of that type of object, not merely to one of its roles or its functionality.
8.6.6. The Revised OneRowNim Class
Figure 8.21 provides a listing of the revised OneRowNim class, one that fits into the TwoPlayerGame class hierarchy. Our discussion in this section will focus on the features of the game that are new or revised.
Figure 8.21. The revised OneRowNim class, Part I.
(This item is displayed on page 385 in the print version)
public class OneRowNim extends TwoPlayerGame implements CLUIPlayableGame {
public static final int MAX_PICKUP = 3;
public static final int MAX_STICKS = 11;
private int nSticks = MAX_STICKS;
public OneRowNim() { } // Constructors
public OneRowNim(int sticks) {
nSticks = sticks;
} // OneRowNim()
public OneRowNim(int sticks, int starter) {
nSticks = sticks;
setPlayer(starter);
} // OneRowNim()
public boolean takeSticks(int num) {
if (num < 1 || num > MAX_PICKUP || num > nSticks)
return false; // Error
else // Valid move
{ nSticks = nSticks - num;
return true;
} // else
} // takeSticks()
public int getSticks() {
return nSticks;
} // getSticks()
public String getRules() {
return "\n*** The Rules of One Row Nim ***\n" +
"(1) A number of sticks between 7 and " + MAX_STICKS +
" is chosen.\n" +
"(2) Two players alternate making moves.\n" +
"(3) A move consists of subtracting between 1 and\n\t" +
MAX_PICKUP + " sticks from the current number of sticks.\n" +
"(4) A player who cannot leave a positive\n\t" +
" number of sticks for the other player loses.\n";
} // getRules()
public boolean gameOver() { /*** From TwoPlayerGame */
return (nSticks <= 0);
} // gameOver()
public String getWinner() { /*** From TwoPlayerGame */
if (gameOver()) //{
return "" + getPlayer() + " Nice game.";
return "The game is not over yet."; // Game is not over
} // getWinner()
The gameOver() and getWinner() methods, which are nowinherited from the TwoPlayerGame superclass, are virtually the same as in the previous version. One small change is that getWinner() now returns a String instead of an int. This makes the method more generally useful as a way of identifying the winner for all TwoPlayerGames.
Similarly, the getGamePrompt() and reportGameState() methods merely encapsulate functionality that was present in the earlier version of the game. In our earlier version the prompts to the user were generated directly by the main program. By encapsulating this information in an inherited method, we make it more generally useful to all TwoPlayerGames.
Inheritance and generality
The major change to OneRowNim comes in the play() method, which controls the playing of OneRowNim (Fig. 8.22). Because this version of the game incorporates computer players, the play loop is a bit more complex than in earlier versions of the game. The basic idea is still the same: The method loops until the game is over. On each iteration of the loop, one or the other of the two players, PLAYER_ONE or PLAYER_TWO, takes a turn making a movethat is, deciding how many sticks to pick up. If the move is a legal move, then it becomes the other player's turn.
Figure 8.22. The revised OneRowNim class, Part II.
(This item is displayed on page 386 in the print version)
/** From CLUIPlayableGame */
public String getGamePrompt() {
return "\nYou can pick up between 1 and " +
Math.min(MAX_PICKUP,nSticks) + " : ";
} // getGamePrompt()
public String reportGameState() {
if (!gameOver())
return ("\nSticks left: " + getSticks() +
" Who's turn: Player " + getPlayer());
else
return ("\nSticks left: " + getSticks() +
" Game over! Winner is Player " + getWinner() +"\n");
} // reportGameState()
public void play(UserInterface ui) { // From CLUIPlayableGame interface
int sticks = 0;
ui.report(getRules());
if (computer1 != null)
ui.report("\nPlayer 1 is a " + computer1.toString());
if (computer2 != null)
ui.report("\nPlayer 2 is a " + computer2.toString());
while(!gameOver()) {
IPlayer computer = null; // Assume no computers
ui.report(reportGameState());
switch(getPlayer()) {
case PLAYER_ONE: // Player 1's turn
computer = computer1;
break;
case PLAYER_TWO: // Player 2's turn
computer = computer2;
break;
} // cases
if (computer != null) { // If computer's turn
sticks = Integer.parseInt(computer.makeAMove(""));
ui.report(computer.toString() + " takes " + sticks + " sticks.\n");
} else { // otherwise, user's turn
ui.prompt(getGamePrompt());
sticks =
Integer.parseInt(ui.getUserInput()); // Get user's move
if (takeSticks(sticks)) // If a legal move
changePlayer();
} // while
ui.report(reportGameState()); // The game is now over
} // play()
} // OneRowNim class
Let's look now at how the code decides whether it is a computer's turn to move or a human player's turn. Note that at the beginning of the while loop, it sets the computer variable to null. It then assigns computer a value of either computer1 or computer2, depending on whose turn it is. But recall that one or both of these variables may be null, depending on how many computers are playing the game. If there are no computers playing the game, then both variables will be null. If only one computer is playing, then computer1 will be null. This is determined during initialization of the game, when the addComputerPlayer() is called. (See above.)
In the code following the switch statement, if computer is not null, then we call computer.makeAMove(). As we know, the makeAMove() method is part of the IPlayer interface. The makeAMove() method takes a String parameter that is meant to serve as a prompt, and returns a String that is meant to represent the IPlayer's move:
public interface IPlayer {
public String makeAMove(String prompt);
[Page 385]
In OneRowNim the "move" is an integer, representing the number of sticks the player picks. Therefore, in play() OneRowNim has to convert the String into an int, which represents the number of sticks the IPlayer picks up.
On the other hand, if computer is null, this means that it is a human user's turn to play. In this case, play() calls ui.getUserInput(), employing the user interface to input a value from the keyboard. The user's input must also be converted from String to int. Once the value of sticks is set, either from the user or from the IPlayer, the play() method calls takeSticks(). If the move is legal, then it changes whose turn it is, and the loop repeats.
[Page 386]
There are a couple of important points about the design of the play() method. First, the play() method has to know what to do with the input it receives from the user or the IPlayer. This is game-dependent knowledge. The user is inputting the number of sticks to take in OneRowNim. For a tic-tac-toe game, the "move" might represent a square on the tic-tac-toe board. This suggests that play() is a method that should be implemented in OneRowNim, as it is here, because OneRowNim encapsulates the knowledge of how to play the One-Row Nim game.
Encapsulation of game-dependent knowledge
[Page -
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)ControllerHi,
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
Maybe you are looking for
-
Iphoto wont open. Message reads "you can't open the application. It might be damaged....
I get a message :- You can't open the application IPhoto because it may be damaged or incomplete. Any ideas??
-
I am struggling with N97 media player every time I try to play a video including the ones captured by the phone camera I receive the following message "Enable to play either sound or video clip, trying to play partially" then I only get the sound wit
-
Pb not connecting to app world on pc
when i tried to download an app to my playbook through pc app world a dialog box appears on computer screen saying "your playbook is secured with a password please enter the password to connect" but password protection is disabled in my device pls he
-
Easy way to transfer photos from multiple computers to one library ?
Hi, At home we have a couple of macs and of course every user has it's own iphoto library. I am now looking for a way to backup all those iPhoto libraries to a "main" computer in an easy way. This main computer is an iMac with multiple external drive
-
Procurement Contracts Interface Tables
What are the usage of these two Interfaces: 1- OKC_ValueSets_Interface 2- OKC_VS_Values_Interface On which form will i see the posted data and what are the names of their destinaition tables? Regards