Authoring summit -- September 2008

antranig at caret.cam.ac.uk antranig at caret.cam.ac.uk
Mon Aug 4 00:37:38 UTC 2008


Quoting Joshua Ryan <josh at asu.edu>:

> Opening links in a new tab/window is much much easier to implement and
> would probably be acceptable to most users, but then your users could
> end up with a bunch of tabs open at the end of a lesson and have a
> hard time figuring out where they are and/or should be.
>
> The furthest I got was similar to Aaron's second example. I was simply
> using the jquery get method to load all the content in to a div and
> then in the callback going through and altering the links in the
> content to call my portalize method (as the last thing in their
> onclick) which just cleared out the div and repeated the cycle and
> resized the iframe. That approach worked great for links that return
> only simple html content, but loading things like message center got
> very messy and that's about where I got side tracked. The issue with
> loading the right css and js, especially after the user views a few
> pages down seems like it would get pretty tricky and would require
> some substantial garbage collection to avoid css brought in for page B
> being applied to page C and js conflicts. Seems like a solvable
> problem, but one that will require some significant work and may be
> prone to occasional issues. The other option is to simplify the
> problem and require all things that want to be rendered this way to
> follow some rules about what they can have... but that could be lame.

Not so much lame, as awesome :)

Yes, there will be a little more work required than what is done in
the RSFAjaxAHAH sample that Aaron put together, but this is the basic
workflow that we want. Stripping out the head/body material with a
bunch of regexps and re-injecting them into the global <head> in a
traceable way is what we are after - this has also been demonstrated
in outline to be possible (the injection part) in the Camtools
Widgets set and just needs to be orchestrated a bit.

In terms of "require all things that want to be rendered this way to
follow some rules" is exactly the set of guidelines that we are trying
to draw up in Fluid in any case. Javascript should be properly namespaced,
as well as being multiple-include resistant and if possible version
tagged, as well as portal-safe in all the usual ways. We are fortunate
in that we are starting from a "safe baseline" - all the things that
we might seek to aggregate in this way are either

i) EntityBroker worlds (which are almost all currently written in RSF
and hence follow some basic rules on markup, URL semantics etc.)
OR
ii) Camtools-style widgets, which follow a naming layout that
also guarantees some basic safety (namespacing has been being followed
and afaik all use a fixed version of JQuery etc.).

So we will not be struggling here to impose order on a bunch of
random junk (e.g. JSF tool output) that could never be kicked into
some kind of shape. Fluid is actively working on ensuring we can both
find ways of expressing the rules that things should follow, and also
providing a framework for following them easily - for example here is the
page explaining strategies for versioning
http://wiki.fluidproject.org/display/fluid/Versioning+the+Fluid+Framework
and here is the JIRA where multiple version resistance will be tracked
for inclusion in the next 0.5 release for Fluid:
http://issues.fluidproject.org/browse/FLUID-1078
which is a required deliverable for portalised environments like uPortal
in any case.

There is further advice for portal-safety of Javascript in section 2 of
the following docs page:

http://wiki.fluidproject.org/display/fluid/DHTML+Developer+Checklist

Yes, I agree that perhaps in the very short term, we might want to just
put together a popup-based approach - either in tabs, or else perhaps
in a dialog/thickbox style using perhaps (gasp!) a temporary frame.
For things like message centre, this will probably be all we can ever
do with it... until it becomes either Entitised or JSONified (possibly
both).

> /Josh
>
> On Sun, Aug 3, 2008 at 3:43 PM, John Norman <john at caret.cam.ac.uk> wrote:
> > The experience in the first box is a little strange (the one you call
> > normal behaviour :-) ). I click on an item in box 1, I go to the item
> > in a full page (ok, but now I have lost my context), but then I click
> > to return to the table and although it does what it says on the tin
> > (return to table) I expected to return to the page I had come from
> > ('cos that is what 'return' means to me).
> >
> > The behaviour in the second box looks more interesting/useful. It
> > would be good to have a more fully functioning demo with real items...
> >
> > Note: I still think the Google fix is the easiest in the short term -
> > open links in a new tab. There you just close the tab to return.
> >
> > Thanks
> > John
> >
> > On 3 Aug 2008, at 22:18, Aaron Zeckoski wrote:
> >
> >> Here is a little example of how it might work to do the AHAH stuff.
> >> http://ponder.org.uk/RSFAjaxAHAH/faces/main
> >>
> >> It is not perfect in that this deals in html snippets and does not
> >> have to strip away the extra html elements but it is the concept that
> >> I want to demonstrate here. Conceptually we are dropping the view of
> >> some data (an entity for example) into the page and then continuing to
> >> control the navigation as if the thing were inside an iframe (when it
> >> is actually not).
> >>
> >> I think it should just be a matter of applying the right JS libraries
> >> and calls to the current stuff you have Josh.
> >> -AZ


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




More information about the fluid-work mailing list