Skip to Content
Last modified by Pascal Robert on 2012/07/19 21:09
From version 14.1
edited by Pascal Robert
on 2010/09/19 10:29
Change comment: There is no comment for this version
To version 17.1
edited by David Avendasora
on 2011/05/03 05:36
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.probert
1 +XWiki.avendasora
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://webobjects.mdimension.com/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