Wat is de beste opzet om generieke componenten te bouwen? We moeten de mogelijkheid bieden om veel zaken aan te kunnen passen aan de wensen van de organisatie. In een aantal gevallen hebben we zelfs geen goede standaard content:
- Iconen van componenten: sluitknop van dialoogvenster, sorteerknoppen van tabelkoppen.
- Nu in sommige gevallen opgelost met een behavior, maar dat beperkt de mogelijkheden.
- Inhoud elementen van een blok: label en beschrijving van een fieldset, titel van een dialoogvenster.
- Nu in een aantal gevallen opgelost met extra modellen, maar dan kunnen er alleen zaken die met een
Label mogelijk zijn.
In alle gevallen geldt:
- Er moet een simpele API voor simpele situaties zijn.
- Er moet de mogelijkheid zijn om de inhoud volledig aan te passen.
Te bepalen:
- De meeste componenten zijn direct door alle organisaties te gebruiken. Moeten alle generieke componenten direct inzetbaar zijn? Of is het acceptabel dat organisaties een laag toe moeten voegen zodat het component binnen hun huisstijl past?
Let op: Wicket heeft een krachtig mechanisme om teksten aan te passen, maar er kan niet van uit worden gegaan dat dit in alle organisaties werkt. Rotterdam heeft in apps CMS-functionaliteit gebouwd, zodat iedere tekst zonder release aangepast kan worden. Maar hierdoor werkt de standaard wijze voor het bepalen van de tekst voor een key niet meer.
Wat is de beste opzet om generieke componenten te bouwen? We moeten de mogelijkheid bieden om veel zaken aan te kunnen passen aan de wensen van de organisatie. In een aantal gevallen hebben we zelfs geen goede standaard content:
Labelmogelijk zijn.In alle gevallen geldt:
Te bepalen:
Let op: Wicket heeft een krachtig mechanisme om teksten aan te passen, maar er kan niet van uit worden gegaan dat dit in alle organisaties werkt. Rotterdam heeft in apps CMS-functionaliteit gebouwd, zodat iedere tekst zonder release aangepast kan worden. Maar hierdoor werkt de standaard wijze voor het bepalen van de tekst voor een key niet meer.