[Using Sakai] Portable links to tools

[Marshall Feldman]

Hi,

Andrew Petro wrote:
>> > What's the best way to obtain the URLs for [tools in the context of a particular worksite]? Can one simply open the tool in a browser and copy the path from the browser's address field?
>>   
>
> Yes.  The URL displayed when you click a page in the (typically left-hand) page listing in the context of a particular worksite will include the identifier both for that worksite and for the page within the worksite.
>
> For example,
>
> http://testdrivesakai.com/portal/site/611f18b2-53ce-442a-0019-4c17fe360888/page/e54d84e6-e89e-412c-00c7-bd1931ef48a3
>
> This hyperlink identifies the page with unique identifier e54d8... within the worksite with unique identifier 611f18...
>   
It would seem fairly simple to parse out the unique page identifier and 
the worksite identifier. Are these identifiers stable once a site has 
been configured? Even if a site administrator were to remove and then 
add back a tool, requiring the unique identifier to be updated, this 
would not be too big of a problem.
>   
>> > 2. These links have to be portable. In other words, when copying the web page from the prototype site (a project worksite) to the production site (a course worksite), the links have to point to the respective tools in the course worksite rather than to the tools in the original, project worksite used to design the course. Does Sakai have something like relative addresses for this purpose? Is there a better way to address this problem? 
>>   
>
> As I understand it:
>
> While this is an understandable requirement, it is not technically feasible to have such URLs in Sakai without customizations to the Sakai software to be more featureful in these respects.
>   
Depending on the answer above, it would seem pretty straightforward to 
make a table like the following:
Psuedo URL
	Worksite Identifier
	Unique Page Identifier
	Equivalent URL
http://Resources/Web/Forum.sak
	

611f18...

	

e54d8...

	

http://testdrivesakai.com/portal/site/611f18b2-53ce-442a-0019-4c17fe360888/page/e54d84e6-e89e-412c-00c7-bd1931ef48a3

http://Resources/Web/MasterCalendar.sak
	<some other worksite identifier>
	<another UPI>
	<constructed URL to a tool on another site>


If a site had a table like this, then a javascript inserted in a web 
page could use the table to look up the correct URL. With jQuery it 
might be $(.SakaiLinkMap).click(urlMapper) where the links have 
class="SakaiLinkMap" and urlMapper is the lookup function. One would 
simply put this in the pages $(document).ready function.

Actually, one would only need the first and fourth columns. To complete 
the second and third columns, a javascript could parse the full path in 
the fourth column. One could also construct the full URL from data in 
the second and third columns, with a blank second column implying to use 
the current site identifier. Such functions could be integrated into the 
urlMapper function to fix the table and any faulty URLs when necessary. 
An even fancier version would initialize the URL's in the table. If the 
site designer's page had an unrecognized Psuedo URL, urlMapper could 
open a dialog in a new window and instruct the designer to click on the 
tab corresponding to the Psuedo URL. When Sakai is ready, the designer 
would click an OK button in the dialog window, and urlMapper would add 
it to the table. If the URL on the page was not recognized in the Psuedo 
URL list, urlMapper would scan the list of Equivalent URLs. If it still 
did not find the URL, it would perhaps issue a warning message or a 404 
message. UrlMapper also could have an argument, oldSite, that would loop 
through the table, substitute the current site's identifier for the old 
site's (specified in oldSite), and as it's doing so, also walk the site 
designer through initializing the links for each of the psuedo URL's. 
This would only have to be done once to initialize a new site. This 
could also be done interactively from a form on a special web page.

This way, pages would be portable between sites, and there would be a 
standard, user-specific syntax for relative paths.

Am I missing something, or is this a viable strategy?


      Contact Information:


        Kingston:

202 Hart House
Charles T. Schmidt Labor Research Center
The University of Rhode Island
36 Upper College Road
Kingston, RI 02881-0815
tel. (401) 874-5953:
fax: (401) 874-5511


        Providence:

206E Shepard Building
URI Feinstein Providence Campus
80 Washington Street
Providence, RI 02903-1819
tel. (401) 277-5218
fax: (401) 277-5464
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-user/attachments/20090708/81543e6b/attachment.html