Hierbij een update omtrent mijn framework.

De basis is een behoorlijk eind gevorderd. Het komt nu aan op het maken van een heleboel kleine componenten op verschillende niveaus, met name dataverwerking en user interface. Maar ook bijvoorbeeld macro-functionaliteit en een generieke scheduler.

Het is jammer dat ik het zo groot heb willen maken, daardoor schiet het niet zo op. Maar ik heb op zich al best wat: Een generieke Windows Service, een generieke WinForms applicatie (shell), en een aantal typen componenten waarvoor ik de implementatie al gemaakt heb.

In ieder geval is de basis nu volgens mij goed, en heb ik ook mogelijkheden om snel onderdelen toe te voegen zonder dat ik een heleboel met de hand hoef te doen. Dankzij mijn Excel Code Generator kan ik properties toevoegen, en op diezelfde plek zorgen dat afhankelijke stukken code aangevuld worden. Klinkt goed he?

Het belangrijkste is, dat ik nu een feature freeze op het framework doe, en dan een aantal componenten ga bouwen zodat ik ermee werken. Dan wat applicaties hierop bouwen. Dat zou dan een eitje moeten zijn…

Alle principes blijven overeind: Duidelijke scheiding van taken, gebruik van metadata waar mogelijk, modulaire uitbreidbaarheid, en vast nog een paar die ik vergeten ben.

Hopelijk zal ik wat vaker updates kunnen melden.

Happy coding!

Dat ik hier niet eerder op gekomen ben… Jarenlang heb ik maatwerksoftware geschreven, waarbij sommige stukken gemakkelijk te genereren zijn: Entiteiten, de datalaag en de database zelf. Maar je kunt nog veel verder gaan.

Stel: Je beschrijft alles met metadata. Dus of je velden op schermen wilt hebben, hoe dat eruit moet zien, wat voor validaties er zijn. Op basis hiervan hoef je weinig of geen maatwerk code meer te schrijven. Hierdoor voorkom je, dat je fouten maakt. Bovendien vergeet je nooit meer om bij wijziging in het model velden toe te voegen op plaatsen waar dit gebruikt wordt.

Deze metadata kun je op verschillende momenten uitlezen: Tijdens compilatie van C# code (bijvoorbeeld uit attributen), of tijdens generatie van sourcecode. Dit laatste gaat sneller, omdat je geen reflectie hoeft toe te passen.

Ik ben nu een aardig eindje met mijn Excel Code Generator. Hierin kun je niet alleen C# code genereren uit een model (met classes, members, properties, methods, constructors en attributen), maar ook in-place templates gebruiken. De C# compiler is blijkbaar zelf zo slim niet, maar met wat kleine ingrepen kan ik dat vanuit VBA wel. Ik laad dus C# code in uit bestanden die je refereert, en hierin kun je placeholders opnemen waar ik dan uitvoer van templates in plak. Het voordeel is, dat je heel gemakkelijk repeterende code kunt voorkomen. En bij aanpassingen vergeet je code niet aan te passen, want dat gebeurt vanzelf.

Neem bijvoorbeeld alle properties van een entiteit: Die wil je niet alleen initialiseren in de constructor, maar bijvoorbeeld ook heen en weer kopiëren van en naar het scherm. Of andere dingen mee doen. Wat ik nu heb bedacht, is dat je template sets kunt maken. Een template set bevat een lijst met velden, en een lijst met templates. Zo kun je dezelfde set gegevens meerdere malen gebruiken.

Ik ben er van overtuigd, dat dit veel voordelen oplevert. Minder fouten, beter onderhoudbare code, en een beter overzicht van de structuur. In het model zie je namelijk de structuur van de classes, en ook waar bepaalde onderdelen (zoals properties) weer gebruikt worden. Zo zie je niet gauw over het hoofd, dat bij het wijzigen van properties ook op andere plaatsen iets moet gebeuren.

De Excel Code Generator is al behoorlijk goed, maar het is nog niet perfect. Ik hed bedacht dat ik ook automatisch code wil uitlijnen. Dit is nodig, omdat ik zelf de complete structuur van de C# files schrijf. En ik laad ook bestanden in waarnaar gerefereerd wordt (de implementaties van de methoden, constructors en custom properties), en hierin ga ik placeholders vervangen met code. Hierbij zou je automatisch willen uitlijnen. Maar dit lukt me nog niet 100%.

