Ga naar inhoud

Kopiëren van custom functions


Aanbevolen berichten

Ben benieuwd of binnen dit forum deze kennis aanwezig is...

Ik werk aan een een 'library'-applicatie (onderdeel) waarin ik custom functions kan bijhouden die ik links en rechts in mijn ontwikkel-projecten gebruik. Met onder meer versie-beheer, issue-management etc. Blijkt onverwacht zinvol.

Het blijft echter lastig om: 

- een CF vanuit een bestaande applicatie in de library-app in te plakken;

- en andersom: een CF vanuit de library snel in te plakken in een applicatie.

Op het moment dat vanuit de CF-venster een CF kopieert, dan lijkt het clipboard leeg. heb ooit ergens gehoord dat het XML-data zijn, maar ze zijn op één of andere manier verborgen.  Is er een manier om de data toch te ontsluiten? 

En andersom: vanuit een FileMaker record een clipboard samenstellen dat in een CF-venster een CF kan inplakken?

 

 

Link naar reactie

FileMaker kopieert gegevens als xml data maar laat die niet zien als je hem in bv een teksteditor plakt.  Ik gebruik de BE_ClipboardGetText en BE_ClipboardSetText functies van de BaseElements plugin om de xml om te zetten naar tekst en weer naar clipboard.

Zo kun je scripts/scriptstappen/layoutelementen etc kopiëren, manipuleren en weer terugzetten of tussendoor opslaan.

Link naar reactie

Kwestie van evolutie, Gerard. Ik deed het natuurlijk altijd al in een bepaald bestand, maar deze benadering is uiteindelijk toch te beperkt. Als developer val ik graag terug op een meer uitgebreide tool:

  • mogelijkheid om te zoeken, filteren
  • uitgebreide info toevoegen: versie-data, notities, documentatie, URL's, voorbeeldbestanden desnoods
  • mogelijkheid om voorgaande versies te bewaren (ofwel nieuwe versies aan te maken)

 Ik denk zelfs dat het mogelijk moet zijn om een zandbak-functie te maken om Cf's en parameters los van de installatie te testen. 

De knip en plak optie - nu ondersteund met de BE-plugin - werkt overigens fantastisch. Nu echt zinvol ontwikkel-gereedschap; begrijp niet dat ik het niet jaren eerder heb bedacht.

@hans erik: t.a.v dat probleem van mutaties van dezelfde CF in verschillende projecten is deze tool ook zinvol. Je kan steeds de 'beste' versie nadrukkelijk weer vastleggen in je centrale tool.

 

Link naar reactie

Ik snap de voordelen van een ‘toolbox’, maar de methode om ze ‘gewoon’ in een bestand te plakken heeft ook zijn voordelen.

Overigens sluit het een het ander niet uit. Je zou ook beide kunnen gebruiken. Het idee is niet verkeerd. Misschien als ik nog eens een vrij uurtje heb iets om mijn huidige verzamelbestand mee uit te breiden.

Link naar reactie

Ik vind de huidige manier waarop je custom functies kunt beheren een beetje te simplistisch. Maar dat geldt eigenlijk voor een heleboel zaken zoals layouts, scripts en keuzelijsten. Een FileMaker applicatie groeit en groeit en groeit. Op een gegeven moment heb je 300 layouts, 1200 scripts en 186 keuzelijsten en het voortschrijdend inzicht maakt dat je eigenlijk de boel op iets andere manier wilt indelen. Dan heb je dus een probleem, want FileMaker heeft wel de tools om duizenden scripts aan te maken, maar niet de tools om die ook te managen.

De display lijsten zijn al 20 jaar niet  noemenswaardig aangepast. Enerzijds is dat geruststellend omdat continuïteit een groot goed is, anderzijds begint het al een jaar of 15 een beetje te knellen. Dus komen er allerlei tools op de markt om de lacune op te vullen, maar het blijft behelpen en Claris had dit al geleden moeten oplossen.

aangepast door hans erik
Link naar reactie

Ik ben het met je eens dat er een management probleem is. Wil dat niet direct aan FileMaker toeschrijven. Vind ook dat ze op dit management-vlak een steeds betere tooling leveren: zoals bijv migratietool, add-on's etc. Zou alleen nog heel graag layouts willen kunnen kopiëren.

Vind het ook erg grappig dat je in FileMaker zelf een beheertool kunt maken zoals een CF-database.

In alle eerlijkheid: kan je een tool visualiseren waarin je een dergelijk uitgebreide applicatie zoals jij specificeert, even van een andere opzet kunt voorzien? Anders dan wat ondersteuning in de knip&plak sfeer, zoeken van scripts en gebruik van analyse tools (DDR etc) gaat het niet. 

Er zit hier wel iets paradoxaals: een reden om voor FileMaker maatwerk te kiezen is vaak flexibiliteit. Functionaliteit kan naderhand worden uitgebouwd. Ik denk dat dat een hele juiste propositie is, maar het conflicteert enigszins met jouw klacht (als ik je post zo mag typeren)..

aangepast door Marsau
Link naar reactie

Nou, het zou natuurlijk al helpen als je bij het maken van een nieuw script of layout gewoon met een popup-menu kunt kiezen in welke map het ondergebracht moet worden. Met name omdat Filemaker je op veel plekken nog steeds in een modaliteit drukt en dat ook nog eens vrij knullig doet.

