| 
         
     
	
		 |  
		|   | 
		
		
			| 
Application Components & Component Factory framework
			 |  
			 |  
			| 
 
The web-applications are mainly consists of many screens 
or web pages; which deliver information. Also may contain form-elements (e.g.
check-boxes, radio-buttons or Text-input boxes) for end-user to enter information or send 
requests. Each web page may consist of many Application 
Components (or components on the web page). The Application 
Component or AC is a component (or presentation 
section on the web page) such as ‘weather-info’ 
or ‘stock-quote’ as shown in the figure#1 and figure#3. 
			 |  
			 |  
			| 
			 |  
			 |  
			| 
 While 
the types of ACs vary from application to application 
and are unique to each application, the process is same. 
In most web pages we can identify one or more such ACs. 
For example, CRM (Customer relationship management) 
application may present customer complaints, satisfaction 
or response time as charts, graphs and tables etc.; 
and HR (human resources) application may present organizational 
maps as hierarchical-trees and employee information/status/performance 
in a popup for each employee etc. Likewise, Air traffic control systems may
contain Flights and Games may contain animated characters such as
Race-cars. 
			 |  
			 |  
			 
  |  
			Figure#2  |  
			 |  
			
The 
Component-Factory (or "CF") approach recommends identifying such 
ACs and building a ‘CF’ (or 
Java Class) for each Application Component or AC.
The ‘ Component 
Factory’ (or CF) is nothing but a simple Java-class, 
which access appropriate data-sources (e.g. RDBMS or Wire for real-time data such as Stock-quotes) to collect data 
for the component and creates the browser specific 'Code-block' (XHTML, SVG, DOM, Jscript etc.) to present the component. 
For example, for Fig#1, the CF is nothing but a Java-class, 
which takes the user’s city-name as input, accesses 
the database for latest weather-data and creates the 
HTML-code to presents the weather AC.
   Likewise, Fig#3, 
the CF is nothing but a Java-class, which takes a ticker-symbol 
of a company as input and creates the HTML-table/SVG-charts 
code for the stock-quote AC. As shown in the Fig#2, the CF may use one or more
  reusable GUI-Classes for the charts to generate the code for the AC.  
			 |  
			 |  
			
ComponentFactory
Weather = new CF_Local_Weather(94089);
//Set ZIP-Code 
Weather.CGM ( User_Info, Out); //
Write the 'Code-block' to present the Component 
ComponentFactory Quote
= new CF_Stock_Quote( "SUNW");
//Set Ticker Symbol 
Quote.CGM ( User_Info, Out); 
//Write the 'Code-block' to present the Component  
			 |  
			 |  
			
The 
‘Java Classes’/CF created this way can be 
instantiated in any JSP/Servlet by just writing one 
or two lines of code.  Hence, the
components can be quickly interchangeable, by just replacing these
two-lines. Also, if they are implemented 
as Portlets, they can be accessed from remote web-servers 
not only to get the information but also as  
well-packaged 'code-block' for the AC. These Classes can be seen as ‘component-factory’ 
for weather AC and ‘component-factory’ for 
stock-quote respectively, because they manufacture ‘ACs’ 
at real-time as per client/browser requirement and/or 
profile. Any application, which needs weather information, 
can request the Java-class to custom create browser/user-profile 
specific AC at real-time for the city (or zip code) 
passed to it.  
			 |  
			 |  
			| 
 These 
Java-classes (or CF) are highly independent and any 
modification to them would not require any updates in 
the code that uses them to build sub-ACs.  
Hence, the Java-class can be independently refined or redesigned to meet evolving needs. 
Also such classes can be made intelligent and adaptable. 
For example, ‘stock-quote’ may access the 
user profile and customize the AC for each user by choosing 
appropriate charts as per his preferences. Hence, the 
CF not only can produce ‘AC’ but also may 
customize it as per user preferences. 
			 |  
			 |  
		| 
             Figure#3 
           |  
		 |  
		 |  
		| 
  If 
many Component Factories are built, they can be used 
in the JSP/Servlet to build components in the each page 
quickly. For example, it is possible to create a CF-class 
for stock info table, which takes ticker symbol as one 
of its input and access the latest data from data source 
to generate SVG-code to present a stock quote table. 
Likewise, CF-class to generate SVG-code to present intra-day 
stock movement chart. Once such CF’s are built, 
they can be used in a JSP file to build AC for presenting 
stock information. For example, the following pseudo-code 
listing uses CFs to create stock-info as shown in the figure#3 
		 |  
		 |  
 		 
			
				| 
 Pseudo-code listing#1   | 
				 
				
	
- <svg height="750" width="500">
 
- <%
 
- String Ticker = req.getResource("TickerSymbol");
 
- %>
 
- <g transform="translate(0,0)">
 
- // Translate (X, Y) determines the X & Y location of this Group.
 
