[OGo-Discuss] Bug 1852: support creation of xmpp: field types in OGo

[Sebastian Reitenbach]

Hi,

> 
> No, I don't see why we need that many different type codes. Eg the  
> imaps and fish pattern are useless because the value still needs to  
> be structure.
Fields from type url (type = 4) are somewhere else handled specially in the 
webui, there is somewhere else always sth. like this added:
https://:443/OpenGroupware.woa/wo/4C874C870146066A04/ftp://ftp.de.openbsd.org
and clicking it, will result in an "Not Found" error.
So url fields only seem to work with http: and https: urls.

> 
> A new type only makes sense when the semantic information would be  
> useful. In all other cases its the task of the UI to process URLs in  
> a better way.
> 
> 
> Wrt to URL patterns, those should be but in the attribute  
> configuration! Eg:
>              {
>                  key        = jabberid;
>                  target     = "_self";
>                  type       = 20;
> 		urlpattern = "xmpp:%@";
>              },
> and
>              {
>                  key        = aimid;
>                  target     = "_self";
>                  type       = 20;
> 		urlpattern = "aim:%@";
>              },
> 
yes, if i see this, this would make more sense for me too.


> '20' would just mean its an IM address (having an own type for IM  
> might make sense, though I'm not entirely convinced of that either  
> since a generic URL UI can easily detect that a URL is a chat one).
as mentioned above, the url field is handled somehow special. I can define a 
ftp link with the method above, but just entering ftp://ftphost into the url 
field does not work.

> 
> Though I also dislike the urlpattern in this case. The database  
> should store the full URL, not just the value the user entered. Maybe  
> 'defaultUrlScheme' might make sense (the editor would check whether  
> the value entered by the user has a scheme and if not, would add the  
> default scheme).
well, it could be handled like this, should be easy.

> 
> Thinking about it, for the specific case of IM addresses we should  
> really use the Outlook field in the way Microsoft uses it. Its sounds  
> kinda stupid to reinvent the wheel here (how long before people ask  
> about having IM addresses in Outlook/Evolution ...)
but I see only one im_address field in the company table, how is Outlook 
using it? Would it be possible to store an arbitrary amount of arbitrary IM 
accounts that way?

> 
> 
> Hm, all that doesn't look very appealing to me. The patches are not  
> very dangerous and are great fast hacks, but IMHO the issue is not  
> thought out well enough (and I won't have the time to do it right now).
well, they are hacked up fast ;) but I think I'll drop the 
OGoExtendedUrlAttributesMap Default in favour of your suggested solution.


> So feel free to apply them, but I reserve the right to drop support  
> for that in future versions of OGo ;-)
> 

kind regards
Sebastian