[Building Sakai] "Full-Window" Helpers

Fri Mar 20 09:25:23 PDT 2009

One query I have regarding a full window mask for the modal window, is  
that since the tool initiates it, where will the modal window be  
positioned? Most position themselves in the horizontal (and sometimes)  
vertical centre of the viewport that opened them.

So modal windows from tools in an iframe sit in the centre of the  
iframe with the rest of the iframe masked. This looks ok except the  
rest of the screen is not masked, which is one issue. The other issue  
is that a full screen mask will look odd with the modal window sitting  
in the centre of the iframe as it will appear to the right and below  
centre.

So would the modal window be positioned in the absolute centre of the  
screen, regardless of the tool iframe? If so, when it closes, focus  
will need to return to the tool iframe.

I think the solution needs to be a full screen mask with an  
appropriately positioned modal window that works well with the tool  
iframe, since it's off centre.

cheers,
Steve

---
Steve Swinsburg
Portal Systems Developer
Centre for e-Science
Lancaster University
Lancaster
LA1 4YT

email: s.swinsburg at lancaster.ac.uk
phone: +44 (0) 1524 594870

On 20 Mar 2009, at 16:14, Noah Botimer wrote:

> I will have to check back through this thread later. I think there  
> is value in solving both of these problems. My original thought was  
> that a modal would be less-favored for this specific problem. But  
> for this email...
>
> I've done this "escape the iframe" thing with SimpleModal. It was  
> kind of a pain, but it worked pretty easily and well once built. I  
> was just talking with Jim and Gonzalo here last week about this  
> issue with respect to the jQuery UI Dialog (which is what I think  
> should be in trunk, rather than jqModal -- watch the commit logs).  
> This is something we really want to do and make easy and consistent.
>
> The last time I ran through the code, they didn't support a target  
> container/document, but it may be implemented by now. I'll be  
> checking into this issue sometime soon. If it's not there, I will  
> hack it in and try to contribute it back to jQUI -- maybe with the  
> help of some of our Fluid buddies, who are certainly better with JS  
> than I am.
>
> Thanks,
> -Noah
>
> On Mar 19, 2009, at 4:35 PM, Daniel McCallum wrote:
>
>> I'm not sure that quite does it b/c the modal's display area is  
>> limited
>> to the iframe. I suppose theoretically I could have a script in an
>> iframe specify the content location for a modal container in the  
>> parent
>> frame and register trigger events with that container. I'm not a js/ 
>> css
>> expert by any means, but it's not obvious to me how one pulls off  
>> that
>> trick. If you have code examples, I'd love to have a look. Or perhaps
>> I'm just missing something obvious in jqModal?
>>
>> Thanks again.
>>
>> - Dan
>>
>> Stephen Swinsburg wrote:
>>> Hi Daniel,
>>>
>>> just implement a modal window with the contents of your helper. The
>>> background gets a mask that renders it unclickable until the modal
>>> window closes. If you have a web accessible path to you helper app  
>>> then
>>> you can supply the window with a URL to use as the contents. They  
>>> will
>>> also have an onClose handler that you can use to perform your
>>> refresh/redirect. Many JS frameworks around can do this, but trunk  
>>> is
>>> now using jqModal, so you might be best using that one. Thickbox  
>>> is also
>>> great.
>>>
>>>
>>> cheers,
>>> Steve
>>>
>>> ---
>>> Steve Swinsburg
>>> Portal Systems Developer
>>> Centre for e-Science
>>> Lancaster University
>>> Lancaster
>>> LA1 4YT
>>>
>>> email: s.swinsburg at lancaster.ac.uk <mailto:s.swinsburg at lancaster.ac.uk 
>>> >
>>> phone: +44 (0) 1524 594870
>>>
>>> On 19/03/2009, at 5:52 PM, Daniel McCallum wrote:
>>>
>>>> Hello,
>>>>
>>>> I have a requirement to render a helper tool in what amounts to
>>>> full-window mode. That is, the helper tool is launched in such a  
>>>> way
>>>> that it hides the portal's site and page navigation so that only  
>>>> the
>>>> helper's UI is clickable.
>>>>
>>>> Is there a canonical way to meet such a requirement?
>>>>
>>>> This is Sakai 2.5.x. The tool launching the helper is rendered in  
>>>> an
>>>> iframe. Both the launching tool and helper tool are SpringMVC+JSP.
>>>>
>>>> Here's my idea...
>>>>
>>>> 1) Custom portal handler or markup which generates crippled portal
>>>> chrome around the normal output (tool iframe) of /portal/page.
>>>>
>>>> 2) JS link in launching tool which directs the portal frame to
>>>> /portal/[my-handler]/{pageId}?toolstate-{toolId}={toolState} where
>>>> {toolState} triggers rendering of the helper.
>>>>
>>>> 3) On helper completion, redirect to value of  
>>>> Tool.HELPER_DONE_URL as
>>>> usual. That URL serves a response which fires a client-side  
>>>> redirect of
>>>> the portal frame to an uncrippled state with appropriate tool  
>>>> state info
>>>> ... e.g. a /portal/directtool/{toolstate} or
>>>> /portal/site/{siteId}/{pageId}?{toolstate}
>>>>
>>>> All of this seems much more difficult to get right than simply  
>>>> using
>>>> "inline" helpers as usual or just popping out a separate window.  
>>>> Am I
>>>> missing a simpler option. Am I over-worried about seen or  
>>>> unforeseen
>>>> pitfalls?
>>>>
>>>> Thank you.
>>>>
>>>> - Dan McCallum
>>>> Unicon, Inc
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> sakai-dev at collab.sakaiproject.org
>>>> <mailto:sakai-dev at collab.sakaiproject.org>
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to
>>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>>> "unsubscribe"
>>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org 
>>  with a subject of "unsubscribe"
>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2437 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090320/043524e0/attachment-0001.bin 