f18c764ffa
Monotone-Revision: 9054022ef1ca8aeba6e34842d27d9b94ce002b89 Monotone-Author: dev-unix.inverse.qc.ca Monotone-Date: 2006-06-15T19:34:10 Monotone-Branch: ca.inverse.sogo
109 lines
4.3 KiB
Plaintext
109 lines
4.3 KiB
Plaintext
# $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.
|