Re: [e4-dev] Annotations vs Events and when should we extend them & Dyna

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

Am 08.11.12 07:43, schrieb Marco Descher:
> Hello Paul, Tom,
> 
> first, thanks a lot for your comments and help; regarding the discussion on Bug 389063 and 392903, please let me face this points:
> 
> @Tom I see your way of solving the problem, but to gather a deeper understanding, could you please answer the following comments/questions
> 	- A menu is to consist of both items provided by the application model and dynamic menu items which may unfold into n items. How is it 
> 	  possible given your lifecycle approach to address these dynamic elements and put them into the right order with elements already provided
> 	  by the application model or fragments?

so we'd start out with the following:
<menu label="File">
  <lifecycleuris>....MyDynamicMenuDelegate</lifecycleuris>
  <directmenuItem elementId="item.1" name="New"/>
  <directmenuItem elementId="item.2" name="Close"/>
</menu>

the menu delegate to insert items between 1 and 2 would look like this:

class MyDynamicMenuDelegate {

   @AboutToShow
   void showMenu(EModeService modelService, MMenu menu) {
      MenuElement item = modelService.findElement("item.1");
      int idx = -1;
      if( item != null ) {
        idx = menu.getChildren().indexOf(item);
      }

      List<MenuElement> elements = createDynamicElements();

      for(MenuElement e : elements) {
         e.getTags().add("dynamic");
      }

      if(idx == -1) {
         menu.getChildren().addAll(elements);
      } else {
         menu.getChildren().addAll(idx, elements);
      }
   }

   private List<MenuElement> createDynamicElements() {
      ....
   }
}


BTW the insert location could also get marked very easily using
groupMarker or separator, so it doesn't have to be a menuitem.

> 	- Where does the cleaning of the rendered menu items happen? S.t. next time the entry is called the elements are fully replaced?	
> 

See above I'd tag the menuelements and so we can find them very easily
when the menu goes down. We could also say that it's your duty to remove
the stuff you added and so you'd track the added elements in your
delegate and implement and @AboutToHide like this:

class MyDynamicMenuDelegate {
  private List<MenuElement> elements = new ArrayList<>();

  // .....

  @AboutToHide
  void hideMenu(MMenu menu) {
     menu.getChildren().removeAll(elements);
  }
}


> 	I think that your approach is good for any element else as described in your bug, but not in this specific case! I also think that those
> 	approaches are working on different levels! Adding dynamic items is not a lifecycle thing but merely a contribution of an element which
> 	unfolds into a managed set of elements!
> 

Comparing your approach is a bit easier (one does not have to find the
insert location) but I also don't think mine is overly complex, even if
we decide that the user has clean up his own.

> 	So again, I am really in favour of your solution for other elements, and by the way would be happy to discuss this on phone or personal 
> 	as I see, we are not living too far appart! :)=)
> 

I'm always available to discuss eclipse and other java topics over
frosty beverage.

> @Paul 
> Thanks for your comment in the patch! I will definitely get into each of your points, as it is really important to me that a solution for dynamic
> menu items finds its entrance into Kepler!
> 

Didn't go through all of Pauls comments but, saw that you are using
HashMaps for caching stuff. I don't think you need any of those but
store the information you need later on e.g. in the model elements.

Tom



-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834