Interactivity Abstraction

Hi All,
I have chosen Captivate to make a training video for my
softare much like I am sure many of you have done before. I have
been having a hard time with one thing though.
My goal is to have many small 200px by 100px sections of
software demo'd. Then once I have demo'd every small section of my
software I plan to use these small demos in an overall demo. So I
plan to make the demo an interactive simulation using clickable
buttons to invoke the small demos from before. Sounds easy right?
The reason I am doing the small videos is because I plan to
have small '?' (question marks) next to each confusing part of my
software. I don't want the user to have to navigate away and trudge
through a long tutorial each time they don't understand something.
So, I will have mini tutorials all over the app. Then one big one
containing all the small ones in an "Interactive Demo"
I have been working with Captivate for a while to capture the
screen for simple fullscreen demos, but I can't seem to get this
functionality out of it.
Is this possible? Thanks for any help in advance?

Open 2 versions of captivate. Set one at 200px100px and the
other at your main project size (ie 800x600 as an example).
Use the smaller version to record your demos and publish
these as individual .swf files, named accordingly. Record each of
these separatly so you end up with a collection of .CP files and
published .SWF files.
Then drop these .swfs into the main project either as
animations on a slide or come in through a slidelet when a user
clicks or hovers over (use insert animation in slidelet options)
Webbo

Similar Messages

Difference between Abstract portal Component and JSPDyn page.

Hi Experts,
What is the difference between Abstract portal Component and JSPDyn page.
Thanks,
Jay.

Hi,
The PDK provides two methods for creating a portal component:
Abstract Portal Component
The Abstract Portal Component class offers a lean method for writing HTML commands to the Web client as well as for basic event handling. It is an implementation of the IPortalComponent, which is the central abstraction of the Portal Component API.
DynPage
The Page Processor Component, which extends the Abstract Portal Component, returns a DynPage. It provides more sophisticated event handling. Controls that produce events (such as buttons and checkboxes) have an event attribute that contains the name of the event handling method. This event handling method is invoked by the DynPage when it occurs.
The JSPDynPage is an implementation of the DynPage and allows the use of the DynPage in combination with JSP (Java Server Pages).
The PDK documentation and examples focus on the DynPage. Easier event handling and the separatation of content development (JSP) from application development (Java) make the DynPage a better choice for components with interaction and changing content.
For more details, Refer thes thread,
https://fortress.wa.gov/dop/portal/irj/portalapps/com.sap.portal.pdk.basic.portalcomponentimplementation/docs/jspdynpage.html
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f0b3e9d5-b2af-2a10-20ba-9f6ce6b1a27f
Hop it helps..
GS
Edited by: Sathishkumar GS on Apr 14, 2008 2:07 PM

Regarding Abstract Interface

Hello,
What makes the difference between the Normal Interfaces and Abstract Interfaces. Is there any technical differences between these two interfaces.
Thank you

Hi,
You use a message interface to describe a platform-independent or programming-language-independent interface, which you want to use to exchange messages between application components using SAP Exchange Infrastructure.
When you create a message interface you define the communication parameters by using the attributes Mode and Category as Sync/Async, Inbound/Outbound or Abstract.
Message interfaces of this category can perform the role of an inbound or outbound interface within integration processes, depending on whether it is used to send or receive a message. For this reason, no direction is specified during definition. In integration processes, you can use the same abstract interface to receive and send a message. Abstract message interfaces generally receive the message from an outbound interface of a sender system and send it to an inbound interface of a receiver system, thus performing a complementary role.
BPM can interact and deal with only Abstract Interfaces. And so, if you have a transformation step inside the BPM , the source and target interface will have to be abstract interfaces.
These characteristics determine the direction of an interface:
· An outbound interface sends a request message that is only used to make a communication party aware of data sent, without waiting for a response message. In the case of the latter, we also refer to publishing interfaces.
· An inbound interface receives a request message that you reply to with a direct response message or whose data you can process in the system without a response.
Thanks
Swarup

Abstract Interface and BPM

If I have a Transformation step in my BPM, whether it is necessary to have the Source and Target Message Interface to be ABSTRACT?
Thanks

