[alg] complexere menu`s (design pattern)?

[Alarmnummer]

Ik ben nu bezig met een complexere gui en daarbij heb je dus een standaard aantal menu items, zoals help, about en exit. Maar je kan in het programma ook allerlei panels voor je neus krijgen en die panels hebben ook hun eigen menu items. Deze menu items moeten dus aan het menu toe worden gevoegd. Mijn vraag is of hier een vaste aanpak voor is. Ik kan zelf wel een opl. bedenken dus dat is niet zozeer het probleem. Maar dit komt zo vaak voor dat er wel standaarden voor gemaakt moeten zijn.

[CyberSnooP]

Wat is nu precies je probleem?
Hebben die panels een eigen menubalk of wil je die items toevoegen aan een centrale menubalk?

En wanneer veranderen je menu's? Als het panel is aangemaakt? Of als het actief is geworden?

Verder verwacht ik persoonlijk niet dat er echt standaard oplossingen voor zijn. Je kunt volgens mij gewoon zelf een eenvoudige oplossing maken die je menuitempjes toevoegd en ze eventueel tagged met een code voor jou panel. Het verwijderen zou je dan kunnen laten gebeuren door een functie te schrijven die alle menuitems met een bepaalde code als extra tag verwijderd.

[Alarmnummer]

Alle panels die hebben hun eigen menu`s items die toegevoegd moeten worden aan het centrale menu zo gauw zo`n pannel actief wordt. En ik ben dus echt op zoek naar een standaard patroon hiervoor. Een oplossing hiervoor bedenken is niet echt een groot probleem maar dit moet al zo vaak gedaan zijn dat er wel een design pattern ofzo voor moet zijn.

[Verwijderd]

OF ik begrijp je verkeerd,
OF jij bent een GUI aan het maken die niemand begrijpt....

[Orphix]

Op zondag 07 april 2002 16:00 schreef Foxboy het volgende:
OF ik begrijp je verkeerd,
OF jij bent een GUI aan het maken die niemand begrijpt....

Ja ik heb er ook wat moeite mee

Zoals ik het nu begrijp is het toch gewoon een tree?

[Alarmnummer]

Als je bv kijkt naar access dan zie je dat er andere toolbars komen als je iets anders selecteerd. Ook de menu`s die veranderen. De toolbars/menu`s zijn dus contect afhankelijk. Ik zoek dus een machanisme om de toolbar/menu context afhankelijk te vullen. Ik zoek niet zozeer naar een ad hoc oplossing (want die kan ik zelf wel in elkaar zetten) maar mijn vraag is of er hier een standaard voor is. En je moet natuurlijk bedenken hoe je met collisions om moet gaan.

[Johannes]

Eej Alarmnummer, je moet niet op alles een design pattern willen toepassen.

Je zou het natuurlijk wel met een Observer kunnen doen. Je hebt in dit geval twee observers, en meerdere subjects. Ik weet niet of dit de bedoeling is van dit pattern in GoF, maar ik pas het maar ff aan. Dan heb je dus twee Singleton's, één voor de toolbar, één voor het menu, beide ook observers. De panels's zijn subjects(of observable), en zenden dus berichten aan de observers wanneer ze geopend en gesloten worden.

[Alarmnummer]

ik zat zelf eigelijk te denken aan een interface:

code:

class MenuItemList menuItemList{
    ArrayList items;
    String menuName;
}

public interface MenuItemAskable{
   public MenuItemList[] getItems();
}

Iedere panel moet dus de MenuItemAskable interface implementeren, die een array met menu`s terug kan sturen. Dus alle fileMenu menuItems, en alle editMenu menuItems. Als er dan een Panel wordt geselecteerd dan kan het Menu worden geupdate. Een oplossing voor dit probleem vinden is niet zo lastig, maar ik ben nu eenmaal gek op design patterns

[Johannes]