Hoe dan ook: Ik denk dat dit toekomst heeft, en dat dit me veel voordelen biedt. Wie weet ga ik dit product nog eens promoten, op het moment dat er vraag naar is…

Happy coding!

Ik draaf de laatste tijd een beetje door. Maar laten we het positief Zien: Ik barst van de motivatie en ideeën. Ik ben flink aan de weg aan het timmeren met mijn framework. Ik verzin steeds meer, en kan het amper bijhouden. Ik moet dus nog wel tijd vinden om alles af te bouwen…

Het is lastig om een definitie of korte samenvatting te geven van dit framework, wat ik op dit moment ook nog maar ‘Yet Another Framework’ noem. Maar misschien is het beste om te zeggen wat mijn doel is: Ik wil herhalende en niet-uitwisselbare code voorkomen. Ik wil niet iedere keer hetzelfde bouwen, en ik wil dingen die ik bouw opnieuw kunnen inzetten. En dit allemaal schaalbaar, veilig enzovoorts.

Eén van de pijlers van mijn framework is Component Based Design. Functionaliteit stop je in een component, en elk component heeft ook maar een beperkte set rollen en taken. Dit verhoogt de (kans op) uitwisselbaarheid.

Verder is modelleren heel belangrijk. Ik vind, dat je zowel je proces als je datastructuren moet kunnen modelleren, en je moet dit ook nog run-time kunnen doen. Hiervoor heb ik veel meta-informatie nodig, maar dat is geen probleem.

Ten slotte is ook uitbreidbaarheid belangrijk. Alle plekken waar je verwacht dat functionaliteit aangepast of uitgebreid moet kunnen worden, moet je in componenten stoppen, zodat je dit kunt vervangen.

En dan nog het amateuristische aspect: Ik ben nu zelf eens de opdrachtgever, en ga niet bezuinigen op de tijd/opleverdatum. Alles moet goed, of zelfs meer dan goed zijn. Natuurlijk, ik kan consessies doen of zaken vooruitschuiven, maar dit doe ik dan het liefst alleen in componenten. zodat je kunt zeggen: Als je dat wilt, dan moet je dit component vervangen. Het antwoord "dit is niet mogelijk" wil ik niet geven.

Wat me hele leuke inzichten geeft, is het modelleren van mijn framework in Excel. Ik genereer alle code met één druk op de knop in Excel, en dit hoef ik alleen nog maar door de C# compiler te halen.

Wat het uiteindelijk zou moeten opleveren, is een framework waarop je gemakkelijk applicaties kunt bouwen. Dit moet schaalbaar, veilig, robuust en uitbreidbaar zijn.

Hopelijk kom ik binnen een paar maanden met een compleet werkend geheel, van back-end tot GUI. Tot die tijd is het nog een beetje rommelen met een testproject. Maar je kunt al aardig wat!

Happy coding!

Ik gebruik nu al een tijdje mijn Excel Code Generator voor het genereren van mijn Framework. Dit werkt al aardig, maar ik miste nog wat mogelijkheden.

Wat ik nu heb toegevoegd, is dat je in de code weer placeholders kunt opnemen waar templates in geplakt worden. Deze worden opgebouwd tijdens het verwerken van het model. Zo kun je waarden zetten van alle members. Verder heb ik de code wat beter beheersbaar gemaakt. Zo werk ik nog wel met kolomnummers in plaats van namen, maar de nummers zijn nu als constanten gedefinieerd. En verder heeft elk soort sheet (delegate en class) nu een eigen methode, die vanuit de hoofdmethode aangeroepen wordt. Zo is de hoofdroutine een stuk korter geworden, en kun je daar nu ook gemakkelijk je eigen extensies in schrijven.

Ik hoop dat ik het framework van voor naar achter af krijg. Het compileert wel, maar het is behoorlijk groot. Een echt werkend geheel is het nu dus nog niet…

Happy coding!

Ik heb het voor elkaar gekregen om behalve van model naar code ook de wijzigingen in code weer op te nemen in het model, zodat ik dezelfde files opnieuw kan genereren zonder code kwijt te raken.

Misschien denk je nu: waarom gebruik je dan geen partial classes? Maar in mijn model heb ik alleen de structuur van de classes staan, en niet de code die erin zit. Ja, ik heb verwijzingen naar bestanden per method en constructor, en die bestanden moeten dus bijgewerkt worden, als je opnieuw genereert.