(overigens: die 'mappen' zijn natuurlijk helemaal geen mappen. Het zijn een soort constructies die op mappen lijken, maar je kunt ze niet sorteren of wat dan ook. Maar dat terzijde)

Voorbeeld: je maakt een knop aan op een layout en je besluit dat je geen bestaand script kunt gebruiken maar een nieuw script moet aanmaken. Je kiest dan een mapje waar het script moet komen en je vult de naam vh script in. Klik je op Cancel, dan is er toch al een nieuw script, laat staan dat je de map nog kunt wijzigen. Ook zou ik wel een script als template willen gebruiken... Het kan allemaal wel, maar altijd met een omweg.

En een 'Date Modified' of een 'label' bij een script (ook als kolom a.u.b.) zou natuurlijk niet verkeerd zijn.

aangepast door hans erik
Link naar reactie
  • 4 weken later...

Ik denk overigens dat je een CF altijd 'downward compatible' moet maken: de nieuwe versie voegt functionaliteit toe. En als er bijv parameters toegevoegd worden moet je er dus rekening mee houden dat die leeg kunnen zijn. Voor het resultaat is het simpel: als dat een ander formaat heeft, moet je gewoon een andere functie maken.

Een eenvoudige optie is verder om de versie van de CF in de naam op te nemen, bij cf_datumformat_v12, en nieuwe versies krijgen dan altijd een andere naam. Dan zie je aan de naam welke versie je gebruikt...

In de Meetup gisteren (28/6) werd een constructie gesuggereerd waarbij een CF in een FileMaker veld wordt opgeslagen en wordt uitgevoerd m.b.v. een evaluate() functie. Dat zou ik toch afraden, om meerdere redenen:

1.Performance. De evaluate functie is notoir traag. Bij een kleine CF maakt het niet uit, maar het kan flink uit de hand lopen;

2.Security. De evaluate functie zet de deur naar 'code insertion' op een kier. Zodra iemand zich toegang kan verschaffen tot de inhoud van het veld zijn de rapen gaar. Dat is ook een probleem met executeSQL, iets wat Claris opgelost heeft met de parameter constructie.

3.Welk probleem los je op? Want je blijft meerdere versies (onder)houden.

Link naar reactie

Een alternatief is om versiedatum gewoon als comment in de calculatie op te nemen. Iets minder zichtbaar, maar aangezien een CF altijd globaal aanwezig is, is "detectie" niet echt een probleem. 

Inderdaad lastig als je in naderhand parameters wilt toevoegen of wijzigen. Eigenlijk ondoenlijk, je moet dan elke toepassing van de CF nalopen: beter is dan een nieuwe CF te definiëren. 

Ben wel gecharmeerd van de gedachte om de CF integraal als Evaluatie uit te voeren, maar dan vooral als test-optie in mijn CF-database Volgens mij ging het gisteren overigens om iets anders: de optie om met de CF Javascript uit te voeren, o.i.d. - om zo nog meer functionaliteit te realiseren. Daar zou dan wel een performance aan zitten. Wellicht heb ik het verkeerd begrepen van Peter, want het was wel erg snel en summier.

Link naar reactie
On 6/29/2021 at 10:13 AM, Marsau said:

Een alternatief is om versiedatum gewoon als comment in de calculatie op te nemen. Iets minder zichtbaar, maar aangezien een CF altijd globaal aanwezig is, is "detectie" niet echt een probleem. 

Inderdaad lastig als je in naderhand parameters wilt toevoegen of wijzigen. Eigenlijk ondoenlijk, je moet dan elke toepassing van de CF nalopen: beter is dan een nieuwe CF te definiëren. 

Ben wel gecharmeerd van de gedachte om de CF integraal als Evaluatie uit te voeren, maar dan vooral als test-optie in mijn CF-database Volgens mij ging het gisteren overigens om iets anders: de optie om met de CF Javascript uit te voeren, o.i.d. - om zo nog meer functionaliteit te realiseren. Daar zou dan wel een performance aan zitten. Wellicht heb ik het verkeerd begrepen van Peter, want het was wel erg snel en summier.

Ik was niet helemaal nauwkeurig: het versienummer in de naam heeft alleen zin als je de nieuwe versie en de oude versie naast elkaar gebruikt, of in verschillende toepassingen, of wanneer je handmatig de functie in een toepassing bijwerkt (zowel de inhoud als de naam). Kopieer je een nieuwe versie naar je bestand, dan is het voor Filemaker een nieuwe CF. Je zou dan alle berekeningen na moeten lopen om de CF om te zetten en dat wil je niet. FileMaker kijkt natuurlijk naar het interne ID van de CF, niet naar de naam. Als je via de naam vd CF ook de versie wilt weergeven moet je EN de naam EN de programmacode bijwerken. Heb nog niet gekeken of dat met de XML conversie automatisch kan...

Javascript: ja dat zou inderdaad kunnen met de nieuwe JS functies. Javascript wordt natuurlijk door de web engine uitgevoerd, niet door FM zelf. Vraag me af hoe dat dan in serverside scripts zou moeten werken? 

aangepast door hans erik
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...