Basic Technical UI Walk Through French

[1] Apparemment, Web Objects ne fait plus partie du Framework Zoe, l'information disponible ci-dessous a donc surtout un but historique.
Note de David Medinets: Informations extraites de la liste Zoe Developer.
Lets take a closer look at SZLink as an example of how an "inspector" works:

Example

The end result of all that would be, for example, a link to a "date" that could look like this:
Generated html rendered as "Sat Jul 27"
<a title="Saturday July 27th 2002" 
href="/S/Z/ZO.E/SZ/98097B00010010D95D00EF005375CE55/2.0.5.1.1.1.
2.5.SZEnvelopeInspectorToolbar.5.1.0"><span class = "Label">Sat 
Jul 27</span></a>
HTML template
<webobject name = "Date"></webobject>
The component definition
 Date: SZLink
 {
 	value = value.creationDate;
 	class = "Label";
 };

So how does it work?

Lets take a look at SZLink more closely:

All the other SZLink methods follow the same pattern.

This turn out to be quiet a powerful setup as it let the system deal with how exactly links should be resolve and free the developer from such trivial matters. To handle a new type of object simply add a new concrete inspector and the entire system will know how do deal with it... A great time saver... :-)

This concept is used all over the places. For example there is a pretty useful table component that takes a collection of objects and a list of keys and automatically create a table out of all this information with all the right links at the right place thanks to SZLink. So to get a full blown table you simply define:

Envelopes: SZTable
 {
 	list = envelopes;
 	keysDescription = "self|recipientNames.iterator.next|sentDate";
 	headersDescription = "Subject|Recipient|Date";
 };
This is the definition used in the name inspector (SZNameInspector?.szd) to display a list of all the messages for a given "name". The "list" binding point to a collection of envelopes, "keysDescription" are the different keys (aka method names) that you want to display and the optional "headersDescription" is simply the display name for those keys. For each item in the list, the table will dynamically invoke each keys (through key value coding, check SZKeyValue?) and create an SZLink for it. In turn, SZLink will query SZInspector and figure out what should be displayed exactly... Et voila.

Now, lets take a look at a typical inspector: SZDateInspector? . This concrete inspector handles, er, date objects. In ZOE, that basically all the stuff you get when clicking on a date, the main page (which is a subclass of SZDateInspector? ), the SZListInspector? and so on.

The html template don't have much stuff in it:
information on the right side of a typical ZOE page (eg threads, contributors, ...)

The definition file ( SZDateInspector?.szd) tells you exactly what those components are and where they get their data from: 
PageLayout: PageLayout
 {
 	title = title;
 	page = name;
 	pathComponents = pathComponents;
 };
This component provides the overall layout of every single pages. It handles the header with all its elements, the footer and the content layout. The page itself (eg SZDateInspector? ) only provide the content. 
List: SZEnvelopeList
 {
 	list = envelopes;
 };

SZEnvelopeList? is a "custom made" table for displaying envelopes. It's like a table but specifically tailored for envelopes.

Month: Month
 {
 	month = value;
 };

This is the calendar component. 
ThreadList: SZList
 {
 	title = "Thread";
 	list = threads;
 	minimumSize = 0;
 };
Finally, SZList is a simple "list" component that only display one value in a list. It also handles the "more..." link and so on.

And that's it. Those are the only things you need to define to have a fully functional inspector page. There is one more component associated to an inspector: its toolbar. Check SZDateInspector? Toolbar for more details. The header component will look at runtime for a toolbar component given a page name: so for " SZDateInspector? " it will try to find a " SZDateInspector? toolbar".