Skip to Content
Last modified by Pascal Robert on 2012/07/19 21:09
From version 16.1
edited by Pascal Robert
on 2010/09/19 10:26
Change comment: There is no comment for this version
To version 18.1
edited by Pascal Robert
on 2012/02/11 08:39
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Web Applications-Development-WO Component-Code Template and WODs
1 +Development-WO Component-Code Template and WODs
Content
... ... @@ -1,7 +1,25 @@
1 1  == Overview ==
2 2  
3 -WebObjects was designed with a Model-View-Controller architecture. This means that your application is separated into several distinct roles. Your EOModels and their EOEntities constitute the model layer. The Views and Controllers are implemented with WOElements and WOComponents, which area spread across three different pieces: Code, Templates, and WODs. One of the things interesting aspects of WebObjects is that the component architecture does not presume to produce HTML. You can use the same component system to create HTML, XML, CSS, XSLT, emails, or any other type of dynamic data.
3 +WebObjects was created using several well-understood and powerful [[software design patterns>>http://en.wikipedia.org/wiki/Software_design_pattern]]. The most obvious pattern used by WebObjects is the [[Model-View-Controller>>http://en.wikipedia.org/wiki/Model_View_Controller]] architectural pattern. This means that code and resources in a WebObjects application are separated into two fundamental roles: //Model// and //View//. The //Controller// role may be fulfilled by Model, View or in a separate set of Controller classes or, more commonly, a little of all three.
4 +The Model portion of a WebObjects application includes:
4 4  
6 +* **EOModels** several ##.plist## files bundled together into a ##.eomodeld## package that defines an Entity-Relationship Model, including Entities, Attributes and Relationships. Originally Apple provided a diagramming tool called //EOModeler// that allowed graphical design of a Model including drag-and-drop creation of relationships, but it was deprecated along with the rest of the Apple-authored development tools when [[WOLips>>WOL:]] and became the recommended development environment.
7 +* **Entity Classes** These classes provide the core getters and setters for attributes and relationships. Custom business logic is also often added to these classes.
8 +
9 +The View portion of a WebObjects application includes:
10 +
11 +* **Components (**{{{}*.wo packages{*}{}}}**)** these are packages made up of several additional files
12 +** ##**.wod{**##} **file** this file abstracts the bindings to the ##.java## classes out of the HTML/XML/etc. definition to further separate the layout portions of the View from the code portion. Modern WebObjects applications often use in-line bindings which can replace the use of ##.wod## files, but at the cost of more tightly tying the code to the layout.
13 +** ##**.html{**##} **file** this file can be a standard ##.html## simply with the addition of ##<webobjects>## tags that bind the Component to the ##.java## class.
14 +** ##**.api{**##} **file** this file can define the API of a component that is reusable by other components, defining the available and required bindings.
15 +** ##**.woo{**##} **file**
16 +* **Component Java Classes** These classes provide the logic to provide values for the bindings defined in the ##.wod## or ##.html## files.
17 +* **Localizable.strings files** these files define the localized strings that are available to a WebObjects application that implements Localization to provide a different presentation to users that speak different languages.
18 +
19 +{{info title="Not Just HTML!"}}
20 +One of the things interesting aspects of WebObjects is that the component architecture does not presume to produce HTML. You can use the same component system to create HTML, XML, CSS, XSLT, emails, or any other type of dynamic data.
21 +{{/info}}
22 +
5 5  == Code ==
6 6  
7 7  Whether you extend WODynamicElement or WOComponent, you always have a Java class that implements your component's logic, and optionally stores its state. By default, the name of your Java class determines how you will refer to your Component throughout your application, which you will see several examples of later. There are a few key differences between implementing WODynamicElements and WOComponents.
... ... @@ -8,7 +8,7 @@
8 8  
9 9  === WODynamicElements ===
10 10  
11 -If you are building a [[WODynamicElement>>http://developer.apple.com/documentation/WebObjects/Reference/API/com/webobjects/appserver/WODynamicElement.html]], your class will not have a Template or WOD file. Any output is generated in code directly. WODynamicElements also can not assume that there will be an instance per usage, rather a single instance of your class may be concurrently serving multiple Components. As a result, your WODynamicElement must be completely thread-safe. These attributes make WODynamicElements ideal for producing relatively small output or output that is "computed." If you find yourself writing large amounts of code to handle outputting data, you may want to consider the benefits of templates that come from building WOComponents.
29 +If you are building a [[WODynamicElement>>http://wocommunity.org/documents/javadoc/WebObjects/5.4.2/com/webobjects/appserver/WODynamicElement.html]], your class will not have a Template or WOD file. Any output is generated in code directly. WODynamicElements also can not assume that there will be an instance per usage, rather a single instance of your class may be concurrently serving multiple Components. As a result, your WODynamicElement must be completely thread-safe. These attributes make WODynamicElements ideal for producing relatively small output or output that is "computed." If you find yourself writing large amounts of code to handle outputting data, you may want to consider the benefits of templates that come from building WOComponents.
12 12  
13 13  There are three primary methods that you may implement in your WODynamicElement depending on the type of interaction your element provides or requires:
14 14  
... ... @@ -100,7 +100,7 @@
100 100  
101 101  {{/code}}
102 102  
103 -which would bind the zipcode of the address of the person in your sesson to value. Even more interesting are the NSArray operations that Foundation provides. For instance, if your session had a ##public NSArray purchaseAmounts()## that returned an array of ##BigDecimal##s, you could refer to the binding ##value = session.purchaseAmounts.@sum##, which would return the sum of the values of the array. There are several other Array operations available in the Foundation classes, and Project Wonder provides even more in its [[ERXArrayUtilities>>WOnder-ERXArrayUtilities]] class. For even more advanced KVC capabilities, read the [[WOOgnl>>Project WONDER-Frameworks-WOOgnl]] section of Project Wonder.
121 +which would bind the zipcode of the address of the person in your sesson to value. Even more interesting are the NSArray operations that Foundation provides. For instance, if your session had a ##public NSArray purchaseAmounts()## that returned an array of ##BigDecimal##s, you could refer to the binding ##value = session.purchaseAmounts.@sum##, which would return the sum of the values of the array. There are several other Array operations available in the Foundation classes, and Project Wonder provides even more in its [[ERXArrayUtilities>>WOnder-ERXArrayUtilities]] class. For even more advanced KVC capabilities, read the [[WOOgnl>>documentation:Project WONDER-Frameworks-WOOgnl]] section of Project Wonder.
104 104  
105 105  A single WOD entry can contain several binding declarations, and a WOD file can contain many entries. For example, here is an excerpt from a real WOD file:
106 106