- // You may think the SVG-Group as a Canvas to draw the component
 
- // You can draw even very complex components on this canvas.
 
- // This Canvas may contain other Canvases to draw subcomponents, 
 
- // And so on. This helps up build the component hierarchy. 
 
- <%
 
- //Write Java Code to use CF to include the AC’s code.
 
- // Instantiate & Initialize the CF
 
- AgileTemplate Table = new StockInfoTable(Ticker);
 
- // Call the method to generate and write the AC’s Code
 
- Table.CGM(ati, out);
 
- %>
 
- </g> // Close the Canvas (i.e. SVG Group).
 
- <g transform="translate(0,250)">
 
- <%
 
- AgileTemplate Chart1 = new IntraDayChart(Ticker);
 
- Chart1.CGM(ati, out);
 
- %>
 
- </g>
 
- <g transform="translate(0,500)">
 
- <%
 
- AgileTemplate Chart2 = new MonthlyChart(Ticker);
 
- Chart2.CGM(ati, out);
 
- %>
 
- </g>
 
- </svg>
 
        | 
   
				  
			 |  
			 |  
			| 
			 |  
			 |  
			| 
 Likewise, 
it is also possible to create larger-CF for comprehensive 
stock information AC. The larger-CF uses many CFs to 
build charts (or sub-ACs). For example, the following 
pseudo CGM() code shows, how larger CF may use other 
CFs to include sub-ACs. 
			 |  
			 |  
			
			
			
				|  
 Pseudo-code listing#2: Sample Code Generation Method 
				 |  
				| 
 This 
following pseudo method code listing shows, 
how one may use other Component factories or 
GUI-classes to build subcomponents. This larger 
CF could take a Ticker symbol to build a component 
as shown in the above figure. The Objects of 
this CF-Class can be used again, for example, 
to build subcomponents for a larger portfolio 
Tab-Class. The tab-component shows the company 
names as Tabs to select or to switch between 
the company-info components. 
			 |  
			
		
- int CGM (AgileInfo ati, StreamWriter out)  {
 
-  
 
- String Ticker = this.Input_TickerSymbol; 
  // Get the TICKER symbol.
 
-  
 
- // Instantiate & Initialize the CF
 
- AgileTemplate Table = new StockInfoTable(Ticker);
 
- // Call the method to generate the AC’s Code
 
- Table.CGM(ati,
  out, 0, 0, null);
 
- //Note: The
  X & Y coordinates may be passed to CGM.
 
-  
 
- // Instantiate & Initialize the CF
 
-   AgileTemplate Chart1 = new IntraDayChart(Ticker);
 
- // Call the method to generate
  the AC’s Code
 
- Chart1.CGM(ati,
  out, 0, 250, null);
 
-  
 
- // Instantiate & Initialize the CF
 
- AgileTemplate Chart2 = new MonthlyChart(Ticker);
 
- // Call the method to generate the AC’s Code
 
- Chart2.CGM(ati,
  out, 0, 500, null);
 
-  
 
- }
 
		 
			 |  
			|  
 Note:
This also shows a method to build component-hierarchy. The large component
contains a Table and two Charts. Likewise, one
could build arrays, as shown below: 
ComponentFactory CF_Array
= {Table, Chart1, Chart2}; //Array
of Components
				  |  
	| 
 Figure#4 
  
As
shown in Fig#2, CF encapsulates the tight
coupling of all the Objects and all the logics (e.g. Application,
presentation & business logics).  It needs just 2 lines of code to
include/replace an AC from webpage. If any two ACs
needs to collaborate with each other, on average they need
no more than 3 to 7 lines of communication code (e.g. to loosely couple
service-provider & service-consumer ACs).
		  |  
			  
			 |  
			 |  
			| 
 Notice, 
most online-GUI-classes (Navigational-menus, charts 
and trees etc.) contain in the Agile-Templates library 
may not be good ‘Component factories’ as 
per the definition in this document. Most components 
in the Agile-Templates library (i.e. online-GUI-API) 
require all the data to be supplied by the developer 
and do not access data on their own. Developer may use 
the classes from the GUI library to build his own CF. 
			 |  
			 |  
			| 
 The 
CF usually encloses both business logic and presentation-logic 
(e.g. one or more GUI-classes). Better designed ‘CF’ 
could not only ‘highly independent’ but 
also intelligent to effectively use user profile (client 
preferences, security/authentication etc.) to build 
personalized/customized ‘AC’ at real-time. 
To attain higher lever of Independence, the ‘Component 
factories’ should require little or no data from 
callers (or other peer components), except ‘Request’ 
and ‘Session’ objects; which may contain 
information about requesting browser, client-profile 
and/or database-connections etc. 
			 |  
			 |  
			| 
 If 
