Ga naar inhoud

Wat vindt u hiervan?


rmw

Aanbevolen berichten

Het is mooi, maar niet te mooi om waar te zijn

 

Gebruik dit al een tijdje. De standaard functies zijn al vrij uitgebreid, maar met wat kennis van Groovy en Java kan je bijna stellen dat "the sky is the limit".

 

Ik gebruik het nu bijna standaard in elke applicatie. Bijvoorbeeld om betere dialoogvensters te maken, etc. Ik ga er vanuit dat deze plugin nog veel krachtigere dingen kan, maar daarvor is op dit moment mijn kennis van Groovy te beperkt (hint hint voor FM Summit 2010 :) )

 

Het vraagt wat tijd om je er echt in te verdiepen, maar het is het allemaal waard.

 

Je hebt op FMForums een subforum dat helemaal aan deze plugin is gewijd.

Link naar reactie

Ook dat klinkt mooi :wink:

 

Ik heb wat huiver, omdat je wel genoodzaakt bent java op de client te hebben staan.

En het versie beheer daarvan verdient niet echt een schoonheidsprijs....

Maar als ik jou zo hoor is dat hier geen show-stopper

 

Toch maar eens in duiken dus....

 

rmw

Link naar reactie
Bij installatie van deze plug-in loopt mijn filemaker adv vast :(

is nederlandstalige versie op win vista

iemand een idee ?

alvast bedankt

 

Ik heb het nog niet op Windows Vista geinstalleerd, maar wel op Windows7, en daar gaf het geen probleem.

 

Normaal gezien als je het voorbeeld bestandje opent zou hij automatisch de plugin moeten installeren. Loopt hij dan ook vast?

Link naar reactie

Ik zou deze vragen gewoon in de versie nummer van FM houden. Zou makkelijk kunnen voorkomen dat oplossingen onder FM9 anders moeten zijn dan die onder 10, 11,12 of 1?. Met andere woorden als men een vraag stelt over een probleem onder 10 dan is het antwoord onder 9 misschien helemaal niet van toepassing. (een oplossing onder 10 voor de pro kan onder de server versie zelfs niet werken?). Dat zal voor gebruikers lastig worden om dit er uit te filteren.

Link naar reactie
als er toch al enkele gebruikers hier op zitten, zou het mss handig zijn om een klein subforum of draadje te maken waar we elkaar kunnen helpen? Ik loop soms echt tegen problemen waar ik niet rond geraak, wegens gebrek aan kennis van Java of Groovy.

 

Het is maar een ideetje :)

 

Helemaal mee eens.

En als er dan ook nog iemand zo vriendelijk is om iets als dit voor Groovy te maken zijn we helemaal een mooi eind op weg :o

Link naar reactie
  • 4 weken later...

Nee, laat maar komen. De kern van de zaak is dat het een Filemaker plug-in is, juist daarom hoor het hier thuis in een apart draadje. Het klopt dat andere programmeertalen er dwars doorheen gaan, maar beter hier vanuit Filemaker redeneren dan op een ander forum dit hele ding niet willen / kunnen begrijpen omdat men daar Filemaker niet snapt.

Link naar reactie
  • 1 maand later...

ik kan deze redenering gedeeltelijk volgen. Het duurt inderdaad even eer een plugin helemaal gestest/aangepast is voor verschillende platformen en/of de nieuwe versie van FileMaker.

 

Maar ik vind ook dat het de taak is van de ontwikkelaar om dit te controleren en pas een update te adviseren indien de plugin degelijk is getest. het is natuurlijk waar dat op gebied van een OS update je meestal weinig te zeggen hebt over al dan niet up te daten...

 

Maar meestal loopt dit bij ons toch vrij vlekkeloos...

Link naar reactie

Op het gevaar het feestje toch een beetje bederven, ik heb totnutoe 2 minder prettige ervaringen gehad met plugins:

 

Ik gebruikte jarenlang de Schubec PHP plugin, tot die er de brui aan gaven en de ontwikkeling en support ervan stopzetten! (het alternatief is gelukkig wel die van Scodigo - ik weet niet welke van beide ontwikkelaars als eerste op het idee kwamen om de PHP interpreter als plugin te compileren).

 

