I can see some of this being additive to current code, but most likely, yes.
I think that's exactly the right way to go, actually.

That all makes sense, but we should try to not add yet another 
directory-like structure. First of all, it *is* directory-like, so we 
should use path separators. (We're talking about Horde 4 here, right?)

But we already have two, sometimes different, ways to access object by 
url. There is the browser view with rewrite rules and slugs. And the 
"browse" interface that is used by webdav and obrowser. The latter 
should be used for internal referencing, because that's actually what 
obrowser is for, and the browse() methods already return the object if 
you pass it a node path.

We might want to adopt the rewrite urls for browse() too, so have the 
same directory structure in all browsing methods (internal and web 
browser).

This code will give you all apps that implement show methods:



         foreach ($GLOBALS['registry']->listAPIs() as $api) {

             if ($GLOBALS['registry']->hasMethod($api . '/show')) {

                 ...

             }

         }



(well, it will get you the 'provides' name for those apps). I think we 
need to do some work for this feature to be really useful. The show 
api method isn't really appropriate for this because it requires named 
parameters, which would be awkward:



task:id=2

task:id:2



etc.



I think what we really want is something like path-based browsing, 
with slugs, and to have slugs auto-generated where reasonable for the 
groupware apps. Calendars tend to have the same thing a lot, so that's 
tricky, but we could replace spaces with - in task and note names to 
get a reasonable guess. Combined with named shares... but you can see 
this is a bunch of changes.



For bugs it's simple:



ticket:id



now that we have queue slugs:

ticket:queue_name could probably be recognized also, though we'd be 
unable to distinguish ticket ids from queues with all-numeric slugs 
(my not-so-unreasonable example for this was a photo gallery named 
"007").



for wiki pages too, since they by nature have full slugs:



wiki:SoAndSo



could be easy for photo galleries since we have slugs there now:



photos:Baby-Pictures



etc. Any of those look good/right? Better ideas?

for the future, please upload patches as text attachments to avoid any 
issues with line wrapping, etc. - thanks!

Sorry, I meant to add a note to that patch.



OK, so this is my very rough starting point. It uses detail in the 
registry file, which identifies what each "module" provides. I hope 
I've got it right, as I'm struggling a little working out where to 
insert this call in the rendering sections.



I guess a further enhancement would be to loop through the registry, 
looking for active modules which have a "show" function in the API. 
Can someone take a look and let me know if this is possible?



Regards,



Jon

Index: Text.php

===================================================================

RCS file: /repository/framework/Horde/Horde/Text.php,v

retrieving revision 1.9

diff -r1.9 Text.php

56a57,77

That's all fine, no worries - just wanted to be sure we hadn't lost 
your interest.

Sorry about this guys. OK, status update...



Well, there's not much to offer really, but I'm writing some stuff 
into the Horde_Text called wikiLikeLinks which will be called by the 
various text-to-html functions, and uses detail in the registry to 
provide the link codes and URL destinations.



The main delay is that some personal stuff has come up since starting 
writing it, and work stuff is intruding a little as well, sorry to say.



As soon as I can get something together I will. Is there a status of 
Paused_Pending_Life_Getting_A_Little_More_Simple? :)

Ping? I know it hasn't been that long but I hope we haven't lost your 
interest on this.

Sounds a bit like http://wiki.horde.org/WikiLikeLinking



I like the idea and hope you do submit those patches.

This is something I'd like to see. Very similar to the way that Trac 
works (which I hope to be replacing for Chora + Whups + Wicked), a 
wiki entry, referring to ticket:blah will link to the whups ticket, 
where you can write "This is as per wiki:WikiPage", that refers to the 
wicked page that specifies a source:/path/to/file for chora links.



The base horde system ideally would be able to then extend this, 
allowing the author of a block to refer to 
[note:Some_People_Who_Know_About_Stuff], task:12345678 
contact:fred@bloggs.com or date:2008-05-27 or 
file:/something/something.txt for mnemo, nag, turba, kronolith and 
gollem accordingly.



There's already a degree of this in Wicked for integration with Whups, 
but it's not very easy to configure (needing knowledge of regex), and 
it doesn't work both ways.



I'll try and see if I can start putting some stuff together to get 
this working, as I'd like to move away from Trac as soon as possible :)