Wat ik nu kan, is in eerst de structuur van de classes genereren, en in Visual Studio.Net code schrijven voor elke class. Vervolgens hoef ik in mijn model alleen nog maar bestandsnamen in te typen bij elke method, en vervolgens zou ik het model opnieuw kunnen genereren zonder dat ik de getypte code kwijt ben.

De truuk die ik hierbij gebruik, is dat ik bij elke methode die ik met de hand tik in Visual Studio.Net regels commentaar moet opnemen, zodat ik dit weer kan parsen in de code generator. Dit doe ik als volgt:

//begin #bestand.cs#

DoeIets();

//end #bestand.cs#

Alles wat hiertussen staat, is dus de code van bestand.cs.

Happy coding!

Hoe compileer je een compiler? Dat vind ik een interessante vraag. Een vergelijkbare situatie heb ik nu zelf: hoe maak ik een framework voor (het maken van) mijn framework?

Mijn framework begint steeds groter te worden. Ik had besloten om helemaal opnieuw te beginnen, om bij elk detail stil te staan. De totale architectuur (classes, methoden, attributen) wil ik eerst modelleren. Dus ik wil een stap terug doen: niet bouwen, maar terug naar de tekentafel.

Aldus ben ik begonnen met het modelleren van mijn framework. Het heeft inmiddels meerdere doelen:
-Entity framework
-Code generatie op basis van templates
-Basis voor een modulair uitbreidbaar systeem op zowel business logica als presentatie (GUI) niveau
-Mogelijkheid voor zaken als dynamische compilatie, flexibele client/server architectuur, macro’s opnemen en afspelen, enzovoort.

Nu kan ik hopelijk gemakkelijk nieuwe functionaliteit modelleren zonder al teveel moeite. Vanuit het model genereer ik C# code, die ik weer compileer tot een applicatie waarin je kunt modelleren

Het zal mij benieuwen, of ik het voor elkaar krijg om dit werkend te krijgen. In het begin zal het moeilijk zijn, omdat ik op dit moment nog met veel compiler errors zit. Dit wordt echt een uitdaging!

Happy coding!

Ik heb een robuuste, generieke en uitbreidbare oplossing voor macro’s in mijn GDP framework gebouwd. Het scherm heb ik redelijk van Office afgekeken, hoewel die van mij een stuk simpeler is. Aan de linker kant zie je alle macro’s, aan de rechter kant de geselecteerde macro en daaronder informatie over de uitvoer. Vanuit de macro kun je hier ook naartoe schrijven.

Grotendeels bestaat de oplossing uit een aantal onderdelen:
*Een MacroHostExtension, die macro’s kan opnemen en afspelen. De standaard implementatie ondersteunt C#.
*Een MacroRepositoryExtension, die macro’s kan opslaan. De standaard implementatie ondersteunt in-memory en opslag op file system.
*Via de Callback moet je vanuit de GUI, als Record Macro actief is, doorgeven welke macro stappen toegevoegd moeten worden.

Het framework ondersteunt ook custom events. Zo kun je een opdracht (actie) en argumenten meegeven. Verder ga ik alle standaard acties die ik kan bedenken vanuit de GUI toevoegen als constante, zodat je daar geen typefouten in maakt.

Ik heb de eerste versie inmiddels werkend. Je kunt een opname starten, de GUI een actie laten doorgeven, en dit wordt vertaald naar C#. Je kunt deze macro bewerken, afspelen, hernoemen en verwijderen.

Naast C# ga ik nog PowerShell ondersteunen, maar dit ga ik in een custom implementatie doen. Ik hoef dan alleen wat methoden te overriden.

Happy coding!

Ik heb nog steeds niet gevonden of er een standaardtechniek of framework is voor het ondersteunen van macro’s vanuit .Net-applicaties. Er is wel een framework voor Application Extensibility, het MEF, maar dat is net als VSTO in Office toebedeeld aan de ontwikkelaars. De tool hiervoor is Visual Studio.Net. En waar blijft het gemak van "Record macro" in Excel, en even de code aanpassen? Deze laagdrempelige macro’s, samen met het feit dat de ontwikkelomgeving (VBA-editor) in Office zelf zit, maakt het een geweldige techniek. Krachtig en toch laagdrempelig.

