f18c764ffa
Monotone-Revision: 9054022ef1ca8aeba6e34842d27d9b94ce002b89 Monotone-Author: dev-unix.inverse.qc.ca Monotone-Date: 2006-06-15T19:34:10 Monotone-Branch: ca.inverse.sogo |
||
---|---|---|
.. | ||
common.h | ||
dbd.css | ||
dbd.m | ||
DDatabase.m | ||
DDatabase.wox | ||
DDatabaseManager.m | ||
DDatabaseManager.wox | ||
DHostView.m | ||
DHostView.wox | ||
DSoAuthenticator.h | ||
DSoAuthenticator.m | ||
DSoDatabase.h | ||
DSoDatabase.m | ||
DSoDatabaseManager.h | ||
DSoDatabaseManager.m | ||
DSoField.h | ||
DSoField.m | ||
DSoHost.h | ||
DSoHost.m | ||
DSoObject.h | ||
DSoObject.m | ||
DSoTable.h | ||
DSoTable.m | ||
DSoUser.h | ||
DSoUser.m | ||
DSoUserManager.h | ||
DSoUserManager.m | ||
DTable.m | ||
DTable.wox | ||
Frame.m | ||
Frame.wox | ||
GNUmakefile | ||
MainPage.m | ||
MainPage.wox | ||
product.plist | ||
README | ||
Version |
# $Id$ PostgreSQL Browser ================== Intention: - fix open SOPE issues - fix PostgreSQL issues, prepare low-level storage - work towards SOGo from a storage point of view (with UI-X coming down from a UI point of view) SOPE Hierarchy - /DBHOST/Databases/MYDB/MYTABLE/MYFIELD - /DBHOST/Users/MYUSER - /DBHOST/Databases/MYDB/MYTABLE/MYFIELD=MYPKEY Class Hierarchy DSoObject DSoHost "DBHOST" DSoTable "MYTABLE" DSoDatabase "MYDB" DSoDatabaseManager "Database" DSoUser "MYUSER" DSoUserManager "Users" DSoField "MYFIELD" Tricks used =========== - *always* remember that SOPE objects which are looked up in the traversal process are conceptually *UI* objects, not datamodel objects (though this might be done for simplistic applications) - the idea is: the URL is UI - small hack in MainPage.m to make a redirect to a "valid" WO URL if the request-handler-key is missing - should be made by SOPE itself? - own authenticator object - two different authenticators (with dbname available and without) - a hack in the SoApplication -lookupName: to differentiate between 'hostnames' and resources - in DSoObject we extract login/password from the basic auth - SOPE does all the authentication for SOPE level objects, but if we want to reuse passwords, we need to do that manually - we reuse an HTTP parsing method from SoHTTPAuthenticator - could -sleep to tear down transient state (not used) - -sleep is called by the SoObjectRequestHandler - Note: also supports -_sleepWithContext: - note that the EOAdaptor is created by the object, but the channel is created by the method (the component) - the object itself is not really active, the methods should be active - the distinction here is blur, in general I would avoid methods which would require an [[WOApplication application] context] - we are not really clever with DSoUserManager and DSoDatabaseManager, those two classes are basically identical - the "GET" method is explicitly mapped in product.plist for the application object because otherwise "GET" will be treated as a hostname (because we perform no check on the hostname!) - need to check whether we can make SOPE smarter on this front, but I guess that issue is inherent to all containers which map to arbitary, external collections - we could create an EOAdaptor and connect it to 'template1', but this would result in one unnecessary DB connection? - Note: this is not a problem for methods which are registered in products.plist - those are found in the SoClass. But the system checks for some keys during its traversal process (and expects getting a nil if the key does not exist). - when redirecting to the DSoHost object, we need to ensure that we add a slash - otherwise the relative URLs will be broken! - in theory SOPE should make a redirect to the default method, not sure why this isn't happening - ZideStore always makes such a redirect? - maybe any folderish object when being at the end of a traversal stack should check that? - acquisition - if you override -lookupName:inContext:acquire:, you should probably disable acquire in super calls! - otherwise all name processing code coming after the [super lookup..] is overridden by objects in the acquisition mechanism - note that acquisition is also done on the traversal path! if the lookup returns nil on an URL path being traversed, URL acquisition will occure (except on non-acquisition protocols like WebDAV) - if you have a path like '/Databases/MyDatabase/MyTable/MyField' and 'MyField' isn't processed by MyTable (eg not yet implemented), then this will return a SoDatabase object! - because acquisition will look for 'MyField' in 'MyDatabase' which will create a SoDatabase. - baseURL - calculation of base URL requires you to either override -baseURLInContext: or implement -container and -nameInContainer - enabling WebDAV - implemented -isCollection in DSoObject - per default the baseURL is broken - you need to ensure that it returns a proper value, see above - if the baseURL doesn't match the requested WebDAV URL, we run into problems, maybe need to fix something in the SOPE WebDAV layer here - a trick to stop acquisition is to return a NSException 404 code.