Glenn,
This is a good start for a discussion about this though I
wonder if it
might be too large a scope to start with for implementation.
I would recommend a smaller initial implementation that
allows for the
following:
1) Linking to tool B from within tool A
2) Linking to site D from within tool A in site C
I think it would be ideal for developers if we could do the
following:
1) Ask for the relative URL to a tool in a site like so:
String url = SomeToolService.getSiteTool(siteId).getUrl();
2) Ask for the URL to an item in a tool in a site like so:
String url =
SomeToolService.getSiteTool(siteId).getItem(itemId).getUrl()
;
Then maybe I would put the portal URL (e.g.
http://sakai.school.ed
u/portal) in front of that relative url and tack
on a get variable to the end and now I have a URL which
loads correctly
regardless of the starting point.
Ideally, I would use a service to create this URL so I am
not assembling
it myself. The service function should be implemented by
whatever portal
is being used.
For example, this would create a URL string that would take
the user to
an item in a site with the portal rendered correctly
regardless of their
current location. It could be used to link from another tool
or even to
create a link that could be sent out via email:
String toolItemUrl =
SomeToolService.getSiteToolItem(siteId).getUrl();
String url = PortalService.makeExternalUrl(toolItemUrl);
An example URL in a web-based portal might be:
http://sakai.school.edu/portal/site/1234
/tool/12345/item/123456/?externa
l=1
I am sure that I do not understand this as well as you do
Glenn but from
a tool developer perspective this makes sense.
Thoughts? Is this totally crazy?
-AZ
--
Aaron Zeckoski (aaronz vt.edu)
Lead Developer - Learning Technologies - Virginia Tech
> -----Original Message-----
> From: Glenn R. Golden [mailto:ggoldenumich.edu]
> Sent: Wednesday, May 10, 2006 11:32 PM
> To: sakai-dev
> Subject: Sakai Tool Destinations
>
> For those of you interested in the internal
navigational URL space of
> tools, and how tools might cause a change in the portal
site or page
> displayed, or might even redirect the user to some
other tool in some
> specific state...
>
> I'm working on support for this. My current thoughts
are in this
> very rough draft document:
>
>
http://collab.sakaiproject.org/access/content/group/
> 1097928811887-22636/Architecture%20Docs/Sakai%202.2/
> sakai_tool_destinations.pdf
>
> I'm posting it like this to get early feedback.
There's more to
> come. I'm attempting to get basic support for this
working in the
> next few days, as part of 2.2. No guarantees that
I'll make it.
>
> The unfortunate part of this is that most of our tools
do not use
> this mechanism now, so we won't be able to control
them as described
> in the document. But once support is in, we can change
the existing
> tools to work this way, and more and more of them can
collaborate in
> this way.
>
> I've also got some simple sample servlet based tools
in the /samples
> module, which you can checkout and check out. Number 2
is designed
> to have the destinations as described in the
document... more to come.
>
> - Glenn
>
> Glenn R. Golden
> Software Architect, University Of Michigan
> ggoldenumich.edu
>
>
>
> ----------------------
> This automatic notification message was sent by Sakai
Collab
> (http://collab.s
akaiproject.org/portal) from the DG: Development site.
> You can modify how you receive notifications at My
Workspace >
> Preferences.
----------------------
This automatic notification message was sent by Sakai Collab
(http://collab.s
akaiproject.org/portal) from the DG: Development site.
You can modify how you receive notifications at My Workspace
> Preferences.
|