• [ << ]
  • [ 0 ]
  • [ 1 ]
  • [ 2 ]
  • [ 3 ]
  • [ >> ]
Oct '03
05

Layout Managers v.s. Absolute Positionering

In Java worden Layout managers gebruikt voor het positioneren van componenten. De reden hiervoor is dat Java op verschillende platformen moet kunnen draaien en dat de componenten niet altijd even groot hoeven te zijn. FlowLayout Manager Er zijn hele eenvoudige zoals de FlowLayout (plaatst componenten van links naar rechts en van boven naar beneden) en hele ingewikkelde zoals de GridBagLayout - het beste te vergelijken met een GridBagLayout Manager dambord waarop je kunt specificeren hoeveel vlakken een component mag omvatten en in welke hoek die mag staan. Door zijn veelzijdigheid wordt deze veel gebruikt in GUI teken pakketten. Het resulteert dan ook in onleesbare genereerde code.

Hoe anders gaat het toe in de wereld van Visual Basic. Je plaatst een component op het scherm en daar staat ie. Standaard gepositioneerd relatief ten opzichte van de linker boven hoek van het paneel waar die op staat. Dus verander je de grootte, dan blijft ie staan. Dat is niet altijd wat je wilt hebben, dus kan dat eenvoudig aangepast worden door het component relatief ten opzichte van de rechter kant of de onderkant te positioneren, zodattie wel mee beweegt. Knip.Plak.Property.Property. Klaar.

Uiteraard kan je in Java prima absoluut positioneren door geen gebruik te maken van een layout manager (de zogenaamde null layout) Echter dan kan je alleen componenten plaatsen ten opzichte van de linker boven hoek en dat niet echt de bedoeling.

Wat dan wel? Ik kan me een aantal dingen voorstellen. Bijvoorbeeld het maken van je eigen layout manager die het gedrag van de Delphi's en VBs van deze wereld nadoet. Zeg maar een AlignmentLayoutManager waarbij je per component kan aangeven ten opzichte van welke zijkant hij mee moet bewegen. Zo'n layout manager valt wel in een dag in elkaar te zetten, alleen schiet je er ook iets mee op ? Waarschijnlijk niet als je GUI teken pakket niet met zelfgemaakte layout managers kan omgaan, want dan moet je zelf alle posities gaan uitrekenen. Zucht. Nu ja, er is nog een alternatief en dat staat hieronder :-)

Investeer in herbruikbaarheid.

Jajajaja hoor ik de sceptici nu denken. Herbruikbare code. Vergeet het maar. En het klopt, heel vaak wordt iets geschreven en gebruikt en daarna aangepast en veranderd en specifiek gemaakt en daarna dus onbruikbaar om opnieuw te gebruiken. Hoera. TooManyDependenciesException. Maar goed, daar heb ik het dus niet over.

Kleine groeperingen van classes zonder dependencies. Een paar panelen in elkaar met de juiste Layout Managers en wat utility methods om snel componenten toe te voegen. Daarnaast kant en klare veel voorkomende GUI logica. Voor serieuze winsten is het goed om de grafische user interface te standaardiseren. Zorg dat alle schermen op een min of meer zelfde manier werken en er uit zien. Doe 80 % van het werk in 20 % van de tijd. Gebruik de tijd die je over hebt om je generieke klassen generiek te houden en zorg dat ze van commentaar voorzien zijn. Dat is altijd handig iemand anders ze ook eens her gebruikt.

Conclusie

Uit de hier bovenstaande overpeinzingen zou je de volgende regels kunnen destilleren voor een beter Java GUI ontwikkel proces. Het maken van user interfaces in Java hoeft echt geen disaster area te zijn.

  • Denk van te voren na over de schermen en hoe ze functioneren.
    • Overleg met de gebruiker(s) hoe zij willen werken.
    • Teken de schermen van te voren.
    • Ontwerp op panel niveau, niet op scherm niveau.
  • Maak een wel overwogen keuze tussen de mogelijke Java GUI systemen.
    • Inventariseer de benodigde GUI widgets. (knoppen, menu's, tabellen etc.)
    • Bepaal de noodzaak voor een 100 % Java oplossing.
  • Coach mensen met minder ervaring. Laat ze niet zelf alles opnieuw uitvinden.
    • Gebruik 'boeren verstand' regeltjes zoals: "als je extends typt, kom dan even langs"
    • Maak gebruik van een 'coding standard'.
  • Investeer in herbruikbaarheid en bouw een reeks van standaard componenten op.
    • Standaardiseer veel voorkomende panelen zoals panelen met knoppen en panelen met lijsten van labels + editors.
    • Identificeer schermen die visueel op elkaar lijken en bouw daar gestandaardiseerde panelen voor. Plaats (nog) geen besturings logica in die panelen, enkel de visuele compositie.
    • Standaardiseer veel voorkomende event handlers en models.
    • Documenteer ze!

Erik Hooijmeijer is senior developer bij Twee-en-Veertig. Naast ruime ervaring op het gebied van Java en Windows GUI's is hij ook een ervaren bouwer en ontwerper van bedrijfs kritische applicaties. Erik verzorgt trainingen en presentaties op het gebied van Java. Zijn email adres is
  • [ << ]
  • [ 0 ]
  • [ 1 ]
  • [ 2 ]
  • [ 3 ]
  • [ >> ]