Re: Bug 1852: support creation of xmpp: field types in OGo

Hi,
[email protected] wrote: 
> On Mar 24, 2007, at 18:30, Adam Tauno Williams wrote:
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1852
> >
> > This seems useful, and overdue;  it has come up on the mailing list
> > before although I can't seem to find the thread.  It also seems  
> > related
> > to Bug#1274
> >
> > http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1274
> >
> > Outlook provides an IM address field and this is stored in the
> > im_address field of the person table.  But it doesn't seem to provide
> > any way to specify what kind of IM service is being used;  so I  
> > like the
> > Bug#1852 solution better.
> 
> Hm, yes. As mentioned IMHO an IM field is more like a phone number,  
> though thats not typed further either. The UI would need to check the  
> string contents to decide what to render.
> But I don't mind ;-)
good ;)

> > Question #1) Is there any kind of policy/philosophy with regard to
> > adding new types of extended attributes?
> 
> In general extattrs are bad because they slow down the system  
> (different relation in the DB, lots of joins, assemble/dissably in  
> the app etc).
> Eg email1 should have been company.email from the beginning (I think  
> it was added later on).
> 
> Now the questions was on "new types". Adding new types of course  
> doesn't hurt, only people using more of them does ;-)
I started with adding an xmpp: url link, but now I think it would be better 
to add sth. more generic than an xmpp link, just add,
The target attribute is used to decide whether to open the link in a new 
window or in the current window. For type 4 it defaults to _new, and for the 
rest of the types it defaults to _self.
The value stored in e.g. jabberid SkyPublicExtendedPersonAttributes of a 
person is used together with the corresponding urlpatterns from the 
OGoExtendedUrlAttributesMap Default.

Sebastian
> 
> What I always wondered is whether we are going to drop the  
> 'company_value' and use 'obj_property' like other objects. But I  
> suppose thats not going to happen in the OGo 5.x line given thats it  
> is a larger change.
> 
> 
> > Question #2) If the Bug#1852 solution is used perhaps we should  
> > consider
> > created an extended attribute type of each of the *major* IM service
> > types so a corresponding URL can be generated.  XMPP, OSCAR (AIM/ICQ),
> > MSN, SIP, YMSG (Yahoo) and Skype? (ex types 20, 21, 22, 23, 24, and  
> > 25?
> 
> Good question. Can't we just have one IM type which stores the IM  
> service URI. Like: aim:helje5?
> 
> Of course the component/element which shows the value must parse this  
> for display. And the editor might need to support the user.
> Its a bit more difficult to implement, but sounds like the better  
> option to me.
> 
> 20 would mean: URL which points to a chat identity (in every other  
> way it would be a regular URL field anyways? [do we have a URL  
> type?? ;-)])

 so I changed the patch to be able to define arbitrary link types via 
OGoExtendedUrlAttributesMap Default, for example:

        OGoExtendedUrlAttributesMap = (
            {
                type = 3;
                urlpattern = "mailto:%@";
            },
            {
                type = 4;
                urlpattern = "%@";
            },
            {
                type = 20;
                urlpattern = "xmpp:%@";
            },
            {
                type = 21;
                urlpattern = "fish://%@";
            },
            {
                type = 22;
                urlpattern = "imaps://%@";
            }
        );


SkyPublicExtendedPersonAttributes = (
            {
                key = jabberid;
                target = "_self";
                type = 20;
            },
            {
                key = anotherurl;
                target = "_new";
                type = 4;
            }
)

the ordinary url type is of type 4 (or has an attribute href) and email is 
type 3, 
I changed SkyObjectField.m to consider everything above 19 as a special link 
type, defined in OGoExtendedUrlAttributesMap, together with a definition of 
email and url type.

So this is not yet working for objects using LSWObjectViewer.m, should I add
the same there too? I am not sure whether it is really needed there.

kind regards
Sebastian

-- 
OpenGroupware.org Discussion [email protected]
http://mail.opengroupware.org/mailman/listinfo/discuss