An AppleScript to ensure that new Safari windows are opened in a tab

1. repeat
2. delay 1
3. tell application "Safari"
4. if the (count of documents) > 1 then
5. set theURL to the URL of the front document
6. if theURL is not "" then
7. close front document
8. tell front window
9. -- Safari appears to only let the front window create tabs
10. set theTab to make new tab
11. set current tab to theTab
12. set the URL of theTab to theURL
13. end tell
14. end if
15. end if
16. end tell
17. end repeat

Tags: Safari, web development, AppleScript

Persisting NSDictionary ‘documents’ into the multi–user CouchDB store across the network

NSMutableDictionary Category

1. #define COUCHDB_ID_KEY @"_id"
2. #define COUCHDB_REV_KEY @"_rev"
3. #define HTTP_METHOD_POST @"POST"
4. #define HTTP_METHOD_PUT @"PUT"
7. @implementation NSMutableDictionary (NSDictionary_FBTFCouchDB)
10. + (id)dictionaryFromDocumentStore:(NSURL *)storeURL withIdentifier:(NSString *)identifer {
11. if (!storeURL || !identifer) return nil;
12. NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:identifer relativeToURL:storeURL] cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:30.0];
13. NSError *error = nil;
14. NSURLResponse *response = nil;
15. NSData *responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:&error];
16. if (error) {
17. NSLog(@"Network Connection Error: %@", [error localizedDescription]);
18. return nil;
19. }
21. // Couch uses UTF8 encoding for transfers
22. NSString *jsonString = [[NSString alloc] initWithData:responseData encoding:NSUTF8StringEncoding];
23. if (!jsonString) return nil;
25. error = nil;
26. SBJSON *jsonParser = [[SBJSON alloc] init];
27. id result = [jsonParser objectWithString:jsonString allowScalar:YES error:&error];
29. [jsonString release];
30. [jsonParser release];
32. if (error) {
33. NSLog(@"JSON Parse Error: %@", [error localizedDescription]);
34. return nil;
35. }
36. return result;
37. }
40. - (BOOL)persistInDocumentStore:(NSURL *)storeURL {
41. // We do both inserts and updates in this method
42. NSString *methodName;
43. NSURL *requestURL;
44. if ([self objectForKey:COUCHDB_ID_KEY]) {
45. // this dictionary originated from the document database so update by including ID in URL
46. methodName = HTTP_METHOD_PUT;
47. requestURL = [NSURL URLWithString:[self objectForKey:COUCHDB_ID_KEY] relativeToURL:storeURL];
48. } else {
49. // This is a new Dictionary so we are inserting
50. methodName = HTTP_METHOD_POST;
51. requestURL = storeURL;
52. }
54. NSMutableURLRequest *aRequest = [[NSMutableURLRequest alloc] initWithURL:requestURL];
55. [aRequest setHTTPMethod:methodName];
57. NSError *error = nil;
58. SBJSON *jsonParser = [[SBJSON alloc] init];
59. NSString *argsData = [jsonParser stringWithObject:self allowScalar:NO error:&error];
61. if (error) {
62. NSLog(@"JSON Serialisation Error: %@", [error localizedDescription]);
63. return NO;
64. }
66. // Finish setting up the request and send to document store
67. [aRequest setHTTPBody: [argsData dataUsingEncoding:NSUTF8StringEncoding]];
68. NSURLResponse *response = nil;
69. error = nil;
70. NSData *responseData = [NSURLConnection sendSynchronousRequest:aRequest returningResponse:&response error:&error];
71. [aRequest release];
73. // Now parse the results
74. NSString *result = [[NSString alloc] initWithData:responseData encoding:NSUTF8StringEncoding];
75. error = nil;
76. NSDictionary *results = [jsonParser objectWithString:result allowScalar:NO error:&error];
77. if (error || [results objectForKey:@"error"]) {
79. // Something went wrong. report, clean up and return
80. if (error) {
81. NSLog(@"Can not parse results: %@", [error localizedDescription]);
82. } else {
83. NSLog(@"Database Error: %@", [results valueForKey:@"reason"]);
84. }
85. [jsonParser release];
86. [result release];
87. return NO;
88. } else {
90. // update the revision and the id (in case this is an insertion we do both)
91. [self setValue:[results valueForKey:@"id"] forKey:COUCHDB_ID_KEY];
92. [self setValue:[results valueForKey:@"rev"] forKey:COUCHDB_REV_KEY];
93. [jsonParser release];
94. [result release];
95. return YES;
96. }
97. }
100. @end

Other Possibilities & Further Development

Tags: Cocoa, REST

Taking Watershed's Cocoa desktop application to relational database communications forward

Currently…

Aims & Objectives

Option One: Enhance Exitsting Framework

Option Two: FBTFPersistentObjects with Core Data In-Memory Stores

Option Three: Core Data REST Stores

Other Considerations

Tags: Cocoa, WebObjects, XML, EOF

As our current persistent framework at Watershed needs work I’ve been thinking about shared persistent data frameworks

Tags: Cocoa, Core Data, WebObjects

Using requests with the WebObjects REST Handler for HTTP requests.

