Closed Bug 323273 Opened 14 years ago Closed 14 years ago

Context menu for events not available

Categories

(Calendar :: Lightning Only, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: stephan.schaefer, Unassigned)

Details

Attachments

(1 file, 2 obsolete files)

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
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
Attachment #208360 - Flags: first-review?(jminta)
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?
Attached patch Avoid using anonid. (obsolete) — Splinter Review
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 ?
Attachment #208360 - Attachment is obsolete: true
Attachment #208560 - Flags: first-review?(jminta)
Attachment #208360 - Flags: first-review?(jminta)
As discussed, this patch avoids exposing the whole view to do some form of data hiding.
Attachment #208560 - Attachment is obsolete: true
Attachment #208646 - Flags: first-review?(jminta)
Attachment #208560 - Flags: first-review?(jminta)
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
Attachment #208646 - Flags: first-review?(jminta) → first-review+
Patch checked in.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.