# $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.
f18c764ffa