Authoring summit -- September 2008

Michael Feldstein michael.feldstein at oracle.com
Mon Aug 4 01:49:57 UTC 2008


Is there a list anywhere of the major tools that are going to be least 
friendly to this approach in their current incarnations? It would be 
good to know which tools are closer to being ready and which ones 
aren't. For example, the discussion board is one that I would 
particularly like to see embeddable. It should be possible to attach a 
thread in line on just about anything.

I'm thinking it would be good to identify potential trouble spots or, if 
you like, potential targets for rework.

- m


antranig at caret.cam.ac.uk wrote:
> 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.
>
> ------------------------------------------------------------------------
>
> This automatic notification message was sent by Sakai Collab 
> (https://collab.sakaiproject.org//portal) from the DG: User Experience 
> site.
> You can modify how you receive notifications at My Workspace > 
> Preferences.

-- 


Oracle <http://www.oracle.com>
Michael Feldstein | Principal Product Manager | +1.818.817.2925
Oracle Academic Enterprise Solutions Group
23A Glendale Road, Glendale, MA 01229
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080803/2263e20f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080803/2263e20f/attachment.gif>


More information about the fluid-work mailing list