Ik ben toch bang, dat ik het zelf moet gaan bouwen. Het framework ervoor heb ik al, maar nu moet ik nog zorgen dat elke actie (door de gebruiker) kijkt of er een macrostap opgenomen moet worden. En elk scherm of component moet bij het afspelen van macro’s kijken of hij de opdracht begrijpt, en dit uitvoeren.

Het klinkt alsof deze techniek veel ingewikkelder is om te maken, omdat VBA volgens mij gewoon een host is die het script uitvoert. Bij mijn oplossing moet ik twee kanten op vertalen. Maar volgens mij heb ik weinig keus….

Happy coding!

Met een paar kleine wijzigingen heb ik GDP nog groter gemaakt. Zo zou de GUI alleen maar een framework kunnen zijn, waarbinnen je assemblies laadt met schermen. Tijdens het laden van de assemblies staat er informatie bij de schermen (classes) over de naam en positie binnen het menu.

Wat GDP dus nu is, is een framework waarop je applicaties kunt bouwen die zowel client/server-based zijn (met mogelijkheid tot opschalen) en in ieder geval een uitbreidbare GUI en een command-line variant. What else could you possibly need? (okee, misschien een webportaal… daar gaan we nog eens over nadenken)

Wat je hiermee kunt doen, is andere partijen toestaan nieuwe schermen en functionaliteit te laten bouwen. Of in ieder geval om dit modulair op te lossen, en bij installatie aan te geven wat je wel en niet wilt. Het wordt wellicht een hele lijst met assemblies, als je alles in losse componenten stopt. Maar een aantal basiscomponenten en -schermen kun je ook samenvoegen. Maar zo heb je wel de mogelijkheid om bijvoorbeeld functionaliteit te verbeteren of aan te vullen.

En nu maar kijken of ik nog tijd heb om al die functionaliteit te bouwen! Ik heb ook de macro’s wat meer uitgewerkt. Wat ik bedacht, is dat het leuk is om bij het opnemen van macro’s direct C# code te  genereren. Dan is het afspelen een makkie. Je hoeft alleen de gegenereerde C# code maar te instantiëren.

Happy coding

Waar mijn hart echt ligt, is bij het ontwikkelen van applicaties die uitbreidbaar en scriptbaar zijn. Dit kan op een heleboel manieren.

Zo kun je bij command-line applicaties door het meegeven van parameters van buitenaf de applicatie besturen. Maar dit is vrij beperkt: je kunt alleen bestaande functionaliteit aanroepen.

Je kunt via extensions/plugins de applicatie uitbreidbaar maken. Hier verplicht je de ontwikkelaars om een assembly te ontwikkelen met Visual Studio.Net. Dit is zeer krachtig, maar wel relatief lastig.

Een tussenoplossing is om vanuit de applicatie zelf scripting toe te staan. Vroeger (in de dagen van VB6) kon dit via de Windows Scripting Host. Die kon je in je eigen applicatie hosten, en bood de mogelijkheid om met de applicatie te praten door objecten als context mee te geven.

Wat ik vandaag ontdekt heb, is dat het met PowerShell eenvoudig is om dit op een moderne manier. Je krijgt dezelfde functionaliteit, maar dan met PowerShell in plaats van VBScript. En de aanroep is kinderlijk eenvoudig!

Wat ik me wel begin af te vragen, is wat je nou wanneer gebruikt… En wat doet bijvoorbeeld Microsoft met VBA? Uit compatibiliteitsoverwegingen zit het er nog in, maar voor nieuwe Office-uitbreidingen verwijzen ze al snel naar VSTO. Maar hier heb je een zware (en dure) Visual Studio installatie voor nodig, terwijl de kracht van VBA ook is, dat het al in Office ingebakken zit. Al zou je een lichtgewicht IDE in je eigen applicatie hebben, al dan niet met debugging-mogelijkheden en Intellisense, dan zou je een moderne scripting mogelijkheid bieden.

Ik ga kijken, wat ik hiermee kan doen in mijn ultieme Zwitsers zakmes, Generic Data Processor. Ik heb daar al een dynamische C# compilatie, dus je kunt daar ook gemakkelijk de gebruiker C# code laten intikken. Maar wellicht is PowerShell hier ook handig?

Happy coding!