home *** CD-ROM | disk | FTP | other *** search
/ io Programmo 25 / IOPROG_25.ISO / SOFT / JavaS / javastar-eval.exe / data1.cab / Program_Files / contrib / locators / bongo.README < prev    next >
Encoding:
Text File  |  1999-02-11  |  4.8 KB  |  118 lines
  1.  
  2. Notes about Non-Component Support for Bongo (jdk 1.1.1 and above)
  3. 8/8/97
  4.  
  5. * Introduction
  6. * Recording
  7. * General Indexed Identifiers
  8. * Internal Names
  9. * Verification of Non Components
  10. * Known Bugs
  11.  
  12. Introduction
  13. ============
  14.  
  15. JavaStar Non-Component support allows JavaStar to access non AWT based
  16. components.  During recording with a non-component module, the non-
  17. component module interprets the event and calculates the non AWT component
  18. where the event occurred.  In the recorded script the non AWT component
  19. is recorded instead of the screen coordinate.
  20.  
  21. Each non-component toolkit contains a java AWT based top level.  This
  22. is the level where the toolkit inserts all its components.  For Bongo
  23. the base component is called PlayerPanel.  For example, when recording
  24. against the Bongo widgets.gui example app, each recorded event produces
  25. JS.frame("Example Widgets").member("PlayerPanel").<statement>
  26.  
  27. Recording
  28. =========
  29.  
  30. Without non-component locators, recordings are relatively breakable. 
  31. For example clicking on a button in the Widgets.gui Bongo example without 
  32. the non-component support module produces the following JavaStar code:
  33.  
  34.  
  35.  JS.frame("Example Widgets").member("PlayerPanel").multiClick(71,66,16,1);
  36.  
  37. This statement will click on a screen location in the Bongo frame.
  38. If the Bongo layout manager moves its components around, the button
  39. will not be at recorded screen location (71,66) and the script will 
  40. no longer perform the desired behavior.  
  41.  
  42. With the non-component module, the same JavaStar recording will produce
  43. a click on a specific object:
  44.  
  45.   JS.frame("Example Widgets").member("marimba.gui.PlayerPanel").getNonComponent
  46.  ("bongo","PopupWidget.Presentation%0.FolderWidget%0.PageWidget%1.
  47.  GroupBoxWidget%3.GroupWidget%0.CommandButtonWidget%0").multiClick(5,10,16,1);
  48.  
  49. This has all the benefits associated with object-specific recording, and will 
  50. not break because of minor shifts in screen locations. 
  51.  
  52.  
  53. General Indexed Identifiers
  54. ===========================
  55.  
  56. The getNonComponent method takes two parameters.  The first is the class of the
  57. non-component locator.  After clicking on "Record test",  it is necessary to enter all
  58. non-component classes in the "Non component locator:" field.  In this example
  59. "bongo" was entered in the field to load the Bongo locator.  It is also 
  60. necessary to put the location of the locator in the classpath.   When playing 
  61. back the script and reaching a statement with .getNonComponent, JavaStar will 
  62. get the first parameter ("bongo") and look for the bongo class in the classpath.
  63.  
  64. The second parameter is the Bongo specific identifier.  The string shows the
  65. bongo hierarchy.  Each component in the hierarchy is separated by ".".  Each
  66. component class is followed by %<index>.  The index is the order in which each
  67. component was created.  "PopupWidget" is the top level in bongo and usually
  68. "Presentation%0" is the next component level.  For example CommandButtonWidget%0
  69. generates the event to the 1st button.
  70.  
  71. Internal Names
  72. ==============
  73.  
  74. Bongo allows each component to have an internal name.  This is done by calling
  75. .setName to a widget or in the Bongo builder tool setting the Name field.  
  76. JavaStar will use the internal name as long as the name is unique in the 
  77. entire bongo application.  If the name is not unique JavaStar will use the 
  78. indexed identifier.
  79.  
  80. Internal names are more reliable since they do not rely on the creation order 
  81. of the components.
  82.  
  83. For example, if the above button in the widgets.gui example had an internal name
  84. set to "ok_button", recording clicking the button would produce:
  85.  
  86. JS.frame("Example Widgets").member("marimba.gui.PlayerPanel").getNonComponent
  87. ("bongo","ok_button");
  88.  
  89. Using internal names produces more readable code since it does not have to list
  90. the entire component hiearchy.
  91.  
  92. Verification of Non-Components
  93. ==============================
  94.  
  95. With standard java components the JavaStar verification and synchronization 
  96. allows to access the simple methods of any components.  Simple methods and 
  97. fields are defined as any public methods or class instance variables that take 
  98. no parameters and return String,int,float,double,boolean, or a few java.awt 
  99. types such as Color, Point, Rectangle.  More complex methods may be called 
  100. By editing the test manually and using .getValidUnique() to get the actual 
  101. component.
  102.  
  103. Non-Components will also be fully supported in all of these verification 
  104. techniques. Verification of the bongo widgets may be done by using any of the 
  105. data members or public methods.
  106.  
  107. Known Bugs
  108. ==========
  109.  
  110. Only globally unique internal names are supported.  Hierarchical internal names
  111. are not supported.
  112.  
  113. Send any questions and comments to javastar-feedback@suntest.com.  See 
  114. http://www.suntest.com for the latest information.
  115.  
  116. Dan Schaffer
  117. 8/8/97
  118.