The Use Of URLs Within Sakai

antranig at caret.cam.ac.uk antranig at caret.cam.ac.uk
Wed Feb 6 00:06:19 UTC 2008


The DOM node itself is inaccessible, like all other nodes in the
<head> area. However it is easy and reliable to update the frame
title by means of an assignment like

top.document.title = "MyTitle";

etc.

Cheers,
A.



Quoting Ian Boston <ieb at tfd.co.uk>:

> Once we get to a flatter portal then we will get this,
> since the page title is taken from the outer most iframe....
>
> I wonder what happens if you modify the DOM node for title after
> load.. or is there some other way of setting the title ?
>
> Ian
>
>
>
> On 5 Feb 2008, at 21:50, Michael S Elledge wrote:
>
> > Ian--
> >
> > Would the url be independent of the exterior wrapper? If so, I'm
> > thinking that we could generate more meaningful page titles as
> > well, such as "Edit Assignments" or "Save Resource" rather than the
> > generic "Assignments" and "Resources" titles that we have now.
> >
> > Mike
> >
> > Ian Boston wrote:
> >> There is some work in progress in the portal that impacts this and
> >> I am expecting that we *may* mount the portal as the Root webapp
> >> in the future, and allow one or more of the portal handler to
> >> break free of the static functional url space mapping and focusing
> >> much more on content.
> >>
> >> eg
> >>
> >> http://host/science/physics/physics101/mondaylabs
> >>
> >> as a site url.
> >>
> >> Test done so far indicate this will work and still allow existing
> >> urls to operate as before.
> >>
> >> Ian
> >>
> >>
> >>
> >> On 5 Feb 2008, at 17:51, Antranig Basman wrote:
> >>
> >>> As the outcome of some Framework/Kernel/Technical discussions we had
> >>> at Newport, I have put together a first draft of a page which tries
> >>> to document the URL spaces and suitable uses of all the URL schemes
> >>> we have within Sakai, and also start to make recommendations for
> >>> future usage.
> >>>
> >>> Naturally the recommendations section is particularly poorly
> >>> representative since so far only my personal viewpoint has been
> >>> taken into account, so all are invited to pitch in with their
> >>> thoughts about how we might set about improving Sakai's general
> >>> URL idiom, including but not limited to
> >>> i) the use and relationship of Entity and Portal URLs
> >>> ii) the use of tool-based URLs as opposed to more RESTful helper/
> >>>     AHAH URLs
> >>> iii) the use of URLs at all, as opposed to some information stored
> >>> in session state (as well as the ancient chestnut "tool reset"/
> >>> back button discussion)
> >>>
> >>> http://bugs.sakaiproject.org/confluence/display/SAKDEV/URLs+within
> >>> +Sakai
> >>>
> >>> (note also previous post dedicated to helpers)
> >>>
> >>> Cheers,
> >>> Antranig.
> >>> _______________________________________________
> >>> fluid-work mailing list
> >>> fluid-work at fluidproject.org
> >>> http://fluidproject.org/mailman/listinfo/fluid-work
> >>
> >> ----------------------
> >> This automatic notification message was sent by Sakai Collab
> >> (https://collab.sakaiproject.org/portal) from the DG: Development
> >> (a.k.a. sakai-dev) site.
> >> You can modify how you receive notifications at My Workspace >
> >> Preferences.
> >>
> >>
> >>
> >> <elledge.vcf>
>
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the fluid-work mailing list