search

nl-digigo / NLCS

Technische documentatie en issues NLCS
Creative Commons Attribution 4.0 International
2 stars 0 forks source link

Gebruikerswens: Waardelijsten met bewerkingen per object publiceren in de database, plus eigen uitbreidingen toestaan #370

Open ElisabethKloren opened 6 months ago

ElisabethKloren commented 6 months ago

Waardelijsten met bewerkingen per object publiceren in de database, plus eigen uitbreidingen toestaan

Gewetensvraag: willen we bij bewerkingen ook verschillende presentaties toestaan? nu is dat per status geregeld en kun je dit dus niet bij bewerkingen toepassen Als je wilt dat de software bewerkingen herkent, moet je niet extra lijsten toestaan

Deze vraag valt uiteen in een paar delen:

  1. Willen we bewerkingen publiceren als waardelijst, per hoofdgroep / object? - dit kan goed geregeld worden in onze linkeddatabase, hoe dat dan weer platgeslagen moet worden voor degenen die nog met sql/tabellen werken weet ik niet, dus dat moeten we wel onderzoeken
  2. Willen we eigen uitbreidingen van bewerkingen door gebruikers toestaan?
  3. Willen we verschillende visuele representaties kunnen toestaan voor bewerkingen? Dan groeit in de database het aantal objecten (namelijk, een object + bewerking krijgt eigen visualisatie bij sommige statussen), dan zou de software weer slim moeten zorgen dat een gebruiker niet uit alle objecten selecteert, dat is een grotere aanpassing aan de standaard dan alleen een selectielijst toevoegen
SanderNijhof commented 5 months ago
  • Willen we bewerkingen publiceren als waardelijst, per hoofdgroep / object?

Wat mij betreft 'Ja'. Ik zie daar vooral voordelen in:

  1. minder objecten in de database, minder lagen beheren
  2. meer uniformiteit voor objecten, regelen via de database
  3. duidelijk voor de tekenaar/gebruiker

Nadeel is wel dat het aantal 'velden' per object dan met best een aantal 'kolommen' (in de excel-tabellen) uitgebreid wordt.

  • Willen we eigen uitbreidingen van bewerkingen door gebruikers toestaan?

Op zich heb ik daar niet direct wat op tegen, maar vraag me af of die nodig zijn. Lijkt mij wel lastiger voor de muteer- en controletooling en je loopt kans dat er BEWERKINGEN worden toegevoegd met verschillende namen waarmee hetzelfde bedoeld wordt. Uniformiteit/herkenbaarheid kan dan afnemen. Als de waardelijsten voor BEWERKINGEN worden toegevoegd zijn bewerkingen door NLCS-tooling duidelijker te onderscheiden en zou je eigen toegevoegde BEWERKINGEN kunnen zien als slechts informatief voor de gebruiker zelf.

  • Willen we verschillende visuele representaties kunnen toestaan voor bewerkingen?

Ja, dat is nu ook zo en dat vind ik zelf heel logisch. Als je waardelijsten voor BEWERKINGEN toepast dan groeit de database wel, maar het aantal objecten neemt af. De database groeit dan in aantal datavelden per object, voor alle objecten. Tenminste zoals ik het zie, als niet-database-kenner.

SanderNijhof commented 3 months ago

Afgelopen weekend nog een ingeving op papier gezet voor hoe keuzelijjsten/picklists voor het veld BEWERKINGEN zou kunnen werken. Heb dit snel opgezet en zeg niet dat dit dé oplossing is, maar wel iets om te overwegen of uit te werken naar iets beters.

De belangrijkste voordelen vind ik:

  1. Eenvoudig te begrijpen en gebruiken voor de gebruiker
  2. Eenvoudig uit te breiden, of weer ongedaan te maken
  3. Minimale impact op de werking van NLCS-tooling en de standaard, geen uitbreiding van de database nodig
  4. Meer info in laagnaam mogelijk, bijv. #-##-RI-GWA_RIOOLLEIDING_BETON_500-VOLSCHUIMEN-G ipv #-##-RI-OVERIG_RIOOLLEIDING-VOLSCHUIMEN-G
  5. In de database bepalen welke objecten een bewerking mogen krijgen en welke niet
  6. Afname van het aantal objecten in de database
  7. Past binnen de huidige structuur/werking van de NLCS

Nadelen zijn er ook:

  1. Laagnamen met bijv. 'op de kop' kunnen niet gevonden worden in de objectenlijst, daarin tegen is een bewerking wel makkelijker te selecteren en toe te voegen.
  2. Voor de controle tooling zie ik wel een uitdaging voor de softwareleveranciers.
  3. Je hebt altijd tooling nodig voor toepassen van lagen met een bewerking of je moet de bewerking handmatig toevoegen.

Zie bijlagen: Idee voor picklist met bewerkingen.pdf voorbeeld1.txt voorbeeld2.txt

Hierin ook voorbeelden opgenomen als mogelijke alternatieve oplossingsrichting voor issue #371

ElisabethKloren commented 2 months ago

In de NLCS Database worden op dit moment bewerkingen gepubliceerd door een laagnaam van een object, uitgebreid met de bewerking, op te nemen als "subobject / onderliggend in de hiërarchie" Dit heeft als voordeel, dat de presentatie van het object voor deze specifieke bewerking individueel kan worden aangepast, het leidt wel tot extra laagnamen in de NLCS Database.

Als er geen andere visuele presentatie nodig is, zouden bewerking in de database ook als picklist kunnen worden aangeboden om het aantal laagnamen in de database te verminderen.. (check: zijn er verschillen in presentatie voor bewerkingen, of niet?)

Huidige situatie: Omdat het veld met bewerking hiertoe is ingevuld in de database, kán men in de software een filter maken, waarbij deze laagnamen niet te zien zijn in de selectie voor de gebruiker, maar dat in plaats daarvan een picklist wordt aangeboden. Deze gebruikerswens zou dus kunnen leiden tot een nieuwe "eis aan applicaties"