Sunday, October 31, 2004

notes on bea workshop 8.1 page flow

--- Basically, a page flow is a directory of Web app files that work together to implement a UI feature.

--- The *.jpf file is also a BEA innovation and is the main focus of this article. It contains annotated Java code that implements the navigation and state management logic.

--- Many classes in Java Page Flow inherit from Struts classes and interoperate with the Struts plumbing that serves as the foundation for the Java Page Flow runtime.

--- All action methods are specially annotated with @jpf:action to indicate to the *.jpf compiler that they should be configured as action methods in the auto-generated Struts configuration files. Also, all action methods may be annotated with @jpf:forward to indicate to the *.jpf compiler and to the IDE tools the possible navigation decisions that the action methods may make such as deciding to forward to a page like address.jsp.

--- Because the page flow runtime makes it possible to cache state in controller instance members, it’s very easy to implement support for a back button in a wizard.

--- WebLogic Workshop makes it easy to expose business logic as controls, and the Java Page Flow feature makes it easy to call controls from action methods. Because the page flow runtime performs automatic instantiation and initialization of controls for all instance members that are annotated with @common:control, action methods in page flow controllers may call Workshop controls without having to include code that performs control instantiation and initialization. For example, the confirmation_next action method can simply and directly call the createUser( ) method of UserManager.jcs:

--- Every page flow must have a begin method. The begin method is the first method executed when your page flow is invoked by a web browser

--- Form Beans are used to separate the data presentation layer from the data processing layer of your web application. Form Beans are used as intermediaries between the data that users input into JPS pages and the Action methods. Instead of submitting the data directly to the Action method, the data is first databound to a Form Bean and this Form Bean is then passed as a parameter to the Action method. This helps to separate the presentation layer (i.e., the user input forms on the JSP pages) and the processing layer (i.e., the Action methods), because the Form Bean can play a flexible, intermediary role.

--- Page flows allow you to separate how your web application processes data from how it presents that data to users. When data processing is separated from data presentation, it's much easier to re-use the data processing aspects of the application in other contexts and to manage any future changes to your web application. Page flows link data processing and data presentation by means of databinding. Databinding is accomplished through the use of a special library of JSP tags that allow you to associate the presentation of data on the JSP pages with the data processing inside the page flow file. The special library of JSP tags begin with the prefix "netui-databinding". Two cases of databinding: (1) databinding when a user submits data, (2) databinding when data is displayed to the user.

--- A page flow is a Java class that controls the behavior of a web application through the use of specially designed annotations and methods. The directory that contains the page flow class also includes the JavaServer Pages (JSPs) used in the page flow. For a JSP to be considered part of a page flow, it must reside within the page flow directory. The JSP files use special tags which help bind to data and business logic actions. The actions in the JSP correspond to action methods that are defined in the page flow. These actions methods implement code that can result in site navigation, passing data, or invoking back-end business logic via controls. Significantly, the business logic in the page flow class is separate from the presentation code defined in the JSP files.

--- Data binding is the process that ties data to presentation tags in JSPs, thereby creating dynamic web applications that are easy to build and maintain.
--- Components of the Page Flow Programming Model
Page flows implement user interface control logic, and contain:

Action methods
Form beans - A form bean class is typically defined as an inner class within a page flow class, and in most cases extend com.bea.wlw.netui.pageflow.FormData
Forward objects

In the page flow class, action methods are methods that are annotated with a @jpf:action tag. Action methods can perform several functions:

Implement navigation decisions
Flow data into and out of pages
Invoke back-end business logic via calls to controls

--- Advantages of Using Page Flows

Ease of use
Nested page flows
State management
Rich Data binding features
Service-oriented design with Java controls
Integration with Portal
Strong data typing
Powerful exception handling
Iterative development experience
Built on the open-source Struts framework

--- When your form bean contains a complex data type, you must add a reset method to your form bean definition to ensure that an instance of the complex class is available to hold the values that the user entered in a form and subsequently submitted (posted).

Note: The reset method is called by the underlying Struts framework used by WebLogic Workshop. You do not need to call this method directly anywhere in the code.

public void reset(org.apache.struts.action.ActionMapping mapping, javax.servlet.http.HttpServletRequest request)
this.customer = new Customer(); //initialize complex class.

--- The NetUI Data Binding tags fall into one of the following categories:

Method invocation tags
Repeater tags
The CellRepeater tag
Grid tags


notes on bea workshop 8.1 control

--- controls are lightweight JavaBeans based framework with a single goal: making it easy to leverage resources in j2ee.

--- Most of the inbuilt controls are designed to generate a Java control extension (JCX) file when you add a new one to your application. The JCX file contains configuration information specific to that use of the control. You can reuse a generated JCX file in multiple applications. This kind of reuse assumes that the resources specified by the JCX file are present for each application in which it's used.

--- Not all Java controls generate a JCX file. Controls that do not must always be added as new controls. An example of such a control is the Timer Control.

--- Custom java controls are built from a Java control source file (JCS) and an interface file (JAVA) .

--- By default WebLogic Workshop adds this control file with a JCX extension to the same folder as the file that is currently open in Design View. This control file cannot be located in the root of the project. If the application is in the root of the project, you must create the built-in control in a different folder.

--- controls are javabeans and can be instantiated and used from anywhere like jsp, pageflows, JSF, web services, ejbs, and other component types.

--- For the sake of convenience, you will develop your Java control within a web application project instead of a Java control project. By developing a Java control within a web application project, it is easier to generate and use Workshop's testing devices.

--- When creating custom control, Note that two files are created: (1) a JCS file (which stands for "Java Control Source") and (2) JAVA file. The JCS file contains the implementation code for your Java control, the JAVA file contains the public interface for the underlying implementation code. The JAVA file is the public face of your Java control: it is essentially a list of methods that users can call to access the functionality contained within the underlying implementation code. For the most part, you do not have to directly edit the JAVA file, because WebLogic Workshop automatically maintains the JAVA file as your edit the JCS file.

--- A JCX file extends one of Workshop's pre-build control classes.

---- When creating controls server must be running. controls can be created without server running but it looks like that it may not show all methods. found this issue when adding jms control in the control tutorial.

--- It is necessary to separate the (Investigate) Java control from (its test) web service because web services aren't enabled in Control projects.

--- Java controls can be compiled into JAR files for general distribution to other containers.

--- Also note that once you have compiled a Java control, WebLogic Workshop uses the JAR version by default, instead of working directly from the source code contained in the control project.

--- You can use Java controls to encapsulate complex functionality.

--- Java controls can communicate asynchronously with other components.

--- Control property attribute values are stored as Javadoc annotations in source code

---- tried to use controls from the following but did not work. there was no option to do a 'new control'.

from java project (.java files have no design tab)
from ejb project (even though their was design tab)