The previous post described building a new request handler allowing REST behaviour in WebObjects applications. This post will explain how the handler responds to specific requests. The current test application was built by simply, creating a new WebObjects application in Eclipse, adding a business objects framework and adding the REST handler. The test framework is the same framework that provides the foundation for www.watershed.co.uk so the examples will deal with films, screenings, seasons & festivals. The examples below use two Entities from the model, Exhibits and Programmes. Essentially, a Programme represents a season or festival of films. An Exhibit, generally, represents a film. There is a to-many relationship from Programme to Exhibits; i.e. A Programme contains a collection of Exhibits. This can be seen in use at the Watershed site. The reverse relationship is also modelled, so Exhibits have a to-one relationship to a Programme.

Rewriting

REST URLs describe the location of the resource in a hierarchy, so arguments are sent mimicking a directory structure: www.watershed.co.uk/cgi-bin/WebObjects/WatershedAPI.woa/REST/exhibits/1527 The request URLs are often written into executable code or synthesised from String components so keeping the URLs simple and short aids their use. URLs generated by the data modules are 'pretty' and incoming requests are rewritten in Apache so the previous URL becomes: api.watershed.co.uk/exhibits/1527.

Tools

Although not particular to our WebObjects REST Handler, using special tools can make testing much more efficient and pleasant. Whilst a web browser can be used to generate GET and POST requests they struggle with the other HTTP methods. Using CURL, from Terminal, can be useful, optionally adding headers to, or, setting the method or body of, the HTTP request. Typing man curl into Terminal will display a page explaining the options. RESTClient is a Java Swing application to test RESTful web services. It can be used to test variety of HTTP communications and has GUI options for most of the HTTP 1.1 specification, including setting the method, authentication values and the message body as well as viewing the response headers. RESTClient is a useful tool for any type of web application development.

REST URLs

URL Structure

Just as a WebObjects' component action URL has a structure, then URLs accepted by the REST Handler have a structure. Each action has a target and a method. The method is part of the HTTP specification and is explained later. The URL structure is essentially:

host/entity_name/primary_key/relationship/...

The entity name and the primary key together define the target. The entity names in the URLs follow a casual, but established, convention and are lower-case, underscore-separated and plural. So the URL /exhibits/1527 will map to an Exhibit Enterprise Object with a primary key value of 1527. Using the model described earlier, we can find the Programme with the primary key of 57 by using the URL: api.watershed.co.uk/programmes/57/ . As the entity name is underscore separated then to set the target for the MediaSet entity with a primary key of 1234, we can use the URL: api.watershed.co.uk/media_sets/1234.

The REST Handler uses the EOModels in the application, or linked frameworks, to map the URL to the correct Entity names and thence to a table in the database. The Handler then retreives the correct Enterprise Objects and delivers these targets to the appropriate data module for output in the response.

Relationships & Key paths

Objects in isolation are often of little practical use. Modelling real world environments requires a hierarchy of objects and containers. Creating a new season isn't useful unless we can insert films into it.

Once the target object has been established key paths defined in the model are then available. The relationship between Exhibit and Programme, illustrated in the diagram above, can now be used. To find the Programme of an Exhibit we use the URL: api.watershed.co.uk/exhibits/1527/programme/. We can follow the key path, defined in the EOModel, even further by using the to-many relationship back to an array of Exhibits: api.watershed.co.uk/exhibits/1527/programme/exhibits/. In a similar fashion to entity names, key paths in the model are renamed to maintain the pretty URLs. Although not illustrated, Exhibit has a to-many relationship to an array of MediaSets, named mediaSets. Using this relationship results in a URL similar to: api.watershed.co.uk/exhibits/1527/media_sets/.

Now that we have URLs that point to relationships, we can use these to add objects into and remove objects from collections.

Model Delegates

Comparing the illustration of the Entities, above, and the actual XML generated by a GET request displays an inconsistency. Although, attributes with null values are not currently listed, the attributes notes and history are never included. The REST Handler and the data modules use the model delegate to provide some information about how to render the data. To hide the notes and history attributes:

1. public NSArray excludeAttributesForEntity(String entityName) {
2. // Always remove notes and history regardless of
3. // the entity
4. return new NSArray(new String[] {"notes", "history"});
5. }

The use of the model delegate is optional and if the delegate is not set, the entity and attribute names will be taken from the model and adjusted.

Varying Data Representations

Outlined in the last post was a technique whereby changing the Accept HTTP header changed the response data format or allowed a client to send updated data to the web application in a variety of formats. Sending a request using cURL in Terminal shows the effect of the accept header.

curl -H 'Accept: text/xml' http://api.watershed.co.uk/exhibits/1530/
produces an XML response, whilst:

curl -H 'Accept: text/plist' http://api.watershed.co.uk/exhibits/1530/
produces a response in Apple's Property List format.

Actions

As the URL specifies the resource then the HTTP method specifies the action to perform on it. The REST Handler responds to the HTTP actions defined in the 1.1 specification. Four of the HTTP methods are mapped to the CRUD actions. The currently deployed application will not receive requests other than GET, HEAD & POST. The FreeBSD web server adapter, for watershed.co.uk applications, was compiled from the Apple source code and does not support the PUT & DELETE methods. The sites will be moving to a new virtual server in the next couple of weeks and we will compile a new adapter from the WebObjects 5.4 adapter source.

To read an Exhibit from the data store:
curl -X GET http://api.watershed.co.uk/exhibits/1530/

To delete an Exhibit from the data store:
curl -X DELETE http://api.watershed.co.uk/exhibits/1530/

To update the title attribute of an Exhibit in the data store:
curl -X PUT -d "A new title