Results 1 to 7 of 7

Thread: Brainstormsessie nieuwe versie

  1. #1
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269

    Brainstormsessie nieuwe versie

    Zoals ik in de OpenXML Update-thread al aangaf: ik ga een start maken met v2. Deze wordt geheel from scratch geschreven aangezien ik niet tevreden ben met de opbouw van de huidige versie. Mijn excuses aan de mensen die hierdoor hun project drastisch aan moeten passen, de oude versie zal nog steeds beschikbaar blijven.


    Goed, nu over tot de orde van de dag, ik ga dus voor de verandering eerst eens nadenken voordat ik begin met code schrijven, het eerste punt op de agenda:



    De TNLDTranslateManager

    Ik zit een beetje in een tweestrijd. Aan de ene kant zeg ik: ja, het is wel praktisch om deze op een datamodule te zetten en de TNLDTranslate's eraan de koppelen. De hoofdreden om dit te kiezen is een OO-standpunt: je kan eventueel meerdere managers hebben, en dus meerdere taalbestanden verspreid over je applicatie, per form kan je dan aangeven welke manager je wilt.

    Aan de andere kant zeg ik: weg met die datamodule, maak een globale (uiteraard wel thread-safe) manager aan en gebruik deze automatisch onder de TNLDTranslate componenten. Om de manager dan te configureren kan iets worden gebruikt als subproperties in de object inspector van de TNLDTranslate. Het voordeel hiervan is dat je heel die datamodule niet nodig hebt (even TNLDTranslateFiles e.d. weggelaten, hun toekomst is nog onzeker, maar ik ga er nu even van uit dat deze functionaliteit direct in de manager komt).



    Er zitten aan beiden methoden voordelen en nadelen, ik heb daar zo m'n ideeën over, maar in eerste instantie wil ik even jullie mening, en vooral argumenten waarom het een beter zou zijn dan het ander. Veel mogelijke "problemen" die ik nu zie zijn op een elegante manier op te lossen, maar ik wil eerst een onafhankelijke mening en 'n idee krijgen van hoe NLDTranslate gebruikt wordt



    Alvast bedankt!
    Qui custodiet ipsos custodes

  2. #2
    Ik vind het idee van de manager wel handig. Je hebt een centraal punt waar al je componenten tegenaan kunnen praten en als je zelf een component wilt schrijven weet je ook waar je moet beginnen. Een 'component' dat in de achtergrond wordt aangemaakt hou ik meestal niet zo van, vooral omdat het dan lastig is deze te vervangen door een uitbreiding.

    Denk aan het schrijven van een eigen manager. Als het inderdaad zo is dat alle componenten via de interface met de manager praten kan ik de hele manager vervangen door mijn eigen manager (die niet eens erft van jouw manager) en alles blijft werken.

    Kortom: ik stem voor de manager en ik stem voor een complete loskoppeling van alle componenten. Dus alleen communicatie via de interface en de interface unit is de enige unit die alle componenten gebruiken.

    Maar ik ga nog even nadenken.....
    Marcel

  3. #3
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    Daar heb je inderdaad een goed punt te pakken. De reden waarom ik echter een soort van 'automatische gedeelde manager' wou is omdat het makkelijker te koppelen is, je hoeft niet eerst de DataModule-unit toe te voegen aan je uses, dan even wat compilen/heropenen/syntax-checken om de cache te refreshen waarna je je NLDTranslate koppelt aan de manager. Dit hele gedoe is voor mij een sterk argument om dit te versimpelen (zeker voor beginners), echter, de kracht wil ik ook niet kwijt, misschien is er dus een middenweg. Een aanpasbare manager-interface, een soort van 'override' property in de NLDTranslate component waarin je een eigen manager kan kiezen, zo'n soort oplossing.

    Volgens mij zou zoiets een mooie middenweg zijn, mits goed uitgevoerd. Voor een simpel project is 't dan werkelijk "erin donderen en klaar", wil je meer dan kan dat ook...



    ...we denken in ieder geval vrolijk verder, voorlopig ga ik nog geen code schrijven totdat vast staat hoe 't een en ander echt gaat werken
    Qui custodiet ipsos custodes

  4. #4
    Senior Member walterheck's Avatar
    Join Date
    Oct 2001
    Location
    Belo Horizonte, Brasil
    Posts
    4,212
    Ik denk toch dat ik met marcel mee ga. Het is erg makkelijk om voor een simpel projectje zo even wat compo's op je form te denderen, maar als ik even nuchter kijk dan zie ik het zo: tegenwoordig gebruik ik eigenlijk voor zoveel mogelijk dingen dbExpress. Al heb ik nog zo'n simpel progje, ik moet toch 5 compo's neerdonderen om een verbinding te hebben. maar ik hoef voor elke compo maar een of hooguit twee props in te stellen om het werkende te krijgen. Ik vind dat fijner, omdat dat het heel makkelijk maakt om het later even snel te upscalen. Ik heb dus liever iets meer/uitgebreidere compo's met een betere schaalbaarheid en consistency dan een enkele compo met de ease of use van het alleen maar ner te hoeven denderen van die enen compo. Het kost per slot van rekening bijna geen tijd om even een paar properties in te stellen...


    Dan wil ik eigenlijk nog een puntje aanhalen/een suggestie doen (het is ten slotte een brainstormsessie ). Wat ik miste in de eerste versie, was een mogelijheid tot een soort repository. Ik doel dan op zoiets als bij de ITE van Borland zelf zit. Je hebt dan een mogelijkheid om in een centrale repository een xml bestand te laden met vertalingen van bepaalde strings. Je kunt vervolgens bepaalde strings uit je form selecteren en dan heb je een optie om die uit de repository te trekken. Hij gaat dan zelf zoeken of hij "matches"vindt en die worden automagisch vertaald. Het leuke hieraan is dat je zo kan zorgen dat er niet strings worden vertaald in verkeerde vertalingen. Vb. (beetje wazig misschien, kon zo niks beters verzinnen): 2 forms: een over servies en een over dieren. op beide staat het woord kop, maar betekent het iets anders. Door nu eerst een andere repository in te laden, kun je beide woorden vertalen in hun juiste vertalingen. Psycho, jij zei toen eens dat je het vervelend vond om daarna nog alles na te moeten lopen, maar dat is iig minder werk dan het allemaal met de hand te moeten doen vind ik.
    Nee, de Romeinen spraken geen ISO-8859-1 LATIN

  5. #5
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    Om even je beiden punten af te lopen:


    1. Zoals ik al zei, ik wil die 'kracht' niet kwijt, maar ik begin die 'override property' een steeds aantrekkelijkere optie te vinden. Je kan 't vergelijken met de ThreadMgr property van de Indy server componenten: je kan hier je eigen manager aan koppelen, maar zodra je niks invult gebruikt ie de standaard manager. Op die manier heb je zowel de oude stijl als de nieuwe interne manager. Die interne manager is dan uiteraard ref-counted, dus zodra geen van de componenten 'm gebruikt zal ie nooit worden aangemaakt. Klinkt als de ideale oplossing eigenlijk, maar laat even weten of je hier nog opmerkingen over hebt

    2. Ik denk dat dat gedeelte buiten de basis van NLDTranslate valt, maar meer binnen de Expert die ik gepland heb. NLDTranslate zorgt puur voor de runtime vertaling vanuit een XML bestand, de expert kan vervolgens het proces van die XML bestanden aan repositories automatiseren.



    Overigens wil ik de functionaliteit van NLDTranslateFiles en NLDTranslateUndo ook gaan inbouwen, eventueel volgens dezelfde tactiek als mijn manager-idee, ik ben 't eigenlijk een beetje zat om elke keer die componenten neer te moeten gooien op m'n datamodule als ik ze toch altijd allemaal gebruik. Dit is dus puur luiheid, maar als mijn bovenstaande manager-idee aantrekkelijk genoeg is om ingebouwd te worden is er niks wat me ervan weerhoudt dit ook toe te passen op deze onderdelen, waardoor je toch de structuur netjes en uitbreidbaar houdt...
    Qui custodiet ipsos custodes

  6. #6
    Senior Member walterheck's Avatar
    Join Date
    Oct 2001
    Location
    Belo Horizonte, Brasil
    Posts
    4,212
    1. Tja, het is natuurlijk je eigen beslissing dus ikkan je hooguit mijn mening vertellen , maar persoonlijk vind ik het makkelijker om alles altijd op dezelfde manier te doen. Het idee op zich is wel goed, maar wel een beetje meer verwarrend. Da's natuurlijk ook alleen maar een probleem voor de eerste drie keer, maar toch je raakt denk ik niet ets avn de kracht kwijt op die manier. Verder vraag ik me af hoe jij nu zo lui kan zijn dat je het te veel werk vind om twee compo's op je form te denderen :?

    2. Daar heb je wel gelijk in, maar ik dacht het maar meteen even te opperen, aangeizen het toch bij het onderwerp hoort.
    Nee, de Romeinen spraken geen ISO-8859-1 LATIN

  7. #7
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    1. De grap is: de manier blijft exact hetzelfde. Als jij je manager op een datamodule gooit en koppelt aan de NLDTranslate dan werkt dat op exact dezelfde manier als v1.

    Hoe kan ik zo lui zijn? Simpel . Programmeurs zijn per definitie gemakszuchtig, ik wil zoveel mogelijk code in de componenten zodat ik in de applicatie amper wat hoef te doen. Het neergooien van de componenten daar buiten gelaten, het toevoegen van die datamodule in projecten waar ik 't niet nodig heb bevalt me niet helemaal, en dan met name 't feit dat ik deze datamodule op auto-create moet zetten en toevoegen aan de interface-uses van het form om de koppeling in designtime tot stand te brengen. Natuurlijk kan dit ook in runtime, maar dat is tegen het hele principe van NLDTranslate in: zo min mogelijk code indien niet nodig.


    Natuurlijk is 't mijn beslissing en zal ik dit waarschijnlijk ook wel doorduwen in deze versie (vooral omdat 't enkel functionaliteit toevoegt en niet wegneemt zoals ik al zei), maar ik ben slechts een klein deel van de eindgebruikers, dus ik hoor graag ideeën en meningen, en indien de argumenten overtuigend zijn kan ik mijn mening best bijschaven
    Qui custodiet ipsos custodes

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Nieuwe Versie programma maar DataBase behouden?
    By Anton Sr. in forum Databases
    Replies: 12
    Last Post: 01-Mar-04, 17:07
  2. Nieuwe versie vBulletin
    By Marcel in forum De website
    Replies: 5
    Last Post: 22-Aug-02, 22:48
  3. Weer een nieuwe versie
    By Marcel in forum De website
    Replies: 4
    Last Post: 29-May-01, 23:23
  4. Nieuwe versie forum ge?»nstalleerd
    By Marcel in forum De website
    Replies: 6
    Last Post: 25-May-01, 22:31

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •