323273 - Context menu for events not available

Status: RESOLVED FIXED

(Calendar :: Lightning Only, defect)

Description

[Stephan Schaefer]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Since the decorated views are used in Lightning, the context menu of events is not available anymore. Instead the view's context menu appears.

Reproducible: Always

Steps to Reproduce:
1. create new event
2. right click on it in any view
3. 

Actual Results:  
the view's context menu appears

Expected Results:  
event's context menu should appear to allow for modifying/deleting the event

Comment 1

[Stephan Schaefer]

Attachment: Makes event context menus available again.

Two things:
- the item-context attribute was not inherited by the views so they had an empty menu
- the currently selected event is a property of the view-element and not of its parent binding

Comment 2

[Joey Minta]

Comment on attachment 208360 [details] [diff] [review]
Makes event context menus available again.

+{
+    return document.getAnonymousElementByAttribute(currentView(), "anonid", "view-element" );
+}

So it seems we're stuck between a rock and a hard place here.  Asking for anonymous content is bad, but currently the decorated views don't offer any way to expose the selected item.  The decorated views were meant to be a complete shell for calendar-month-view and calendar-multiday-view.  The solution proposed here does work, but makes a crack in that shell, I see two other possible solutions:

1.) Expose a (readonly?) attribute of the decorated view that reaches in and grabs the embedded view.  This could be done fairly simply in the base-view that all the decorated views inherit.

2.) Create something like the selectionManager/observer situation that Sunbird uses for Lightning.

The second solution seems much more complex and prone to bugs, so I'd lean towards the first, especially for 0.1.  Do you agree?

Comment 3

[Stephan Schaefer]

Attachment: Avoid using anonid.

I fully agree with solution 1, see the new patch. May be this new property should be used by the other properties in the calendar-decorated-base-view implementation to avoid duplication of all the getAnonymousElementByAttribute() calls ?

Comment 4

[Stephan Schaefer]

Attachment: Just expose the selectedItem and not the embedded view.

As discussed, this patch avoids exposing the whole view to do some form of data hiding.

Comment 5

[Joey Minta]

Comment on attachment 208646 [details] [diff] [review]
Just expose the selectedItem and not the embedded view.

Thanks for the patch!  This is good stuff.  I kinda wonder why calIItemBase was already declared in the idl as an interface, but it makes your job easier. :-)
r=jminta

Comment 6

[Joey Minta]

Patch checked in.