[C#] Dynamisch aanpassen controls

[Big Joe]

Zoals jullie vast en zeker weten komt het als ontwikkelaar vaak voor dat we code schrijven waarvan je denkt, zou dat nou niet makkelijker kunnen? Ik ben nu op mijn werk bezig met geavanceerde software, waarbij je de waardes van form controls dynamisch moet kunnen aanpassen. Dit klinkt niet heel erg ingewikkeld, maar zoals jullie hieronder aan de code kunnen zien zit het nog best lastig in elkaar. Dit is mijn code:
ObjectValue (baseclass)

C#:

public abstract class ObjectValue
{
    /// <summary>
    /// Readonly property for setting the Text property of a TextBox (needed for reflection)
    /// View http://msdn.microsoft.com/en-us/library/system.windows.forms.textbox%28v=vs.71%29.aspx for details
    /// </summary>
    protected readonly string _TextPropertName = "Text";

    /// <summary>
    /// Private property that sets or returns the private variable _Content
    /// </summary>
    private char[] _Content;
    protected string Content {
        get {
            if (_Content == null) {
                new NullReferenceException("Content property cannot be null");
            }
            return new string(_Content);
        }
        set {
            _Content = value.ToCharArray();
        }
    }
}

TextBoxValue class:

C#:

public class TextBoxValue : ObjectValue
{
    /// <summary>
    /// Private variable that store the TextBox
    /// </summary>
    private TextBox _TextBox;

    /// <summary>
    /// Private property that sets or returns the private _TextBox
    /// </summary>
    private TextBox TextBox
    {
        get
        {
            if (_TextBox == null)
            {
                throw new NullReferenceException("TextBox property cannot be null");
            }
            return _TextBox;
        }
        set
        {
            _TextBox = value;
        }
    }

    /// <summary>
    /// Constructor for TextBoxValue class
    /// </summary>
    /// <param name="textBox">The Textbox that should correspond to the TextBoxValue class</param>
    public TextBoxValue(TextBox textBox)
    {
        TextBox = textBox;
    }

    /// <summary>
    /// Sets the value of the textbox with the specified string
    /// </summary>
    /// <param name="content">The content to show in the textbox</param>
    public void SetTextBoxValue(string content)
    {
        // Story value in private variable
        Content = content;

        // Set value to the textbox
        PropertyInfo propertInfo = typeof(TextBox).GetProperty(_TextPropertName);
        propertInfo.SetValue(TextBox, Content, null);
    }

    /// <summary>
    /// Returns the textbox that corresponds with the specified TextBoxValue class
    /// </summary>
    public TextBox GetTextBox()
    {
        return TextBox;
    }
}

Om de waardes dynamisch aan te passen gebruik ik nu bijvoorbeeld de volgende code:

C#:

public Form1()
{
    InitializeComponent();

    TextBoxValue value = new TextBoxValue(textBox1);
    value.SetTextBoxValue("GoT rules");
}

TextBoxValue is een door mij gemaakte class die door middel van reflection de waarde van een textbox kan aanpassen. Het resultaat van de bovenstaande code is dat textbox1 de tekst "GoT rules" krijgt. Op zich werkt deze code goed, maar ik moet nu wel voor ieder type control (label, textbox etc) een eigen class maken, wat natuurlijk niet handig is aangezien er aardig wat verschillende controls zijn.

Ik zit eraan te denken om het op te lossen door middel van generics, dus dat je bijvoorbeeld zoiets zou kunnen doen:

C#:

public Form1()
{
    InitializeComponent();

    ObjectValue<TextBox> value = new ObjectValue<TextBox>(textBox1);
    value.SetTextBoxValue("GoT rules");
}

Ik weet niet zeker of dit de beste oplossing is, wat voor design pattern zouden jullie hiervoor gebruiken?

[DEiE]

Wellicht snap ik niet helemaal wát je probeert te bereiken, maar je kan toch gewoon

C#:

textBox1.Text = "GoT rules";

gebruiken?
TextBox erft over van Control, welke de property Text heeft. Ook Label, etc. implementeren Control. Je zou dus (niet bekend met Windows Forms) tegen de abstracte Control aan kunnen praten om deze waarden te zetten op een TextBox, Label, etc. zonder dat je het concrete type hoeft te weten, of reflection nodig hebt.

[ Voor 33% gewijzigd door DEiE op 08-08-2012 15:54 ]

[pedorus]

Ik heb ook geen flauw idee waar al die code voor dient en waarom je reflection nodig zou hebben hier

Wat is het concrete probleem dat je probeert op te lossen?

[ Voor 23% gewijzigd door pedorus op 08-08-2012 15:55 ]

[upje]

Volgens mij probeer je iets simpels heel moeilijk te doen.

Trouwens: waarom zou je een NullReferenceException willen gooien bij het getten van een property?
Waarom zou je een string in een char[] willen opslaan?

[BM]

Wow.... ik zie wel wat je aan het doen bent, maar.... waarom in godesnaam is een me een volslagen raadsel.

[Verwijderd]

Je bent het wiel aan het heruitvinden vrees ik.
Heb je de documentatie die je in je codevoorbeeld noemt al eens goed bekeken?

Daar is ondermeer het volgende te zien:


Hieruit kan je afleiden dat TextBox (en de andere klassen zoals Label) hiervan overerven. In de klasse Control zijn een hele hoop zogenaamde properties te vinden waaronder de Text-property. Hiermee kan je gewoon de tekst instellen:

C#:

Textbox1.Text = "blaat"
Label1.Text = "blaat"

Neem nog eens een kijkje naar de andere methods en properties binnen de Control-klasse, en ik ben zeker dat je een hele hoop leuke zaken tegen komt!

[Woy]

Ik snap net als bovenstaande posters niet wat je nu eigenlijk probeert te doen, en waarom je niet gewoon de property van het control zet?

Verder zou ik eens naar MSDN: Windows Forms Data Binding kijken als ik jou was. Daarmee kun je veel flexibeler de waardes van controls aanpassen, zonder dat je bij elke control je code weer compleet aan moet passen.

[Phyxion]

Wat je probeert te doen is mij een compleet raadsel. Al eens naar databinding gekeken?

[Hydra]

15 jaar ervaring, jaja

[beany]

Misschien is het idee om elke content op elk control te kunnen zetten, en daar 1 uniforme interface voor te hebben?

Meest wazige code die ik de afgelopen maanden heb gezien overigens... Meer uitleg wat je precies wilt doen is welkom!

[Hydra]

Ik snap het probleem niet. Je kunt doorsimpel door controls en childcontrols itereren als dat nodig is. Het is doodsimpel vast te stellen van welk type een control is (TextBox, CheckBox, etc.). En het is ook doodsimpel om van een daarvan (of allemaal) de waardes aan te passen.

[.oisyn]

Big Joe schreef op woensdag 08 augustus 2012 @ 15:34:

C#:

public abstract class ObjectValue
{
    private char[] _Content;
    protected string Content {
        get {
            if (_Content == null) {
                new NullReferenceException("Content property cannot be null");
            }
            return new string(_Content);
        }
        set {
            _Content = value.ToCharArray();
        }
    }
}

Waarom sla je de content eigenlijk op in een char array?

[Big Joe]

Bedankt voor al jullie suggesties! Aan jullie reacties te zien heb ik mijn probleem blijkbaar nog niet helemaal goed uitgelegd, dus ik zal nog wat achtergrond informatie geven. Ik heb een database tabel met de volgende kolommen:
ID (INT PRIMARY KEY),
FormId (INT NOT NULL)
ControlId (NVARCHAR(100) NOT NULL)
Property (NVARCHAR(100) NOT NULL)
Value(TEXT NOT NULL)

Er zit ook een UNIQUE CONSTRAINT op de combinatie van de kolommen ControlId en Property. Hiermee kan ik dus een beheerscherm maken voor gebruikers, waarmee ze de properties van controls kunnen aanpassen zonder hulp van de programmeurs! In eerste instantie wordt het alleen mogelijk om de Text property van controls aan te passen, maar later kunnen we het ook zo maken dat de gebruikers andere properties ook kunnen aanpassen, zoals bijvoorbeeld de kleur.

Voorbeeldrow in database: formid = 1, controlid = textbox1, property = Text, value = GotRules

Jullie suggesties waren erg hulpvol, zo had ik bijvoorbeeld de Control baseclass helemaal over het hoofd gezien! Dankzij jullie hulp ben ik nu op de volgende code uitgekomen:

C#:

public class ControlValueClass {
    /// <summary>
    /// Private property that sets or returns the private variable _Control
    /// </summary>
    private Control _Control;
    public Control Control {
        get { return _Control; }
        set { _Control = value; }
    }

    /// <summary>
    /// Constructor for ControlValueClass class
    /// </summary>
    /// <param name="control">The Control that should correspond to the ControlValueClass class</param>
    public ControlValueClass(Control control) {
        this.Control = control;
    }

    /// <summary>
    /// Sets the value of the specified property with the specified value
    /// </summary>
    public void SetPropertyValue (string propertyName, string propertyValue) {
        // Set value to the specified property of the control
        PropertyInfo propertInfo = typeof(Control).GetProperty(propertyName);
        propertInfo.SetValue(Control, propertyValue, null);
    }
}

Nu kan ik het als volgt doen:

C#:

public partial class Form1 : Form {
    private int formid = 1;

    public Form1()
    {
        InitializeComponent();

        // Get all the controls and properties and set them!
        foreach (DataRow row in DbHelper.ExecuteSql("SELECT * FROM ControlProperties WHERE FormId = " + formid)) {
            ControlValueClass controlValue = new ControlValueClass(GetControl(row["ControlId"].ToString()));
            controlValue.SetPropertyValue(row["Property"].ToString(), row["Value"].ToString());
        }
    }

    public Control GetControl(string controlName) {
        PropertyInfo propertInfo = typeof(Form1).GetProperty(controlName);
        return (Control)propertInfo.GetValue(this, null);
    }
}

De bovenstaande code in het form krijg ik echter niet aan de praat. Ik heb bijvoorbeeld een control die textBox1 heet, maar als ik dan de functie GetControl("textBox1") aanroep krijg ik een nullreference terug, omdat propertInfo altijd null is. Heeft iemand een idee waar dit aan zou kunnen liggen?

[GateKeaper]

Big Joe schreef op donderdag 09 augustus 2012 @ 12:21:
...
Dankzij jullie hulp ben ik nu op de volgende code uitgekomen:
...
Nu kan ik het als volgt doen (nog niet volledig getest):
...
De bovenstaande code in het form krijg ik echter niet aan de praat.
...

Heb je 't nu wel of niet getest dan? Als je het niet test, is het nogal logisch dat je het niet aan de praat krijgt?

[Big Joe]

GateKeaper schreef op donderdag 09 augustus 2012 @ 13:27:
[...]


Heb je 't nu wel of niet getest dan? Als je het niet test, is het nogal logisch dat je het niet aan de praat krijgt?

Ik bedoelde eigenlijk meer dat dit nog een work-in-progress is. Het lijkt mij in ieder geval nog niet te lukken om de controls dynamisch op te halen door middel van reflection.

[Hydra]

Big Joe schreef op donderdag 09 augustus 2012 @ 12:21:
De bovenstaande code in het form krijg ik echter niet aan de praat. Ik heb bijvoorbeeld een control die textBox1 heet, maar als ik dan de functie GetControl("textBox1") aanroep krijg ik een nullreference terug, omdat propertInfo altijd null is. Heeft iemand een idee waar dit aan zou kunnen liggen?

Aangezien "textBox1" geen property van de Form class is, is het nogal wiedes dat je null terugkrijgt lijkt me?

Elke Control heeft een Controls property, dat is een ControlCollection object met de kindcontrols. Als je daar een textbox met naam "textBox1" inzet kun je deze met de .Find() methode terugvinden.

Big Joe schreef op donderdag 09 augustus 2012 @ 13:34:
Ik bedoelde eigenlijk meer dat dit nog een work-in-progress is. Het lijkt mij in ieder geval nog niet te lukken om de controls dynamisch op te halen door middel van reflection.

Relfection heb je dus ABSOLUUT niet nodig. Sterker nog, het is een oplossing voor een probleem dat je niet hebt.

[ Voor 19% gewijzigd door Hydra op 09-08-2012 14:19 ]

[Big Joe]

Heb het inmiddels opgelost met de volgende verandering in de GetControl method.

C#:

/// <summary>
/// Gets the control with the specified name
/// </summary>
public Control GetControl(string controlName) {
    FieldInfo fieldInfo = typeof(Form1).GetField(controlName, BindingFlags.NonPublic | BindingFlags.Instance);
    return (Control)fieldInfo.GetValue(this);
}

Hydra schreef op donderdag 09 augustus 2012 @ 14:19:
[...]


Aangezien "textBox1" geen property van de Form class is, is het nogal wiedes dat je null terugkrijgt lijkt me?

Elke Control heeft een Controls property, dat is een ControlCollection object met de kindcontrols. Als je daar een textbox met naam "textBox1" inzet kun je deze met de .Find() methode terugvinden.


[...]


Relfection heb je dus ABSOLUUT niet nodig. Sterker nog, het is een oplossing voor een probleem dat je niet hebt.

Reflection heb ik nodig omdat de namen van de properties uit de database worden geladen. Zo zou ik in mijn database bijvoorbeeld deze row kunnen hebben:
formid = 1, controlid = textbox1, property = Text, value = GotRules

Met reflection kan ik de waarde van de kolom "property" dynamisch houden, zodat gebruikers in het beheerscherm van de applicatie ook andere properties dan Text zouden kunnen aanpassen.

[Hydra]

Big Joe schreef op donderdag 09 augustus 2012 @ 14:25:
Reflection heb ik nodig omdat de namen van de properties uit de database worden geladen. Zo zou ik in mijn database bijvoorbeeld deze row kunnen hebben:
formid = 1, controlid = textbox1, property = Text, value = GotRules

Met reflection kan ik de waarde van de kolom "property" dynamisch houden, zodat gebruikers in het beheerscherm van de applicatie ook andere properties dan Text zouden kunnen aanpassen.

Het ging me om de naam van de control, niet om de naam van de property van een control. Een control kun je ophalen met de Find methode aan de hand van z'n naam. Jouw methode om reflection te gebruiken om controls te vinden gaat niet werken omdat je je set controls dynamisc op gaat bouwen. Op dit moment is een control misschien een property in je Form1 class, maar dat werkt niet meer als je at-runetime controls toe gaat voegen.

Persoonlijk lijkt me verder reflection nogal overkill omdat je volgens mij helemaal gebruikers niet willekeurige properties wil laten aanpassen maargoed, dat mag je zelf uitvogelen.

[ Voor 13% gewijzigd door Hydra op 09-08-2012 14:40 ]

[Big Joe]

Hydra schreef op donderdag 09 augustus 2012 @ 14:38:
[...]


Het ging me om de naam van de control, niet om de naam van de property van een control. Een control kun je ophalen met de Find methode aan de hand van z'n naam. Jouw methode om reflection te gebruiken om controls te vinden gaat niet werken omdat je je set controls dynamisc op gaat bouwen. Op dit moment is een control misschien een property in je Form1 class, maar dat werkt niet meer als je at-runetime controls toe gaat voegen.

Persoonlijk lijkt me verder reflection nogal overkill omdat je volgens mij helemaal gebruikers niet willekeurige properties wil laten aanpassen maargoed, dat mag je zelf uitvogelen.

Er is tijdens het ontwerpproces samen met de klant afgesproken dat hiervoor reflection gebruikt zou worden, dus hier heb ik geen invloed op. Aangezien we het agile waterval model gebruiken kan dit niet meer herzien worden, pas in een eventuele tweede sprint van de ontwikkelcycle. Bovendien is het nog niet de bedoeling dat gebruikers controls at runtime kunnen toevoegen, dit zouden we wel in een latere fase kunnen implementeren.

[ Voor 3% gewijzigd door Big Joe op 09-08-2012 15:00 ]

[hostname]

Big Joe schreef op donderdag 09 augustus 2012 @ 14:58:
Er is tijdens het ontwerpproces samen met de klant afgesproken dat hiervoor reflection gebruikt zou worden, dus hier heb ik geen invloed op.

Wut?! Jullie laten de klant, die niet technisch onderlegt is en waarschijnlijk geen idee heeft wat reflection uberhaupt is, de implementatiedetails bepalen? Ik denk dat je daar dan toch echt een groter probleem hebt dan het vastblijven houden aan je eigen verkeerde oplossing.

Er is namelijk geen enkele geldige technische reden om dit niet te gebruiken:

C#:

/// <summary>
/// Gets the control with the specified name
/// </summary>
public Control GetControl(string controlName) {
    return this.Controls.Find(controlName, true).FirstOrDefault(); 
}

Het is sneller, gebruikt minder code (dus minder kans op fouten), code is beter leesbaar, werkt ook als er later wel dynamisch controls toegevoegd gaan worden, etc...

[Hydra]

Big Joe schreef op donderdag 09 augustus 2012 @ 14:58:
Er is tijdens het ontwerpproces samen met de klant afgesproken dat hiervoor reflection gebruikt zou worden, dus hier heb ik geen invloed op. Aangezien we het agile waterval model gebruiken kan dit niet meer herzien worden, pas in een eventuele tweede sprint van de ontwikkelcycle. Bovendien is het nog niet de bedoeling dat gebruikers controls at runtime kunnen toevoegen, dit zouden we wel in een latere fase kunnen implementeren.

Agile waterval. Lol!

Ik geloof er geen zak van dat een gebruiker dit bepaald heeft. Je bedoelt dat een of andere techneut dit bedacht heeft, maargoed. Ben je nu klaar? Al die extra classes die je in je OP postte heb je dus helemaal niet nodig.

hostname schreef op donderdag 09 augustus 2012 @ 15:06:
Het is sneller, gebruikt minder code (dus minder kans op fouten), code is beter leesbaar, werkt ook als er later wel dynamisch controls toegevoegd gaan worden, etc...

Hij wil de gebruiker ook willekeurige properties van die control laten setten. Waarom je dat zou willen is me een raadself, maargoed. Laat 'em maar, hij heeft in vorige topics niet echt aangegeven erg geinteresseerd te zijn in adviezen die tegen zijn huidige oplossingsrichting ingaan.

[ Voor 26% gewijzigd door Hydra op 09-08-2012 15:10 ]

[pedorus]

Het lijkt me dat je daar de Controls collection prima toe kan gebruiken.

Maar is het allemaal niet wat ondynamisch wat er aangepast kan worden op deze manier? Als je daadwerkelijk een dynamische oplossing wil hebben, dan lijkt het me beter om C# als een complete scriptingtaal aan te bieden. Op die manier kun je niet alleen eenvoudige types aanpassen, maar zo'n beetje alles. Met behulp van http://www.csscript.net/h...ween_script_and_host.html kun je vrij makkelijk de boel transponeren, en met wat post processing zou je prima aan logging kunnen doen.

Overigens kun je natuurlijk ook voor compatibiliteitsredenen deze methode tijdelijk blijven gebruiken. Op zich kan dit zonder wrapper. Je krijgt dan iets als, even om het idee aan te geven:

C#:

namespace ScriptDomain
{
    public interface OnLoadScript
    {
        void ApplyStyles(Form form);
    }
}
[...]
private void Form1_Load(object sender, EventArgs e)
{
    foreach (DataRow row in DbHelper.ExecuteSql("SELECT * FROM ControlProperties WHERE FormId = " + formid))
    {
        var compiler = new Microsoft.CSharp.CSharpCodeProvider();
        var options = new System.CodeDom.Compiler.CompilerParameters()
        {
            GenerateExecutable = false,
            GenerateInMemory = true
        };
        options.ReferencedAssemblies.AddRange(AppDomain.CurrentDomain.GetAssemblies()
                .Where(a => !a.IsDynamic).Select(a => a.Location).ToArray());
        var result = compiler.CompileAssemblyFromSource(options,
            "using System.Windows.Forms;" +
            "public class Script : ScriptDomain.OnLoadScript {" +
            "    public void ApplyStyles(Form form) {" +
            "        dynamic c = form.Controls[\"" + row["ControlId"].ToString() + "\"];" +
            "        c." + row["Property"].ToString() + " = \"" + row["Value"].ToString() + "\";" +
            "    }" +
            "}");
        ((ScriptDomain.OnLoadScript)result.CompiledAssembly.GetExportedTypes().First()
            .GetConstructor(System.Type.EmptyTypes).Invoke(null)).ApplyStyles(this);
    }
}

Let op dat dit vooralsnog geen rekening houdt met uitzonderingssituaties. En je moet ook rekening houden met het Inner-Platform Effect natuurlijk.

Laat maar weten wat het geworden is

Edit:Disclaimer: Dit is een geavanceerde post, en is zeker niet aan te raden om te lezen voor beginners! Er zouden dingen verkeerd kunnen gaan anders.

[ Voor 4% gewijzigd door pedorus op 09-08-2012 16:24 ]

[Hydra]

pedorus schreef op donderdag 09 augustus 2012 @ 15:09:
Let op dat dit vooralsnog geen rekening houdt met uitzonderingssituaties. En je moet ook rekening houden met het Inner-Platform Effect natuurlijk.

Maar je brengt 'em ondertussen wel op een idee dat precies dat bewerkstelligt? Je moet wel HELE goeie redenen hebben om gebruikers scripts te laten schrijven. Die zijn vrijwel niet fatsoenlijk te debuggen namelijk en als developer wordt je er wel verantwoordelijk voor gemaakt.

[alex3305]

Ik snap misschien het probleem niet helemaal, maar mocht je met vaste controls werken of dynamische controls dan zou ik het zo doen:

Vaste controls met variabele tekst
Vaste namen geven waardoor je dus - net zoals hierboven wordt gezegd - gemakkelijk controls op kunt zoeken en deze de juiste waarden mee kunt geven.

Variabele controls met variabele tekst
Zoeken of een control al bestaat - zoals hierboven wordt gesuggereerd - en mocht deze nog niet bestaan, dan gewoonweg door één of meerdere methodes de juiste control aanmaken aan de hand van database-informatie.

---

Probeer overigens eens goed gebruik te maken van properties in plaats van veredelde getters en setters:

C#:

public string Foo { get; set; }
public string Bar { get; private set; }

is meer als voldoende.

[Hydra]

alex3305 schreef op donderdag 09 augustus 2012 @ 15:18:
Probeer overigens eens goed gebruik te maken van properties in plaats van veredelde getters en setters:

C#:

public string Foo { get; set; }
public string Bar { get; private set; }

is meer als voldoende.

Bah, nieuwerwetse meuk

[farlane]

alex3305 schreef op donderdag 09 augustus 2012 @ 15:18:

---

Probeer overigens eens goed gebruik te maken van properties in plaats van veredelde getters en setters:

C#:

public string Foo { get; set; }
public string Bar { get; private set; }

is meer als voldoende.

Is compiler pruttel rondom dat wat de TS zelf doet, dus ik zie niet in hoe dat 'goed gebruik' zou moeten zijn,

[.oisyn]

Het verschil is natuurlijk dat bij de code van alex3305 in een oog te zien is dat hij gewoon default getters en setters heeft. In de code van de TS wordt je van de wijs gebracht omdat hij ze expliciet implementeert maar toch hetzelfde doet.

[pedorus]

Hydra schreef op donderdag 09 augustus 2012 @ 15:12:
Je moet wel HELE goeie redenen hebben om gebruikers scripts te laten schrijven. Die zijn vrijwel niet fatsoenlijk te debuggen namelijk en als developer wordt je er wel verantwoordelijk voor gemaakt.

Producten zoals Google Docs, Microsoft Office en SAP doen aan scripts van gebruikers. Wellicht lastig om te beheren/debuggen, maar ik zou die producten niet onsuccesvol willen noemen.

farlane schreef op donderdag 09 augustus 2012 @ 15:50:
Is compiler pruttel rondom dat wat de TS zelf doet, dus ik zie niet in hoe dat 'goed gebruik' zou moeten zijn,

OSCON 2010: Rob Pike, "Public Static Void"
Overbodige tekst lijdt af van waar het om gaat.

[Hydra]

pedorus schreef op donderdag 09 augustus 2012 @ 16:10:
Producten zoals Google Docs, Microsoft Office en SAP doen aan scripts van gebruikers.

Zoals ik zei; als je hele goeie redenen hebt. Die heeft de TS vooralsnog niet.

[Verwijderd]

Big Joe schreef op donderdag 09 augustus 2012 @ 14:58:
[...]


Er is tijdens het ontwerpproces samen met de klant afgesproken dat hiervoor reflection gebruikt zou worden, dus hier heb ik geen invloed op.

Waarom heeft jouw klant (die hier waarschijnlijk niets van kent, anders maakte hij het gewoon zelf) inspraak in de techniek / manier waarop jullie de oplossing maken?

[roy-t]

Big Joe schreef op donderdag 09 augustus 2012 @ 14:58:
[...]
Aangezien we het agile waterval model gebruiken

Na deze opmerking zijn er maar 2 opties:

1: Je loopt expres onze tijd te verdoen en probeert semi-grappig te zijn

Of 2: Je gebruikt willekeurige interessante termen door elkaar heen en hebt geen idee wat het betekend

In geval van optie 1: ga lekker ergens anders tijd verdoen, dit hele topic is niet grappig.

In geval van optie 2: lees je alsjeblieft in waar je het over hebt. 1000 jaar ervaring, of niet, agile waterval is een contradictio in terminis. Normaal wat termen door elkaar halen geeft niet maar je hele ontwikkel process hangt af van het snappen wat agile is en wat waterval is en hoe deze twee stromingen compleet het tegenovergestelde van elkaar zijn.

[alwinuzz]

Hoezo kan agile waterfall niet? Lijkt me toch een combinatie van best practices in de software developmentwereld.
Als je met iteraties werkt dan doe je toch aan agile? En dan kan binnen de iteratie alles worden vastgelegd volgens het waterfall model. Als je iets wil veranderen kan dat altijd in de volgende iteratie.

spoiler:

Grapje...

[Big Joe]

pedorus schreef op donderdag 09 augustus 2012 @ 15:09:
Het lijkt me dat je daar de Controls collection prima toe kan gebruiken.

Maar is het allemaal niet wat ondynamisch wat er aangepast kan worden op deze manier? Als je daadwerkelijk een dynamische oplossing wil hebben, dan lijkt het me beter om C# als een complete scriptingtaal aan te bieden. Op die manier kun je niet alleen eenvoudige types aanpassen, maar zo'n beetje alles. Met behulp van http://www.csscript.net/h...ween_script_and_host.html kun je vrij makkelijk de boel transponeren, en met wat post processing zou je prima aan logging kunnen doen.

Overigens kun je natuurlijk ook voor compatibiliteitsredenen deze methode tijdelijk blijven gebruiken. Op zich kan dit zonder wrapper. Je krijgt dan iets als, even om het idee aan te geven:

C#:

namespace ScriptDomain
{
    public interface OnLoadScript
    {
        void ApplyStyles(Form form);
    }
}
[...]
private void Form1_Load(object sender, EventArgs e)
{
    foreach (DataRow row in DbHelper.ExecuteSql("SELECT * FROM ControlProperties WHERE FormId = " + formid))
    {
        var compiler = new Microsoft.CSharp.CSharpCodeProvider();
        var options = new System.CodeDom.Compiler.CompilerParameters()
        {
            GenerateExecutable = false,
            GenerateInMemory = true
        };
        options.ReferencedAssemblies.AddRange(AppDomain.CurrentDomain.GetAssemblies()
                .Where(a => !a.IsDynamic).Select(a => a.Location).ToArray());
        var result = compiler.CompileAssemblyFromSource(options,
            "using System.Windows.Forms;" +
            "public class Script : ScriptDomain.OnLoadScript {" +
            "    public void ApplyStyles(Form form) {" +
            "        dynamic c = form.Controls[\"" + row["ControlId"].ToString() + "\"];" +
            "        c." + row["Property"].ToString() + " = \"" + row["Value"].ToString() + "\";" +
            "    }" +
            "}");
        ((ScriptDomain.OnLoadScript)result.CompiledAssembly.GetExportedTypes().First()
            .GetConstructor(System.Type.EmptyTypes).Invoke(null)).ApplyStyles(this);
    }
}

Let op dat dit vooralsnog geen rekening houdt met uitzonderingssituaties. En je moet ook rekening houden met het Inner-Platform Effect natuurlijk.

Laat maar weten wat het geworden is

Edit:Disclaimer: Dit is een geavanceerde post, en is zeker niet aan te raden om te lezen voor beginners! Er zouden dingen verkeerd kunnen gaan anders.

Wow, ik wist niet dat dit mogelijk was! Ik zal kijken of ik hier vandaag of volgende week nog iets mee kan, want dit zou het nog veel dynamischer kunnen maken!

Wat ik jammer vind is dat een hoop posts off-topic zijn gegaan en er meer gericht zijn om mijn werkwijze onderuit te halen. Ik vind het niet erg om hier verder over te discussieren, maar laten we het dan wel vriendelijk houden.

Verder weet ik dat er niet veel mensen zijn die bekend zijn met Agile waterfall (ook wel wetagile genoemd). Het is teveel werk om hier precies uit te leggen hoe dit deze ontwikkelmethode in elkaar steekt, maar als je op wetagile googled kun je genoeg uitleg vinden.

[Caelorum]

Big Joe schreef op vrijdag 10 augustus 2012 @ 09:22:
[...] Verder weet ik dat er niet veel mensen zijn die bekend zijn met Agile waterfall (ook wel wetagile genoemd). Het is teveel werk om hier precies uit te leggen hoe dit deze ontwikkelmethode in elkaar steekt, maar als je op wetagile googled kun je genoeg uitleg vinden.

Zonder je hier te proberen te bashen, maar de eerste resultaat in google levert mij op "I created a new term to describe Waterfall shops that either aspire to be Agile or are in the transition process. I call these shops “WetAgile.”". Dat komt op mij over alsof het niet echt een ontwikkelmethode is, maar meer een naam om mengelingen tussen waterval en agile aan te duiden. Zou je een linkje kunnen geven naar een fatsoenlijk artikel die het uitlegt zodat wij het wat beter begrijpen?

[Hydra]

Big Joe schreef op vrijdag 10 augustus 2012 @ 09:22:
Wow, ik wist niet dat dit mogelijk was! Ik zal kijken of ik hier vandaag of volgende week nog iets mee kan, want dit zou het nog veel dynamischer kunnen maken!

Wat ik jammer vind is dat een hoop posts off-topic zijn gegaan en er meer gericht zijn om mijn werkwijze onderuit te halen. Ik vind het niet erg om hier verder over te discussieren, maar laten we het dan wel vriendelijk houden.

Er wordt je gewoon vriendelijk vertelt wat je fout doet. Waar je bovendien ook nog eens vertikt op in te gaan. Je hebt bijvoorbeeld niks met m'n opmerking gedaan dat je oplossing wat betreft het ophalen van properties niet gaat werken als je controls dynamisch toevoegt. Daarnaast heb ik ook uitgelegd waarom bovenstaande 'dynamische' oplossing een slecht idee is: het is nauwelijks te debuggen en extreem onveilig.

Verder weet ik dat er niet veel mensen zijn die bekend zijn met Agile waterfall (ook wel wetagile genoemd). Het is teveel werk om hier precies uit te leggen hoe dit deze ontwikkelmethode in elkaar steekt, maar als je op wetagile googled kun je genoeg uitleg vinden.

Wetagile beteking niets meer dan dat ouderwetse waterfall bedrijven proberen meer agile te gaan programmeren maar dat ze, omdat de bedrijfscultuur er nog niet naar is, nog niet volledig 'om' zijn naar een echte agile methodiek. Het is geen methodiek, het is een "in between" situatie.

[CodeCaster]

Big Joe schreef op donderdag 09 augustus 2012 @ 12:21:
Hiermee kan ik dus een beheerscherm maken voor gebruikers, waarmee ze de properties van controls kunnen aanpassen zonder hulp van de programmeurs! In eerste instantie wordt het alleen mogelijk om de Text property van controls aan te passen, maar later kunnen we het ook zo maken dat de gebruikers andere properties ook kunnen aanpassen, zoals bijvoorbeeld de kleur.

En dat is een heel goed idee, want? In plaats van een form in elkaar slepen en "even" een nieuwe binary opleveren, ga je een heel dynamisch forms-platform creëren (met zijn eigen bugs en uitdagingen), wat het debuggen en onderhoud alles behalve makkelijk maakt. Zodat de klant ... de kleur van een labeltje kan aanpassen? Dit kan op diverse manieren een stuk handiger gedaan worden, afgezien van de vraag of het nu echt nodig is.

[Hydra]

CodeCaster schreef op vrijdag 10 augustus 2012 @ 09:31:
[...]

En dat is een heel goed idee, want? In plaats van een form in elkaar slepen en "even" een nieuwe binary opleveren, ga je een heel dynamisch forms-platform creëren (met zijn eigen bugs en uitdagingen), wat het debuggen en onderhoud alles behalve makkelijk maakt. Zodat de klant ... de kleur van een labeltje kan aanpassen? Dit kan op diverse manieren een stuk handiger gedaan worden, afgezien van de vraag of het nu echt nodig is.

Komt bij dat de "klant" moet kunnen programmeren. Als de klant dat kan vraag ik me af waarom 'ie het werk door een extern bureau laat doen.

[roy-t]

alwinuzz schreef op vrijdag 10 augustus 2012 @ 02:02:
Hoezo kan agile waterfall niet? Lijkt me toch een combinatie van best practices in de software developmentwereld.
Als je met iteraties werkt dan doe je toch aan agile? En dan kan binnen de iteratie alles worden vastgelegd volgens het waterfall model. Als je iets wil veranderen kan dat altijd in de volgende iteratie.

spoiler:

Grapje...

Alwinuzz je bezorgde me echt een hartaanval!

@Big Joe

Serieus lees je in dit topic alleen de 'slechte' posts door. Er zijn minstens 5 posts geweest waarin staat waarom het een slecht idee is om de 'C#/script' oplossing te gebruiken en zelfs de post waarin je wordt verteld dat dit kan is geschreven als een sneer ala 'kijken of ie stom genoeg is om dit te gaan doen'. Dit is gewoon pure overengineering en lost je probleem niet op zover ik het zie:

Probleem: klant moet forms kunnen bouwen
Oplossing: ik schrijf een immens complex systeem waarna klant C# moet gaan leren en dan uiteindelijk via een C# script engine het hele programma aanpast naar wens..?!??!?!?!

[Hydra]

roy-t schreef op vrijdag 10 augustus 2012 @ 09:38:
Probleem: klant moet forms kunnen bouwen
Oplossing: ik schrijf een immens complex systeem waarna klant C# moet gaan leren en dan uiteindelijk via een C# script engine het hele programma aanpast naar wens..?!??!?!?!

Installeer dan gewoon VS bij de klant en stuur 'em een factuur van een paar honderd k. Klaar

[Amras]

Hydra schreef op vrijdag 10 augustus 2012 @ 09:40:
[...]


Installeer dan gewoon VS bij de klant en stuur 'em een factuur van een paar honderd k. Klaar

Of Expression Blend ofzo, maar ga dit niet zelf bouwen. Je gaat ook zeker nog tegen problemen aanlopen, omdat je momenteel alleen properties ondersteunt van type string. Het wordt iets complexer als hier andere base types of zelfs complex types verwacht worden.

[Big Joe]

Het aanbieden van C# als een scripting language is sowieso iets voor een volgende sprint en het moet eerst nog worden overlegt met de klant. Overigens moet ik erbij zeggen dat ik jullie bezwaren over de scripttaal niet deel. Het schrijven van simpele scripts kan bijna iedereen binnen een week leren en desnoods kunnen we de klant hier een cursus voor geven (levert ook weer wat € op).

Overigens zou ik er dan wel een soort scriptvalidator ervoor schrijven, die het script controleert voordat hij het uitvoert. Het moet immers niet mogelijk zijn dat een gebruiker een script uitvoert dat functionaliteit van ons programma kapot maakt!

[Amras]

Dus ook nog even (uitgeklede versie van) een C# compiler schrijven, er wordt goed geld verdiend aan deze klant.

Als toch alles dynamisch moet zijn en de klant moet leren scripten, waarom laat je de klant dan geen C# cursus volgen en schaf je een VS2010 licentie voor hem aan? De functionaliteit die jullie hebben geprogrammeerd kun je dan als framework op .NET aanbieden.

[Big Joe]

De klant moet niet leren scripten, maar het is wel een mogelijkheid (indien we dit daadwerkelijk doorvoeren). Bovendien heeft de klant genoeg geld om dit te betalen (overheid)

[ Voor 47% gewijzigd door Big Joe op 10-08-2012 15:10 ]

[CodeCaster]

Big Joe schreef op vrijdag 10 augustus 2012 @ 15:00:
Overigens moet ik erbij zeggen dat ik jullie bezwaren over de scripttaal niet deel. Het schrijven van simpele scripts kan bijna iedereen binnen een week leren en desnoods kunnen we de klant hier een cursus voor geven (levert ook weer wat € op).

Overal waar ik ben tegengekomen dat klanten dingen mochten en konden aanpassen (templating van websites en forms, templating van Word-documenten en PDF's, enzovoorts, al dan niet gebruikmakend van thirdpartycontrols en -tools), moest het werk alsnog door de developers gedaan worden omdat de klant het nooit goed voor elkaar kreeg. Dat ging vanaf een kleurtje veranderen tot een veldje toevoegen tot een query aanpassen: alles werd door de developers gedaan, terwijl er juist zo veel werk in was gestoken om het voor de klant aanpasbaar te maken. Het boeit de klant niet, die wil het programma gewoon gebruiken, en als er iets veranderd moet worden, dan moet jij dat doen.

Dan kun je wel een machtig mooi templatesysteem met querybuilder en forms in databases in elkaar gaan prutsen, maar als het uiteindelijke werk toch maar op jouw bord terecht komt, waarom doe sla je de geld en tijd verslindende tussenstappen dan niet gewoon over, en doe je het in je vertrouwde omgeving (lees: Visual Studio)? Scheelt tijd, geld, bugs en gefrustreerde klanten en developers.

Big Joe schreef op vrijdag 10 augustus 2012 @ 15:08:
Bovendien heeft de klant genoeg geld om dit te betalen (overheid)

Fantastisch excuus.

[ Voor 6% gewijzigd door CodeCaster op 10-08-2012 15:11 ]

[Amras]

Big Joe schreef op vrijdag 10 augustus 2012 @ 15:08:
De klant moet niet leren scripten, maar het is wel een mogelijkheid (indien we dit daadwerkelijk doorvoeren)

En die klant is een niet technisch onderlegde gebruiker? Truus de Tiepmiep moet straks met classes, methoden en design patterns aan de gang? Is dit geen recipe for disaster?

[Hydra]

Big Joe schreef op vrijdag 10 augustus 2012 @ 15:00:
Het aanbieden van C# als een scripting language is sowieso iets voor een volgende sprint en het moet eerst nog worden overlegt met de klant. Overigens moet ik erbij zeggen dat ik jullie bezwaren over de scripttaal niet deel. Het schrijven van simpele scripts kan bijna iedereen binnen een week leren en desnoods kunnen we de klant hier een cursus voor geven (levert ook weer wat € op).

Complete onzin dat "bijna iedereen" in een week C# kan schrijven. Mensen die absoluut geen beta's zijn en niks van programmeren snappen ga je never nooit niet C# leren. En voor wat, een paar extra velden toevoegen aan een form?

Overigens zou ik er dan wel een soort scriptvalidator ervoor schrijven, die het script controleert voordat hij het uitvoert. Het moet immers niet mogelijk zijn dat een gebruiker een script uitvoert dat functionaliteit van ons programma kapot maakt!

En een klant betaalt je voor de enorme ontwikkeltijd hiervan?

Big Joe schreef op vrijdag 10 augustus 2012 @ 15:08:
De klant moet niet leren scripten, maar het is wel een mogelijkheid (indien we dit daadwerkelijk doorvoeren). Bovendien heeft de klant genoeg geld om dit te betalen (overheid)

Werk je toevallig bij Logica?

[ Voor 13% gewijzigd door Hydra op 10-08-2012 15:14 ]

[.oisyn]

Mensen zoals Big Joe zijn de reden waarom zoveel overheids-IT-projecten falen en er miljoenen aan belastingcenten verkwanseld worden.

[Hydra]

.oisyn schreef op vrijdag 10 augustus 2012 @ 15:19:
Mensen zoals Big Joe zijn de reden waarom zoveel overheids-IT-projecten falen en er miljoenen aan belastingcenten verkwanseld worden.

Yup. En die overheid zich maar afvragen waarom het toevoegen van een boxje op een form 3 weken ontwikkeltijd a 100E per uur kost.

[SKiLLa]

KISS, KISS, KISS en probeer het wiel niet opnieuw uit te vinden !

[Afvalzak]

Big Joe schreef op vrijdag 10 augustus 2012 @ 15:08:
De klant moet niet leren scripten, maar het is wel een mogelijkheid (indien we dit daadwerkelijk doorvoeren). Bovendien heeft de klant genoeg geld om dit te betalen (overheid)

Betaald u mijn belastingscenten dan? ^^'

[SKiLLa]

Waarom het toevoegen 3 weken duurt, lijkt me wel duidelijk.
De 100 euro per uur is omdat de leverancier de inkoopprijs van een jr/medior 100% verdubbelt en als sr verkoopt voor non-marktconforme prijzen ...

PS: Ik wil m'n belastinggeld terug, dit soort code-constructies wil ik niet financieren

[ Voor 18% gewijzigd door SKiLLa op 10-08-2012 15:24 ]

[D-Raven]

Big Joe schreef op vrijdag 10 augustus 2012 @ 15:00:
Het aanbieden van C# als een scripting language is sowieso iets voor een volgende sprint en het moet eerst nog worden overlegt met de klant. Overigens moet ik erbij zeggen dat ik jullie bezwaren over de scripttaal niet deel. Het schrijven van simpele scripts kan bijna iedereen binnen een week leren en desnoods kunnen we de klant hier een cursus voor geven (levert ook weer wat € op).

Overigens zou ik er dan wel een soort scriptvalidator ervoor schrijven, die het script controleert voordat hij het uitvoert. Het moet immers niet mogelijk zijn dat een gebruiker een script uitvoert dat functionaliteit van ons programma kapot maakt!

Je bent niet echt een pragmaticus of wel? Hoor je wel wat je zegt? "desnoods kunnen we de klant hier een cursus voor geven". Feitelijk zeg je hier: Desnoods leren we onze klant C# en dan kunnen ze zelf hun applicatie gaan ontwikkelen.....

Daarnaast een script validator schrijven welke controleert of je script niet iets doet wat niet mag? Überhaupt al verder over nagedacht wat dit precies inhoud?

[NMe]

Big Joe, ik weet niet of je nou alleen maar eigenwijs bent of dat je hier nu gigantisch zit te trollen, maar ik weet wel dat dat gedrag dit topic vast om zeep heeft geholpen en ik het daarom nu maar sluit. Je hebt dat eerder met Big Joe in "[JAVA] Inheritance vraag" en Big Joe in "\[vb.net] .DOC en .ODT bestanden openen in texteditor" ook al klaargespeeld, al zijn die topics uiteindelijk wel open gebleven.

Laten we het erop houden dat je er nogal onorthodoxe methodes op nahoudt die een aantal zeer ervaren ontwikkelaars hier laat kokhalzen. De mentaliteit dat je slecht afgewerkt spul kan leveren aan je klant omdat het toch maar de overheid is spreekt ook boekdelen; ik hoop dat ze hier meelezen.

Hoe dan ook, zoals ik zei gaat dit topic dicht. Mocht je alleen eigenwijs zijn in het niet willen luisteren naar oplossingen van anderen, dan is het misschien niet zo handig om op GoT topics met vragen te openen. Mocht je aan het trollen zijn, dan mag je dit als een verzoek zien om dat nooit meer te doen.