Bij oplevering van een groter project met 30 gebruikers, waarbij we gebruik maakten van de SecureFM plugin, kochten we licenties van deze plugin aan, Een maand later een nieuwe versie uit van FileMaker, en was de plugin niet meer compatibel. Leg dan aan je klant uit waarom die 2x een plugin moet betalen. Gelukkig is de kostprijs ivt de ontwikkelingskost klein, maar het komt op z'n minst een beetje raar over.

Link naar reactie
  • 2 weken later...
Dat is nou altijd mijn grote angst voor plug-ins... verandert de omgeving, dan heb je kans dat je gedwongen afscheid moet nemen. Of in elk geval een periode niet vooruit kunt.

Een gegronde angst.

Maar eigenlijk heb je zoiets eveneens met FileMaker zélf, niet alleen met plug-ins. Af en toe verandert FileMaker de regels van het spel, en dat heeft ook implicaties.

Kijk dan maar eens wat we allemaal hebben moeten doen om onze FileMaker Pro 6 oplossingen naar 7 over te brengen.

Dit gebeurt eveneens met de "kleinere" releases. Een voorbeeldje is de manier waarop relaties werkten met lege parameters. Een ander voorbeeld is de manier waarop FileMaker Server met unstored calculations omspringt. Ook een paar keer veranderd. Nog een ander voorbeeld is de steeds stricter wordende manier waarop FileMaker omgaat met data types. Elke keer als er zoiets verandert, zijn er toepassingen die sneuvelen. Alleen de heel simpele dingen blijven overeind.

 

Wat kan je daartegen doen? Niet upgraden is 1 manier. Die werkt ook voor plug-ins. FileMaker brengt elk jaar een nieuwe versie uit. Dat is niet omdat de vorige versie eigenlijk niet goed was. Het is gewoon omdat de kassa moet rinkelen. If it aint broke don't fix it.

Een andere remedie is je code zo defensief mogelijk te schrijven. Zoveel mogelijk "zandzakjes leggen". Hiermee bedoel ik: parameters van scripts nakijken op inhoud en type, checken of je gerelateerde records hebt voor je ernaar toe springt, elk script een ScriptResult laten teruggeven om na te kijken of de zaken gelukt zijn, zoveel mogelijk herbruikbare code schrijven zodat je ook minder code moet debuggen. FileMaker het de gemakkelijkste programma om sh_tcode mee te schrijven, doordat je zo snel aan de slag kan zonder veel te moeten kennen. Het leent zich niet zo gemakkelijk om gebetoneerde routines mee te schrijven, maar het is wel tot op zekere hoogte mogelijk, maar dat vergt heel wat ervaring, tijd en moeite.

Als je plug-ins gebruikt als FileMaker developer, is het ten zeerste aan te raden om een abstractie-layer aan te brengen onder de vorm van custom functies. Je roept dan nooit plug-ins rechtstreeks aan, maar via de custom functies. Zo kan je ook wat gemakkelijker van plug-in veranderen als dat nodig blijkt.

Of je zorgt dat je plug-in in maar 1 script wordt opgeroepen, zo maak je ook een gemakkelijk te onderhouden oplossing.

Zorg dat je applicatie niet staat of valt met je plug-in. Een plug-in is goed om bijkomende functionaliteit te voorzien, maar niet als kern van je applicatie. Anders kan je best niks meer veranderen na installatie van het programma. Geen Filemaker updates, geen systeem updates en geen plug-in updates. Tenzij je de zaken op voorhand grondig kan testen.

 

Freeware plug-ins zijn aantrekkelijk, maar de medaille heeft 2 kanten. Freeware software is meestal "as is", en als het niet werkt, dan heb je ook niks te protocollen.

Als je een plug-in aanschaft, is het de moeite om eens te kijken hoe lang dat ding al bestaat. De Troi Dialog plug-in van Peter Baanen is letterlijk een plug-in van het eerste uur ( het is de eerste gewoon ). En die bestaat nog steeds. De kans dat Peter er morgen mee ophoudt lijkt me dus ook zeer klein. Een andere factor is de functionaliteit van de plug-in zelf. SecureFM is een schoolvoorbeeld van een plug-in die eigenlijk een hack is. FileMaker geeft duidelijk aan plug-in developers aan dat ze niet graag zien dat er ingegrepen wordt op windows en menus van de applicatie zelf. Logisch dat het ding breekt bij elke nieuwe release van FileMaker.

