[OGo-Developer] ZideStore Folder Mapping Question

[Helge Hess]

On Feb 16, 2007, at 19:53, Adam Tauno Williams wrote:
> Root Question:  Can a bundle add to ZideStore folder hierarchy?

Root answer: sometimes :-)

> I'm looking at -
> http://sope.opengroupware.org/en/docs/snippets/categoryhowto.html -  
> and
> assuming that this applies to ZideStore.
> --- Example ---
> categories = {
>   OpenGroupware = {
>     slots = {
>       "Documentation" = {
>         protectedBy = "<public>";
>         valueClass  = OGoHelpDatabase;
>         value       = "Documentation/OpenGroupware.org";
>       };
>     };
>   };
> };
> --- End example from categoryhowto.html ---

This adds the given key to the object (and exposes that to the web),  
yes. But it doesn't necessarily add the object to a WebDAV PROPFIND.

> Then I look at something like
> "ZideStore/SoObjects/ZSContacts/product.plist" and:
> --- Example ---
>   categories = {
>   };
> --- End example from ZSContacts/product.plist ---

Yes, most ZideStore objects directly map keys in sourcecode, that is  
they override

   -lookupName:inContext:acquire:

However, some (all?, none? - don't know :-) still call the SoClass if  
they cannot resolve a key.

Such a check looks like:
   if ((n = [[self soClass] lookupKey:_slot inContext:nil]) != nil)
     return n;

> So then I look at -
> http://sope.opengroupware.org/en/docs/snippets/methods.html
>  - which states "When an Objective-C class is registered as a SoClass,
> SOPE scans the class hierarchy for "action" methods, pretty much  
> like in
> WODirectAction objects."  And sure enough I see that "SxAddress.m"
> contains *Action methods like "PUTAction" and "GETAction".

Yes. All methods ending in Action are exposed in addition to the keys  
defined in the product.plist.

> But SxFolder doesn't seem to be a SoObject.

SoObject is a category, so any Objective-C object is basically a  
SoObject at the same time :-)

> And SxFolders "GETAction" method seems to pretty clearly do nothing.

Yes, how should a folder respond to a GET :-)

> I see vaguely how it goes together;  but I'm not getting how a URL  
> finds
> its way to a specifc object with given parameters.

Hm, any questions left? :-) Eg:

   /zidestore/dav/helge/Contacts/Abc

does:
   next = [WOApplication lookupKey:@"helge" ...]
   next = [next lookupKey:@"Contacts" ...]
   next = [next lookupKey:@"Abc" ...]
etc. And calls an object in the chain if its a callable.

> Is it falling through to the default method as described: "Note  
> that if
> no HTTP method is found, SoMethodDispatcher will look for the "default
> method" and invoke that. This is usually preferred over direct HTTP
> implementation.";

Since ZideStore explicitly overrides GET, this 'default' lookup step  
won't happen.

> I assume I'm overlooking something obvious;  I think this would be
> easier if I had six nineteen inch displays and could look at all the
> code at once. :)

19"? The 30" somethings are just getting cheap ;-)

Greets,
   Helge
-- 
Helge Hess
http://www.helgehess.eu/