Gebruik van drag-and-drop designer goed of slecht?

[Mastermind]

Ik was laatst in het Frijthuis in Groningen waar tweewekelijks ICT-ers bijeenkomen om te borrelen en te netwerken, en aldaar hadden we een discussie over het zogenaamde wysiwyg.

Volgens een Eclipse-gebruiker is drag-and-drop wysiwyg slecht, omdat het gebruik van een IDE die dat ondersteunt slechte en overbodige code zou produceren, en weinig aanpasbaar is.

Dat vond ik natuurlijk onzin: Het gebruik van bijvoorbeeld Visual Studio 2005 produceert bij drag-and-drop naar de designer nette code, waarbij makkelijk eventhandlers aangemaakt worden, properties en dergelijke, wat zelfs in een partial class wordt gezet.

De niet te name noemen Eclipse-gebruiker gaat als volgt te werk: Alle objecten, properties en eventhandlers handmatig intypen, en zelf de Drawing size en coordinaten invullen. En dan steeds het programma runnen om te kijken of de controls goed op het scherm staan.

Dan vraag ik me af: Wat is nou foutgevoeliger, een moderne IDE dat laten doen, of het zelf doen. Ga maar na: Je kunt heel makkelijk een property vergeten, waar de IDE wel aan denkt en automatisch erbij zet. Daarnaast kost het enorm veel tijd om zelf alle methods en properties op te zoeken, terwijl je bij VS2005 een mooi overzicht hebt en met een muisklik alle properties kunt instellen.

Want zeg nu zelf, het kost veel meer tijd, moeite en het is foutgevoeliger om de controls "handmatig" aan de Form toe te voegen dan de IDE dit zelf te laten doen. De IDE, en met name VS2005 denkt overal aan en plaatst de vereiste code netjes samen in een partial class, wat tijd bespaart en tot minder bugs leidt.

Ga maar na: Elke keer X-Y coordinaten invullen en het programma steeds laden om te kijken of het wel goed staat, is veel omslachtiger dan een control draggen en droppen in de designer, naar wens resizen en makkelijk eventhandlers en properties instellen.

[sopsop]

Het gebruik van bijvoorbeeld Visual Studio 2005 produceert bij drag-and-drop naar de designer nette code

Nou....... Da's bij asp.net iig niet het geval. Het doet iig zelden hetgeen dat ik wil doen. Zeker niet bij het wijzigen van templates. Attributen die ineens als childelements worden weergegeven e.d.

Maar het lijkt me dat dit meer thuishoort in Development Tools & Environments of Software Engineering & Architecture.

[Eskimootje]

De methode alles handmatig kost zoveel tijd dat dit nooit de juiste kan zijn, als de code zo'n zooitje word kun je natuurlijk alles eerst drag-n-droppen en daarna alle waardes daaruit overnemen.

Dat de code een zooitje zou worden maakt daarnaast niet zoveel uit aangezien dit allemaal automatisch afgehandeld word. Zou je hierin wel de mogelijkheid willen hebben om te editten is de tool gewoon niet goed genoeg.

[BasieP]

* BasieP is het met hierboven eens

bij mij geeft VS vaak slechte code. Behalve dat default properties nutteloos overbodig opnieuw geset worden, heeft hij er ook een handje van om dingen die ik in code verander weer stiekum terug te veranderen wanneer ik in design mode iets wijzig.

Dit is natuurlijk een voorbeeld, maar ik denk dat design modes enkel grafisch georienteerd moeten zijn, en niet meer dan dat.
Dus setten van vars doe je maar lekker in code, slepen van het component kan je in de design mode doen.
Trouwens nog zo'n klassiek voorbeeld.
Je hebt een form, wilt een panel docked top, een splitter en dan de rest docking mode filled.

Op het moment dat je je componenten in de verkeerde volgorde neerzet, of docking style veranderd van het verkeerde element krijg je dit met alleen de design mode niet meer goed.
Dan moet ik (.net VS2003/2005) in de code (initialize components) de volgorde van het toevoegen van elementen aan mijn form veranderen...
niet fijn..

[killercow]

Ik denk dat je al de mist in gaat zodra je uberhaupt vaste coordinaten gaat gebruiken,
In zowat elke taal kun je objecten vast op het scherm gooien, en dat lijkt ook vaak de beste manier.
Wat echter veel mooier en rustiger werkt is om alles netjes met uitlijningen en containers neer te zetten, zo weet je zeker dat het allemaal op de juiste plek float, allemaal netjes onder elkaar / naast elkaar staat en dat het nergens star in elkaar zit omdat er her en der nog vaste coordinaten staan.

Stel dat je een veld wilt toevoegen, dan zou je bij de starre versie alles moeten verschuiven en de coordinaten netjes moeten bijwerken (drag/drop, of handmatig), bij een layout met relatieve posities gaat dit gewoon allemaal vanzelf.

Hoe je dit precies het beste maakt? ik vindt gewoon netjes via de code, zo'n grafische IDE heeft vaak toch de neiging zich alsnog met de coordinaten te bemoeien.

[whoami]

Drag 'n Drop designen van de UI is goed, maar, je moet er wel voor zorgen dat je dan niet vervalt in een brij van code waarin je UI volledig verweven is met je logica, want dat is wel 'het gevaar' van een dergelijke methode.
En in VS.NET bv kan de verleiding groot zijn om bv ff snel een DataSet of een TableAdapter oid op je form te draggen. Voor quick'n dirty projectjes kan dit niet echt kwaad, maar voor grote projecten is dit niet echt een goede methode.

Je UI gaan maken door alles zelf in te typen, etc... is imho gewoon dom. Je verliest veel tijd aan iets wat je makkelijker en sneller kan doen mbhv een goede designer.

Op het moment dat je je componenten in de verkeerde volgorde neerzet, of docking style veranderd van het verkeerde element krijg je dit met alleen de design mode niet meer goed.
Dan moet ik (.net VS2003/2005) in de code (initialize components) de volgorde van het toevoegen van elementen aan mijn form veranderen...
niet fijn..

Dat krijg je met je designer wel goed hoor. Ff spelen met de z-order van de componenten (bring to front, move to back), of desnoods ctrl-x en ctrl-v gebruiken.

[whoami]

> DTE

[.oisyn]

Mastermind schreef op maandag 16 juli 2007 @ 10:47:
Volgens een Eclipse-gebruiker is drag-and-drop wysiwyg slecht, omdat het gebruik van een IDE die dat ondersteunt slechte en overbodige code zou produceren, en weinig aanpasbaar is.

Typisch geval van bevooroordeelde inductie: omdat tool X slecht is, zal het hele concept wel slecht zijn.

[Defector]

Ik denk dat je daar een goede scheiding in moet maken en niet te ver door moet slaan naar een kant. Dan kun je het beste van beide principes gebruiken. Dus lekker makkelijk een gui in elkaar slepen en ook het gemak van alles onder controle hebben in de code.

[BasieP]

whoami schreef op maandag 16 juli 2007 @ 11:11:
[...]
Dat krijg je met je designer wel goed hoor. Ff spelen met de z-order van de componenten (bring to front, move to back), of desnoods ctrl-x en ctrl-v gebruiken.

ja/nee
dwz, bringtofront werkt hier meestal niet, ctrl-x wel, maar kom op.. zoiets wil je toch niet doen in designmode?