Het veiligste zijn de plug-ins die gebruik maken van de door FileMaker ter beschikking gestelde plug-in API. Zolang FileMaker dan weer de regels van de API niet verandert.

Als er verschillende plug-ins zijn die dezelfde functionaliteit hebben ( SimpleDialog versus Troi Dialog, SmartPill versus Shubec versus Monkeybread ) dan zit je ook al wat beter, op voorwaarde natuurlijk dat je de bovenvernoemde abstracties gebruikt.

Ik vind een zeer belangrijk criterium voor de keuze van een plug-in dat hij multi-platform werkt, zonder pardon. Identiek dezelfde functionaliteit. Dat bewijst meestal al de kunde van de developer achter de plug-in, het is een belangrijke indicatie dat de plug-in geen snel in mekaar gebokste hack is. Daarenboven blijft je klant de vrijheid houden om FileMaker te draaien op een platform van zijn keuze. De ScriptMaster plug-in is multi-platform. Dat vind ik zeker een pluspunt. Hij zit ondertussen aan versie 3. Ook een pluspunt, het is geen 1-dagsvliegje. De developers van 360Works zijn Java specialisten en hebben een hele rits plug-ins die op één of andere manier met Java werken. Geeft me ook een goed gevoel. Enige 2 minpuntes: t'is freeware, en als er weer eens een defecte Java release op de proppen komt, loopt het mis.

Zij die de Java combinatie-problemen kennen met FileMaker Server, weten wat ik bedoel.

 

"Ik gebruik geen plug-ins, ik doe dit wel met AppleScript." Dat hoor ik soms zeggen door developers. Niet multi-platform en daarenboven even fragiel als een plug-in. Of mensen die vanuit script stappen Windows command line instructies doen. Op die manier weet je meestal niet of de dingen lukken, want je krijgt geen error code terug. En het werkt dan ook weer niet op Mac. En als Microsoft met een nieuwe Windows versie komt, gaan de dingen weer kapot.

 

Als toemaatje, het lijkt me logisch dat 1 van de volgende versies van FileMaker op Mac het Cocoa framework zal gebruiken i.p.v. het Carbon framework. Carbon is stilletjesaan verleden tijd. Al eens gedacht wat er dan "anders" zal gaan werken? Als een FileMaker oplossing een zekere complexiteit bereikt, zal ze ALTIJD moeten nagekeken worden bij een nieuwe FileMaker release, plug-ins of geen plug-ins.

 

Dus vanaf morgen schrijven we alleen nog maar poepsimpele FileMaker oplossingen, dan kan er niet misgaan. Misschien.

Not!

De klant wil zoveel mogelijk functionaliteit. Als die op een zeker ogenblik iets nodig heeft waar een plug-in voor nodig is, dan ben ik geen tegenstander. Zolang de klant maar beseft dat de hier besproken problematiek gewoon bestaat. Daar kan je niet vanonder.

Sorry voor de lange post, guys. Dit is duidelijk mijn stokpaardje.

Link naar reactie
Sorry voor de lange post, guys. Dit is duidelijk mijn stokpaardje.

 

Mag ik dan even aan je stijgbeugel rammelen...

 

 

De Troi Dialog plug-in van Peter Baanen is letterlijk een plug-in van het eerste uur ( het is de eerste gewoon ). En die bestaat nog steeds. De kans dat Peter er morgen mee ophoudt lijkt me dus ook zeer klein.

 

Het lijkt me net wel mogelijk, lees kans groot, dat Peter Baanen er mee kan ophouden.

Net omdát hij al zolang bezig is......

 

Ik ben na 21 jaar gestopt met wat ik bezig was, en zal binnen de 10 jaar stoppen met wat ik bezig ben.....

 

En mocht ik er dan nog zijn zal ik waarschijnlijk opnieuw beginnen met wat ik bezig was.

Maar ook dat zal tijdelijk zijn.....

 

Old developers never die, they just crash.... 8)

Link naar reactie

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Antwoord op deze discussie...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...