many such well designed ‘CF’ are available, 
they can be assembled to build JSP/Servlet for each 
page in hours and complex web-application in mater of 
days; or each new CF can be integrated in to any web-application 
in mater of minutes. 
			 |  
			 |  
			| 
 Please 
remember that, each ‘CF’ may use other ‘CF’ 
in the same way to build sub-ACs at run-time. For Example, 
in the Fig#3 example, the ‘CF’ for stock-quote 
may use other ‘CFs’, (each CF creates SVG-Charts 
respectively for 1Mont, 3Months, 6Months and 1Year etc.), 
and select one or more ‘sub-CFs’ by using 
simple ‘if-then-else’ statement at run-time 
as per user preferences. 
			 |  
			 |  
			
				 
				
					| 
 Pseudo Code Sample Listing#3   |  
| 
 
// One may use if-then-else to dynamically select a subcomponent. 
AgileTemplate Chart2 = null; 
If (user_preference == 1month) 
        Chart2 = new 
StockMonthlyChart(Ticker); 
else If (user_preference == quterly) 
    Chart2 
= new StockQuterlyChart(Ticker); 
else If (user_prefers_half_year) 
    Chart2 = new 
StockHalfyearlyChart(Ticker); 
else 
    Chart2 = new StockYearlyChart (Ticker); 
// Call the method 
to generate the code for the sub Application 
Component. 
Chart2.CGM(ati, out); 
// If a user wish 
to see all three, all the charts can be placed 
one after the other 
				 |  
		  
			 |  
			 |  
			| 
			 |  
			 |  
			| 
 Notice 
the two dimensions of flexibility the application designers 
have, to build highly customized applications. The first 
dimension is that it is very easy to build ‘intelligent-CF’, 
which could get each user profile and build the AC as 
per his preferences. The second dimension is that: It 
is simple to create yet another intelligent-CF that 
could choose, at run-time dynamically, a subset of such 
intelligent ACs to assemble larger customized AC; as 
per each user preferences (Ex: Use 3 months or 6 months 
stock chart) by just using simple if-then-else construct.
  
			 |  
			 |  
			| 
 The 
design objective of the “CF” is to encapsulate 
and hide the manufacturing complexity in an independent 
module (e.g. Java or C++ class). This would allow any 
one, who needs the AC can get a ready to integrate AC 
at real-time custom-built by the intelligent-CF. The 
Objective of the CF is to emulate the manufacturing 
process, where manufacturers hide the complexity of 
the manufacturing and internal complexity of the component. 
If one uses this component as a subcomponent in a larger 
component, all he needs to concern about the interfaces 
needed (e.g. to get its services) to integrate the AC 
and not much else. 
			 |  
			 |  
			| 
 
For example, consider the Battery in the Cars: 
The battery maker encapsulates all the manufacturing and functional 
complexity in a '
Replaceable-Container'
(Please review
 Appendix-A for the very important
concept 'Replaceable-Container'). Note the separation of manufacturing
and services. It allows the automakers to only concern about services to assemble
a part. Since, 
the automaker mainly relies on the external service-interfaces, 
the batter-maker preserves his freedom to innovate, 
to refine the manufacturing process, improve the performance, 
services or reduce costs. 
			 |  
			 |  
			| 
 The 
component Factory framework is nothing but, building 
simple and independent CFs/ACs (Replaceable Containers); and assemble such components 
hierarchically to build larger and larger CFs, and hence 
WebPages (or Screens) and finally the Application. 
			 |  
			 |  
			| 
 You 
may picture the process of the creating a JSP/Servlet 
for a web page is just like typesetting the printing 
machine by placing a simple call to run each ‘CF’ 
at appropriate location in the page layout (i.e. screen 
layout). The ‘CF’ manufacture custom ‘AC’ 
at real-time and places them at appropriate location 
in the web page that is under construction for each 
request from client/browser. 
			 |  
			 |  
			| 
 For 
example, if developer likes to place an AC in a cell 
of a table, just include the code for the appropriate 
‘CF’ in the cell. This code is as simple 
as including one line of code to instantiate the CF-Object, 
may be few lines to set data objects (remember, well 
designed CF might not need this data); and finally one 
line to invoke the Object’s code generation method. 
Later, if developer likes to replace the ‘CF’ 
with another ‘CF’, all he has to do is just 
replace this few lines of code with call to new ‘CF’ 
for the new AC. Also, if developer likes to select one 
of these two ‘CF’ based on user preferences, 
all he has to do is just use if-then-else construct 
to select appropriate ‘CF’ to build the 
custom ‘AC’.
  
			 |  
			 |  
			| 
 Appendix-A:
Encapsulate
in a
 
Replaceable-Container
 
(Please Click here this important
appendix is moved to a new Webpage) 
			 |  
			 |  
		  | 
			  |  
			|   |  
		 
		 |  
	 | 
       
      |