Maar dan moet er nog steeds een message gestuurd worden dat het menu geupdate moet worden(het gaat alleen om een menu, geen toolbar?). Eigenlijk heb je een soort van omgekeerde Observer dan, aangezien er maar één observer is, en meerdere objecten. Dit kan je gebruiken in combinatie met de MenuItemAskable interface.
Ik zou voor zoiets gaan(je begrijpt m'n Python code vast wel). Volgens mij zitten observers trouwens al in java ingebakken, dus de eerste twee heb je niet nodig, en de andere zijn een beetje erg versimpeld.

code:

class Observer(object):
    def Update(self, arg):
      pass
      
class Observable(object):
    def __int__(self):
      self.observers = []
      
    def AddObserver(self, observer):
      if observer not in self.observers:
        self.observers.append(observer)
        
    def RemoveObserver(self, observer):
      self.observers.remove(observer)
      
    def NotifyObservers(self, arg):
      for observer in self.observers:
        observer.Update(self)
      
class Menubar(Observer):
    def Update(self, observable):
      # Doe er wat mee, afhankelijk van de observable.

class Panel(Observable):
    def __init__(self, menubar):
      self.AddObserver(menubar)
      
    def OpenPanel(self):
      self.notifyObservers()

Zo kun je ook nog andere observers toevoegen(zoals een toolbar bijvoorbeeld).

[Alarmnummer]

Op zondag 07 april 2002 18:50 schreef Johannes het volgende:
Maar dan moet er nog steeds een message gestuurd worden dat het menu geupdate moet worden(het gaat alleen om een menu, geen toolbar?). Eigenlijk heb je een soort van omgekeerde Observer dan, aangezien er maar één observer is, en meerdere objecten. Dit kan je gebruiken in combinatie met de MenuItemAskable interface.
Ik zou voor zoiets gaan(je begrijpt m'n Python code vast wel). Volgens mij zitten observers trouwens al in java ingebakken, dus de eerste twee heb je niet nodig, en de andere zijn een beetje erg versimpeld.

code:

class Observer(object):
    def Update(self, arg):
      pass
      
class Observable(object):
    def __int__(self):
      self.observers = []
      
    def AddObserver(self, observer):
      if observer not in self.observers:
        self.observers.append(observer)
        
    def RemoveObserver(self, observer):
      self.observers.remove(observer)
      
    def NotifyObservers(self, arg):
      for observer in self.observers:
        observer.Update(self)
      
class Menubar(Observer):
    def Update(self, observable):
      # Doe er wat mee, afhankelijk van de observable.

class Panel(Observable):
    def __init__(self, menubar):
      self.AddObserver(menubar)
      
    def OpenPanel(self):
      self.notifyObservers()

Zo kun je ook nog andere observers toevoegen(zoals een toolbar bijvoorbeeld).

leuk maar ik vind berichtjes versturen wel zo ongelovelijk standaard dat ik daar geen uitleg over geef. (Ik werk meestal met MVC)

[Alarmnummer]

dit is trouwens de huidige gui. Vroeger had het geneste scherm zijn eigen JDialog en vandaar dat de menu`s er nog inzitten.

[Alarmnummer]

*kick*

Ik hoop dat iemand mij hier nog even mee kan helpen. Ik heb eens wat door mijn windows applicaties zitten struinen en ik kom het vrij vaak tegen, dus daar moet een standaard voor zijn gemaakt.

[Belgar]

snap het probleem niet helemaal. in Delphi en Borland BC++ is het zeer eenvoudig. Het 'extra' item gewoon opslaan in een object, of zelfs een array en toevoegen aan de code van je panel.

pseudo:

on=@activate panel
main_menu_bar[items]->add panel_menu_items

on=@deactivate panel
main_menu_bar[items]->remove panel_menu_items

panel_menu_items is dan een object gebonden aan een panel, of zelfs dynamisch gecreerd en gevuld.

[Johannes]

Op zondag 07 april 2002 19:04 schreef Alarmnummer het volgende:

[..]

leuk maar ik vind berichtjes versturen wel zo ongelovelijk standaard dat ik daar geen uitleg over geef. (Ik werk meestal met MVC)

Sorry dat ik 't zeg, maar wat wil je dan? Ik geef een oplossing die overal hergebruikt kan worden(de essentie van Design Patterns: Elements of Reusable Object-Oriented Software). Het enige wat je nog hoeft te doen als je een nieuw panel maakt(inherited van Panel), is de interface MenuItemsAskable te implementeren en je bent klaar. Wat wil je nu nog meer?

[Alarmnummer]

Op donderdag 11 april 2002 11:10 schreef Johannes het volgende:

[..]

Sorry dat ik 't zeg, maar wat wil je dan? Ik geef een oplossing die overal hergebruikt kan worden(de essentie van Design Patterns: Elements of Reusable Object-Oriented Software). Het enige wat je nog hoeft te doen als je een nieuw panel maakt(inherited van Panel), is de interface MenuItemsAskable te implementeren en je bent klaar. Wat wil je nu nog meer?

Ik zoek eigelijk de 'vaste' oplossing voor dit soort problemen. Zoals ik al zei is een oplossing voor dit probleem niet ingewikkeld, maar dit is zo`n vaak voorkomend probleem dat er vast wel een vaste werkwijze voor is.

Bij de vaste werkwijze zijn zo ook veel voorkomende problemen tegengekomen, zoals bv collisions met menu items (meerdere items met dezelfde 'actiontext'). Wat ga je dan doen? Hier kan ik ook wel een opl voor bedenken, maar dit soort dingen moeten wel ergens uitgewerkt zijn.

wat ik dus zoek is de 'standaard' werkwijze voor dit probleem.

[Johannes]

Sja, standaard oplossing? Eigenlijk ga ik er niet echt vanuit dat die er is. Waarom creeer je niet zelf je standaard oplossing(misschien met Observers) en blijf je die gebruiken? Ik werd zelf een beetje op het verkeerde been gezet door je 'design pattern' in je onderwerp. Ik zie design patterns namelijk ietsje meer low-level dan dit. Je gebruikt design patterns om je designs samen te stellen, je design is geen design pattern.

P.S.: Als ik ff een opmerking over je GUI mag geven: ik zou geen twee menubar's gebruiken. Ik weet niet of je dat nu gedaan hebt omdat je nog een oplossing zoekt voor dynamische menubar's, maar als ik er zo naar kijk voelt het nogal onlogisch aan. Er moet gewoon 1 menubar en 1 toolbar zijn, linksbovenin.

[Alarmnummer]

Op donderdag 11 april 2002 14:43 schreef Johannes het volgende:
Sja, standaard oplossing? Eigenlijk ga ik er niet echt vanuit dat die er is. Waarom creeer je niet zelf je standaard oplossing(misschien met Observers) en blijf je die gebruiken?

Voordat ik bezig ga om zelf iets in elkaar te zetten wil ik graag weten wat er allemaal al aan standaard aanwezig is, zodat ik 'het' design kan reusen Maar ik denk dat ik zometeen wel even zelfs iets in elkaar zet want ik heb nog geen antwoord op mijn vraag.

Ik werd zelf een beetje op het verkeerde been gezet door je 'design pattern' in je onderwerp. Ik zie design patterns namelijk ietsje meer low-level dan dit. Je gebruikt design patterns om je designs samen te stellen, je design is geen design pattern.

Een design pattern hoeft niet low level te zijn, je hebt ook system design patterns. Dit zijn design patterns van een veel hoger nivo. En dit wil niet zeggen dat een design pattern van een hoger niveau niet opgebouwd kan zijn uit design patterns van een lager nivo. Je zou MVC als een design pattern van hoger nivo kunnen zien die oa wordt opgebouwd door een observer/observable design pattern van een veel lager niveau.

P.S.: Als ik ff een opmerking over je GUI mag geven: ik zou geen twee menubar's gebruiken. Ik weet niet of je dat nu gedaan hebt omdat je nog een oplossing zoekt voor dynamische menubar's, maar als ik er zo naar kijk voelt het nogal onlogisch aan. Er moet gewoon 1 menubar en 1 toolbar zijn, linksbovenin.

Dat is ook een van de redenen dat ik dit topic gestart bent