Mohini,
Absolutley. <b>BPM can interact and deal with only Abstract Interfaces.</b> And so, if you have a transformation step inside the BPM , <b>the source and target interface will have to be abstract interfaces.</b>
The interface mapping will be between Abs Interfaces in the IR.
Regards,
Bhavesh

Equivalent of Global Interactive Activity in 11g

Hello,
Is there an equivalent of Global Interactive (not Global Creation) activity in OBPM 11g? What I intend to do is to be able to have certain stand alone activities in the workflow bounded independently to different taskflows (there taskflows are associated with the business process but not directly linked to it). E.g. Let's say I have a requirement that the 'Manager' role in the workflow should be able to assign the primary process participants to different Line of Businesses based on day to day needs. All I need is a UI to achieve this. But I am also trying to leverage BPM roles so that only 'Managers' are able to see this link in their workspace / worklist and able to access this UI. We have previously implemented this using 'Global Interactive' in 10g. All we did was to place the activity in a manager swimlane and associate a screenflow to it. Trying to understand what 11g has to offer for this requirements.
Thanks,
Gaurav

One of the things that helps end-users train themselves on a process is to present a picture of where a work item instance that they are working on is located in the process. This is commonly referred to as the “you are here” map. In Oracle BPM 10g, this is done like this:
1.     Add a Global Interactive activity to an abstract role (role with a name).
2.     Name this new Global activity “You are here”.
3.     Click Runtime in the left pane and check the "Has instance access" (do not check the checkbox labeled “Use activity for instance presentation").
4.     Click the OK button.
5.     Right mouse click this new activity and select Main task from the popup.
6.     Change the Implementation type to "Show Process Image".
7.     Click OK.
8.     Save the project and reload the project.
9.     Start the WorkSpace again. Log out and relogin.
10.     On the right side of the inbox, for an existing work item instance click the "Select action" dropdown.
11.     Click the new "You are here" action.
12.     Note the red flag above the activity where this work item instance is located in the process.
Hope this helps,
Dan

Java code and jsp interaction

Hi,
How does one interact between java code and jsp page.That is, if the java code does say database connection, the web page should tell that the connection has been made,just like an application but this will work on the web server not in the console.Kindly let me know.
As

Just curious but where do these questions come from? A course you are taking or you are building something for a hobby?
If you are building some small simple web-app it's probably quicker to embed code right onto your JSP page.
There are various levels of abstracting your web-app separating display from logic from the model.
The following are techniques from simple web-apps to more complicated ones.
-Embedding script right into your JSP
-Using beans
-Using custom tags ( I think there are some standard ones now, struts seems to be a popular buzzword)
-Including a servlet to handle your requests redirect, update bean content grab info form your database and forward to a JSP. (Read up on model 2 architecture.)
To include as much detail as possible would be to write a book. Fortunately many have so I don't have to fit one in this tiny reply box.
Hope that was somewhat useful.

[svn] 1063: ImplementationCompiler abstract syntax tree generation

Revision: 1063
Author: [email protected]
Date: 2008-04-02 08:31:38 -0700 (Wed, 02 Apr 2008)
Log Message:
ImplementationCompiler abstract syntax tree generation
work-in-progress. Most of the methods for the equivalent Velocity
macros in ClassDef.vm and ClassDefLib.vm are stubbed out in
ImplementationGenerator. Note, with -generate-abstract-syntax-tree
set to true, mxml compilation is mostly broken. The current default
is false.
checkintests Passed: YES
Needs QA: Not yet
Needs DOC: NO
API Change: NO
Code-level description of changes:
swfutils/src/java/flash/swf/tools/SyntaxTreeDumper.java
Added evaluate() for BlockNode, CommentNode, TypeIdentifierNode,
and UsePragmaNode.
Modified evaluate() for CallExpressionNode, GetExpressionNode,
SetExpressionNode, and FunctionSignatureNode to include more info.
compiler/src/java/flex2/compiler/as3/AbstractSyntaxTreeUtil.java
Initial checkin.
compiler/src/java/flex2/compiler/as3/binding/DataBindingExtension.java
Moved numerous common methods to AbstractSyntaxTreeUtil.
compiler/src/java/flex2/compiler/mxml/rep/Model.java
Made getEffects() public.
compiler/src/java/flex2/compiler/mxml/rep/MxmlDocument.java
Added generics to getDeclarationIterator(), getImports(),
getScripts(), and getMetadata().
Added getInterfaceNames().
compiler/src/java/flex2/compiler/mxml/rep/DocumentInfo.java
Changed return type of getImportNames() from Collection to Set.
compiler/src/java/flex2/compiler/mxml/ImplementationCompiler.java
Modified parse1() to call generateImplementationAST() if
getGenerateAbstractSyntaxTree() is true. Otherwise,
generateImplementation() is called.
compiler/src/java/flex2/compiler/mxml/ImplementationGenerator.java
Initial checkin.
Modified Paths:
flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/as3/binding/DataBindingExtension. java
flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/ImplementationCompiler.java
flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/rep/DocumentInfo.java
flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/rep/Model.java
flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/rep/MxmlDocument.java
flex/sdk/trunk/modules/swfutils/src/java/flash/swf/tools/SyntaxTreeDumper.java
Added Paths:
flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/as3/AbstractSyntaxTreeUtil.java
flex/sdk/trunk/modules/compiler/src/java/flex2/compiler/mxml/ImplementationGenerator.java

Hi Florian,
you can use the resource / EMF API directly in a plain (non-interactive)
environment.
If you want to enrich your model you should investigate using imported
metamodels and derived properties for the derivable information.
However, the Linker#afterModelLinked is usually a good place to enhance
the model.
Regards,
Sebastian
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
Am 29.11.10 19:39, schrieb Florian Gessner:
> Hi Sebastian,
>
> thanks for your fast reply.
> The example described in the blog uses the IDocumentEditor to manipulate
> the data. I do not want to implement this in the UI layer but in the
> backend.
> I think EMF should would independent from this, but for me it is not
> clear how I can integrate this into the backend. I think it would be a
> bit strange if I would enrich the model by some logic during validation
> or linking. Or is this how it works?
>
> Thanks and best regards
> Florian

What is Abstract Portal Component?

Hi Experts,
Can anyone explain me the meaning of an Abstract Portal Component? What are the cases required to implement it.
Thanks in advance.

Hi Vinay,
The Abstract Portal Component is a class that offers a lean method for writing HTML commands to the Web client as well as for basic event handling. The programming effort is therefore greater for larger, interactive components.
you can understand by seeing the below links
[http://help.sap.com/saphelp_nw70/helpdata/EN/e3/fab74247e2b611e10000000a155106/content.htm]
[http://help.sap.com/saphelp_nw70/helpdata/EN/44/46bb2e70e20597e10000000a155369/frameset.htm]
Example:
[http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/60d39c32-3d7f-2c10-819b-f223c1c5d1c8&overridelayout=true]
hope this helps you

Abstract Class & Interface

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
Santosh

In 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

Design for two interacting, extensible classes

Hi,
I have a design problem where I have two interacting classes that both need to be highly extensible. I'm pretty sure this not an uncommon problem but I can't really seem to find an appropriate pattern to implement it.
The problem comes from the field of reinforcement learning, where an Agent learns some task in an Environment by executing Actions based on the current State of the environment. The State has to be provided by the Environment, and the Action chosen by the Agent based on that State has to be executed on the Environment. I thus have an Environment interface (for multi-agent problems) like so:
public interface Environment {
     //execute given action for given agent (e.g., move the agent, let the agent pick up smth
        //in the env, etc), and return a reward
     public double executeAction( Action act, Agent a );
     //compute and return state of given agent (e.g., what the agent can currently see in the
       //environment)
     public State getState( Agent a );
}There can be many different types of environments, and many different types of actions. So I thought of having a callback method on the Action that the Environment calls in method executeAction, like:
public interface Action {
     //execute on the given environment for the given agent
     public void execute(Environment env, Agent a);
}In that case you could have the same environment (e.g., a world with blocks), and different actions (say move, push a block away, pick up a block, etc). Does this make any sense? It's a little like the Command pattern perhaps?
There are two things I'm worried about. One is that the Action would need to cast the received Environment to the right implementation, but I guess that's unavoidable. The other (actually two) is that the Environment implementation would need to expose the right methods for the action to be able to execute, plus I don't always want an Action to be able to do anything it wants with the environment (e.g. teleport the agent, remove all obstacles). On the other hand maybe I shouldn't worry about the latter since it's just meant to be a toolkit, so if people using it want to program actions to teleport the agent, that's their business.
Any suggestions/comments greatly appreciated.
Thanks
Matt

I am not a native english speaker, and I'm not sure I understand your description. Is the following pseudo-code a correct description of your design?No problem, me neither. Maybe that's why it was hard to understand :) Actually, an agent should by no means have direct access to the environment: it is only allowed to perceive things through the State object it receives. So the design is something like:
public interface Agent {
        //do a step: choose an action based on the current state, and learn from
        //the reward received after the last action.
     public Action doStep( State s, double reward );
public class Simulator {
        //do one simulation step
     public void doStep() {
          State s;
          Action act;
          for ( Agent a : agents ) {
                        //get the agent's state from the environment
               s = env.getState(a);
                        //let the agent choose an action based on that state (lastReward is stored in a Map, omitted)
               act = a.doStep(s, lastReward);
                        //execute action on the environment and store the reward for this agent
               lastReward = env.executeAction(act, a));
There are two things I'm worried about. One is that the Action would need to cast the received Environment to the right implementation, but I guess that's unavoidable.Why? Cant he environment interface define abstract "modifier" methods that make sense to all implementations?Not really. An environment can be anything: a world with objects that the agent has to collect/avoid (I chose that example because I thought it might be easy to visualise and understand). A Blackjack game in which the agent has to choose to get another card or stop. The stock market in which the agent has to make trading decisions. And so on.
And iff the actions are specific to some environment implementations, then each environment can implement executeAction his way, for example calling different Action methods. In this case the Action become merely a Visitor.Yes, I indeed looked at the Visitor pattern, but I think it's not flexible enough. The types of the environments / actions need to be known beforehand, and in my case they can be anything.
The other (actually two) is that the Environment implementation would need to expose the right methods for the action to be able to execute, plus I don't always want an Action to be able to do anything it wants with the environment (e.g. teleport the agent, remove all obstacles).Method executeAction should use only those methods exposed in interface Environment (which is the type of the env argument).
If the Action and Agent implementations need some different views of the environments, just define two different interfaces.Hmm, yes. The problem is that the Environment interface should pretty much only specify those methods that I listed. Those are the methods necessary for the reinforcement learning paradigm (basically as implemented in the Simulator). Adding additional, problem-specific methods to that interface would not make sense, because environments can be anything. But, perhaps I could do something like:
public interface BlockWorld {
     public boolean move(Block b);
     public Block getBlockAt(int x, int y);
public class SomeWorld implements Environment, BlockWorld {}
public class PushAction implements Action {
     @Override
     public void execute(Environment env, Agent a) {
                //unavoidable (?) cast
          BlockWorld world = (BlockWorld) env;
          //get the block that the agent is facing, and move it
          //as specified in the action
}So define an interface according to the methods the world wants to expose. The only concern is that the same world (with obstacles and what not) could be used in a lot of different contexts, and I guess it's not desirable to subclass it every time just to make it implement an additional interface because one wants to expose different methods. But maybe I can use the Adapter pattern for this?

Abstract classes and Interfaces

Why would you use these? Why not make a concrete class and extend them? I see why JAVA doesn't use mutiple inheritance but I don't see how allowing interfaces correctes that, after all what happens if two interfaces implemented by one class have two fully defined methods with the same signature but differant outputs?
I tryed googleing this but just got articles on when to use Abstract over interface and interface over abstract, which should have helped some but it didn't.
Can someone explain or post a link for a good example.

Why would you use these? Why not make a concrete
class and extend them? Check out the JDBC interfac (java.sql package).
The core Java API defines what types and methods it wants to use for DB interactions. But because every DB and driver is so different, there's no concrete implementation that the core API could provide for those types. It's up to the vendors to provide all the "how"--all the concrete implementations of the methods.
interfaces correctes that, after all what happens if
two interfaces implemented by one class have two
fully defined methods with the same signature but
differant outputs?That rarely happens (it has never happened to me in about 8 years of Java programming) and if it does, you just have to find a different approach--you can't meet both contracts.

Synchronous User Interaction in Instance-Method

Hey Guys!
I got a problem getting information by user synchronous.
To make it understandable I abstracted the problem a little:
I have a class 'player'. It has an attribute 'name' and a method 'get_name'.
In get_name i want to ask the actual user for his/her name. A dialogue should open with a text-field and an ok-button.
(Solvable with DD_Documents -> no Problem as far).
But then I want to save the given value in text-field in the 'name'-variable.
This is a problem: Not because of getting the data out of the input field but because of the flow-control!
I know I could write a method in the same class to react to the interaction and save the variable. But if I want to use one or more players in a program, it does not wait until the variable is set to go on.
I do not want to go on with the code in the method as long as the user didn't press ok.
Can I wait for an event in a method?
Hope you get my problem!
Thank you for your help!

Hi Wolfgang,
I would try this kind of approach and see if it will solve your problem (I'm assuming your EVENTS are raised in the method display_document):
First, I would cut the following lines from the method ask_for_name:
set handler dbox_close for all instances.
set handler dd_btn_clicked for all instances.
set handler dd_ie_entered for all instances.
Second, I would add this DEFINITION of a local class & object declaration (I guessed on parameter & class names):
** Local class definition for event receiver
CLASS lcl_event_receiver DEFINITION.
PUBLIC SECTION.
    METHODS:
    handle_dbox_close
      FOR EVENT dbox_close OF zcl_player_class
        IMPORTING e_name,
    handle_dd_btn_clicked
      FOR EVENT dd_btn_clicked OF zcl_player_class
        IMPORTING e_name,
    handle_dd_ie_entered
      FOR EVENT dd_ie_entered OF zcl_player_class
        IMPORTING e_name.
ENDCLASS.                    "lcl_event_receiver DEFINITION
DATA: g_event_receiver TYPE REF TO lcl_event_receiver.
Third, I would make the following changes in your main method:
method main.
CREATE OBJECT g_event_receiver
create object s1.
create object s2.
create object s3.
SET HANDLER g_event_receiver->handle_dbox_close FOR ALL INSTANCES.
SET HANDLER g_event_receiver->handle_dd_btn_clicked FOR ALL INSTANCES.
SET HANDLER g_event_receiver->handle_dd_ie_entered FOR ALL INSTANCES.
s1->ask_for_name( ).
s2->ask_for_name( ).
s3->ask_for_name( ).
write:/ s1->name.
write:/ s2->name.
write:/ s3->name.
endmethod.
And lastly, insert the implementation for each of the handler methods:
*&       Class (Implementation) lcl_event_receiver
*        Event receiver for player class
*       CLASS lcl_event_receiver IMPLEMENTATION
CLASS lcl_event_receiver IMPLEMENTATION.
METHOD handle_dbox_close.
ENDMETHOD.
METHOD handle_dd_btn_clicked.
ENDMETHOD.
METHOD handle_dd_ie_entered.
ENDMETHOD.
ENDCLASS.               "lcl_event_receiver
Regards,
Ryan Crosby
Edited by: Ryan Crosby on Nov 8, 2011 9:50 AM

Global Interactive activity

Hi,
Could you please tell me how we can pass I/O arguments through PAPI WS/PAPI API to execute the Global Interactive activity, the main task defined for it is a Screenflow. Global Interactive activity is not having "Instance Access" check in the Properties option. We will then use these arguments inside the Screenflow for business process. As per my knowledge, for Screenflow mapping, we need to map "Value" with the appropiate arguments defined in the Screenflow argument mapping section. By default, "Value" shows predefined values.So, how we can map argument values coming from PAPI WS/PAPI API to this screenflow.
Thanks,
Abhishek

One of the things that helps end-users train themselves on a process is to present a picture of where a work item instance that they are working on is located in the process. This is commonly referred to as the “you are here” map. In Oracle BPM 10g, this is done like this:
1.     Add a Global Interactive activity to an abstract role (role with a name).
2.     Name this new Global activity “You are here”.
3.     Click Runtime in the left pane and check the "Has instance access" (do not check the checkbox labeled “Use activity for instance presentation").
4.     Click the OK button.
5.     Right mouse click this new activity and select Main task from the popup.
6.     Change the Implementation type to "Show Process Image".
7.     Click OK.
8.     Save the project and reload the project.
9.     Start the WorkSpace again. Log out and relogin.
10.     On the right side of the inbox, for an existing work item instance click the "Select action" dropdown.
11.     Click the new "You are here" action.
12.     Note the red flag above the activity where this work item instance is located in the process.
Hope this helps,
Dan

Pattern to gain abstraction over assembly with no abstraction

I'm interacting with a large code base (in a single assembly) written by another department (let's call it BusinessAssembly). Precious few of the objects we need to use in that assembly use interfaces. As a result, LOTS of our projects need to reference that
assembly because there is no abstraction available and tests are difficult to write.
To further complicate matters, it now looks as though we may need to be able to support multiple versions of the BusinessAssembly and switch between them either at build-time or run-time. E.g. BusinessAssembly2 will add new objects which we'll need to use,
but BusinessAssembly1 won't contain those objects.
My only promising solution so far is to create two separate projects in our solution, one that references BusinessAssembly1 (BusinessProxy1) and another that references BusinessAssembly2 (BusinessProxy2). These projects would contain proxies and decorators
around the individual BusinessAssembly objects (e.g. BusinessUserProxy), and those proxies and decorators would implement interfaces (IBusinessUserProxy).
If I've thought this through correctly, an abstract factory could then provide the requested proxy/decorator object from the correct proxy/decorator project at run-time and our other projects could abandon their references to the giant assembly and simply use
the interfaces the various proxies/decorators implement.
I'm not trying to alter the behaviour of the objects, but another consideration here is that we would like to gain the ability to provide test doubles for the various BusinessAssembly
objects, which this approach should provide.
However, this approach does come with a considerable amount of development overhead: when BusinessAssembly3 creates ten new objects, we'll need to write proxies and interfaces for each of those.
My question(s): Is it an acceptable use of proxies to merely provide an interface for an object that otherwise has no interface? Would a different approach avoid the development overhead?
Also, I'm terribly ill right now so let me know if I'm not being clear or if I didn't actually even type any real words here.

Hi DOAHacker,
It seems you are always copy and paste questions here, may I ask the reason? I saw the same case here:
http://programmers.stackexchange.com/questions/259779/pattern-to-gain-abstraction-over-assembly-with-no-abstraction
Here is Tory's answer:
If BusinessAssembly2 contains all of BusinessAssembly1's public members, then you could write one or more Interfaces for that subset of members, which could be used as a constructor parameter in one or more Facade classes, thereby
providing Dependency Injection. That would allow you to switch between either version of the underlying business assemblies at either design time or runtime, as needed.
It would also allow you to build test classes that implement those interfaces, and pass those into your Facade for testing purposes.
You'd still need to create or extend your Interfaces and Facade classes when
BusinessAssembly3 came out. I don't see any way around that, unless using the new classes directly is acceptable.
If those business assemblies are large, you could save yourself a lot of tedious manual work by building a little code generator that inspected them via Reflection and output Interfaces and Facade classes."
Can you share your own idea to it?
Best regards,
Barry
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.

Abstract Class Misunderstanding

I have a GUI Main class that has action listeners that need to call sub classes passing in data entered by the interacting user. The subclass being called from the GUI is an Abstract class. Since abstract classes can't be instantiated, how do I pass down the data entered by the user? If this does not make sense, please reply so and I'll post code as an example.
Thanks in advance.

You pass an instance of a subclass of the abstract class, one that is not itself abstract.

Interactivity Abstraction

Similar Messages

Maybe you are looking for