Ar re e w we e c cr re ea at ti in ng g A TM M o s - - PowerPoint PPT Presentation

Mani Jorda Garcia 28.3.2000 Page 1

A Ar re e w we e c cr re ea at ti in ng g J Ja av va aB Be ea an ns sT

TM M

• r

r J Ja av va a c cl la as ss se es s? ?? ?

L Le et t’ ’s s d de ef fi in ne e t th he e d di if ff fe er re en nc ce e! !! !

Mani Jorda Garcia 28.3.2000 Page 2

1 1. .

W WH HA AT T I IS S A A J JA AV VA AB BE EA AN N? ?

Reusable

software components that can be visually manipulated in builder tools to create applications.

They can be simple components, like a button, or can be more

complex software components like a calendar:

Fig 1. J avaBeans examples

Mani Jorda Garcia 28.3.2000 Page 3

2 2. .

W WH HA AT T I IS S T TH HE E D DI IF FF FE ER RE EN NC CE E B BE ET TW WE EE EN N B BE EA AN NS S A AN ND D C CL LA AS SS S L LI IB BR RA AR RI IE ES S? ?

• The difference is INTROSPECTION.
• Introspection is what builder tools use to “look inside” a

Bean and determine its properties and behavior.

• Beans publish their attributes and methods through special

method signature patterns that are recognized by beans- aware application construction tools.

• BASICALLY, JAVABEANS ARE WHAT BUILDER

TOOLS USE TO CREATE APPLICATIONS.

Mani Jorda Garcia 28.3.2000 Page 4

3 3. .

W WH HY Y D DO OE ES S T TH HE E T TO OO OL L N NE EE ED D “ “T TO O L LO OO OK K I IN NS SI ID DE E” ” T TH HE E B BE EA AN N? ?

To know which are the methods and the properties defined

in the Bean and to create the respective editors to manage those methods and properties.

Mani Jorda Garcia 28.3.2000 Page 5

4 4. . C

CO OU UL LD D I I A AD DD D M MY Y J JA AV VA AC CL LA AS SS S T TO O T TH HE E C CO OM MP PO ON NE EN NT T P PA AL LE ET TT TE E O OF F T TH HE E T TO OO OL L? ?

It is true that a Javabean is defined following standard

design patterns that the tool can recognize.

But it is also true that you CAN CREATE your Java classes,

and ADD them to the tool, even if they are not designed following the design patterns. To do so, we need to create a complementary Java class extended from BeanInfo class, defining the methods and properties we have used in our class, and add it to the tool.

Mani Jorda Garcia 28.3.2000 Page 6

5 5. . C

CO ON NS SE EQ QU UE EN NC CE ES S

Two consequences are derived from the above definitions:

1. If we use a Builder tool, it is better to think of creating Beans rather than Java classes, to take advantage of the possibilities that tools provide:

• Property editors automatically created.
• Easy management of events and listeners.
• 2. If we don’t know if we are using a tool, we can define
• ur elements as Java classes, in which case:
• Properties are read from an external file.

Later on, we could add them to the tool palette and specify the corresponding BeanInfo class.

Mani Jorda Garcia 28.3.2000 Page 7

6 6. . J

JA AV VA AB BE EA AN NS ST

TM M A

AD DD DI IT TI IO ON NA AL L I IN NF FO OR RM MA AT TI IO ON N

6 6. .1 1

J

JA AV VA AB BE EA AN NS S F FE EA AT TU UR RE ES S

• 1. They can be instantiated.

A Javaclass can be instantiated if it is neither an interface nor an abstract class. A class is an interface when it is defined like that, and it is abstract when contains any abstract method

• r variable.

Mani Jorda Garcia 28.3.2000 Page 8

• 2. They contain a constructor method, even if it is an empty

method.

• 3. They are persistent (must implement either a serializable or

externalizable interfaz).

• 4. They follow a standard design pattern defined by five rules.
• 5. They use the event delegation model.

Mani Jorda Garcia 28.3.2000 Page 9

6.2 B

BE EA AN NS S A AR RC CH HI IT TE EC CT TU UR RE E

Beans are composed of three elements: 1. Properties

• 2. Methods
• 3. Events

Properties define the attributes of the Bean. Methods are used to set the Beans properties and to

define and receive events.

Events are the vehicle between Beans, as well as

between Beans and containers.

Mani Jorda Garcia 28.3.2000 Page 10

6 6. .3 3

P

PR RO OP PE ER RT TI IE ES S

Property types

Simple (numbers, characters and strings) Boolean Array Indexed Bound Constrained

Mani Jorda Garcia 28.3.2000 Page 11

6 6. .3 3. .1 1

B

BO OU UN ND D A AN ND D C CO ON NS ST TR RA AI IN NE ED D P PR RO OP PE ER RT TI IE ES S

A Bound property is a property that notifies any

listeners of changes in the property’s value.

The listener notifies other components of changes. The listening component then has the opportunity to respond to the change in the property’s value. A Constrained property is a property in which a change

to the property value can be vetoed by another component that is listening for changes in the property’s value.

Mani Jorda Garcia 28.3.2000 Page 12

6 6. .3 3. .2 2

P PR RO OP PE ER RT TY Y E ED DI IT TO OR RS S

A property editor is an editor for changing property values at design time. They vary from one IDE to another, but typically appear as a top-level dialog box. They can edit a single property at a time or the entire component at

• nce

(which is called component customizes). Component customizers present a dialog box or panel that lets the user set many properties at once.

Mani Jorda Garcia 28.3.2000 Page 13

6 6. .4 4

M

ME ET TH HO OD DS S

They are mainly used:

• to read/write beans properties:
• get ( ), set ( ), is( ) methods
• to handle bean events:
• Notifying the actionlistener that an event has ocurred
• Implementing the action associated to that event.
• Notifying other beans.