WebViewer Helper [1.0.0.28]

[Peter Wagemans]

Het grootste probleem dat je hebt als je FileMaker WebViewers wilt laten praten met FileMaker zelf, is dat je moet zaken kunnen doorgeven en ophalen, wat niet zomaar kan zonder commerciele plug-ins.

 

 

 

Andries en ik zijn daar over aan het brainstormen geweest.

Het leek ons het beste om via de JavaScript Socket Library met FileMaker te gaan praten.

We hadden dan aan de FileMaker kant iets nodig dat luistert op een bepaalde IP poort. Een cross platform plug-in, bij voorkeur open source.

Geen commerciele plug-in, zodat dit een stuk bereikbaarder wordt voor iedereen. Open source omdat we ook zeker willen zijn dat we ook in de toekomst hiermee aan de slag kunnen blijven gaan.

 

Ik had beloofd om iets simpel en stupid te schrijven. Dat is dan vandaag gebeurd.

Het ding is een socket listener, en kan 2 zaken: evalueren van de strings die je er naartoe stuurt, en scripts uitvoeren in de huidige file met een parameter.

 

Nog geen Windows versie, maar dat is omdat ik gewoon nog niet geprobeerd heb om aan de Windows kant te compileren. Dus die kan er vrij snel zijn.

Documentatie in de FileMaker file zelf. Daar zit ook de plug-in.

Op Mac werkt die vanaf OSX 10.5

 

In de file zit geen uitgewerkte documentatie over hoe je dan met deze functionaliteit aan de slag gaat.

Ik veronderstel dat het nu mogelijk wordt hier een bibliotheekje rond te schrijven.

Dat hoop ik toch.

 

Als ik de Windows kant in orde heb, zal ik alles op BeanStalk zetten.

 

[EDIT: ondertussen werkt dit ding al lang op Windows natuurlijk. En wie geinteresseerd is in de source, laat me iets weten]

 

De huidige versie is altijd downloadbaar vanuit de gehoste FileMaker file op fmp://fms.fmsnippets.org/HTML Snippet Library.fmp12

 

{EDIT: even naar pagina 9 scrollen, hij staat nog niet in de HTML snippet library]

[Felix]

.

6 oktober 2015 aangepast door Gast

[Peter Wagemans]

Ik ga me eerst door de WIndows versie van de plug-in worstelen. Misschien kan Andries al reageren, en dan wordt het allemaal wat praktischer en duidelijker.

[Peter Wagemans]

Misschien ook nog een send functie inbouwen, dan krijgt die plug-in nog een heel andere functie, namelijk directe communicatie tussen FileMaker clients.

[Peter Wagemans]

Hier de file met ook de windows versie erin.

 

Ik moet nog heel wat debug code opruimen, er wordt nog zwaar gelogd naar %APPDATA% en ook op Mac is er een log filetje onder ~/Library/Logs/Clarify

 

Posten op BeanStalk doe ik zodra ik de code wat opgeruimd heb.

 

Er kan alvast nu op beide platformen gespeeld worden.

WebViewerHelper.fmp12

[andries]

He Peter,

 

ik zie het ook nog niet

 

Op dit moment heb ik het volgende geprobeerd:

 

- met de websocket techniek die nieuw is in HTML5 (nog te testen of dit in de webviewer gaat werken)

- via HTTP request

 

Met de websocket techniek heb ik het gevoel dat ik uberhaupt niet op de socket terecht komt, de connectie wordt nooit geopend, en ik kan er dus niet naar schrijven

Via de HTTP request kom ik wel degelijk op de socket terecht, maar hier snap ik niet hoe ik er naar moet schrijven, want volgens mij kan je bij HTTP enkel data meesturen in de body, en niet schrijven over de stroom (of toch niet met Javascript, ga dit eens testen via ScriptMaster).

 

Bon nog wat verder testen.

[Peter Wagemans]

De WebViewerHelper luistert voor een connectie op de aangegeven poort ( zet je dus in gang met de enige plug-in functie die er nu inzit ).

Zodra de connectie door een "client" geopend wordt, verwacht WVH onmiddellijk data. Krijgt WVH die data dan doet hij er iets mee. Krijgt hij niks dan doet hij er ook niets mee. Wat hij altijd doet is de connectie aan zijn kant sluiten, data of niet.

 

Je moet dus rap zijn

 

Als je wat te lang wachten tussen het openen van de connectie en er iets op door te sturen, dan ben je gesjareld. Zowel netcat als een browser sturen onmiddellijk data op de socket. Met de browser kan je er echter niet onderuit om eerst een http header mee te sturen.

Als het niet werkt om via websockets GEEN header mee te sturen, dan kan ik de code wel aanpassen dat WVH eerst die bepaalde data uit de ontvangen data wegfiltert. Maar dan wordt de code een stukje ingewikkelder.

WVH checkt incoming data tot de eerste char 13-10 combinatie en gooit de rest weg. Met een http header wordt dat allemaal wat uitgebreider. Als websockets alleen maar http headers kan sturen, dan moet ik hier verder aan werken.

 

void AcceptSocket() {

#if FMX_MAC_TARGET

acceptedsocket = accept(listener, (struct sockaddr *) &serfrom, &fromlen) ;

#elif FMX_WIN_TARGET

acceptedsocket = accept(listener, NULL, NULL);

#endif

if ( acceptedsocket > 0 ) {

char *newline;

servbuffer = (char *)calloc (SERV_BUFFER_SIZE, sizeof(char) ) ;

if ( recv( (int)acceptedsocket, servbuffer, SERV_BUFFER_SIZE - 1, 0) > 0) {

fmx::TextAutoPtr logText ; logText->Assign ( "incoming data detected") ; WriteLog( logText ) ;

// truncate buffer at newline \r or \n, we are only interested in the first line

newline = index( servbuffer, 13 );

if ( newline != NULL ) newline[0] = 0;

newline = index(servbuffer, 10);

if (newline != NULL) newline[0] = 0;

if (servbuffer != NULL) {

ProcessAndReply();

}

else {

logText->Assign ( "no data in buffer") ; WriteLog( logText ) ;

// mmm. not good to return, because no housekeeping of connection. change.

return ;

}

free(servbuffer);

}

#if FMX_MAC_TARGET

shutdown((int)acceptedsocket, SHUT_RDWR) ;

close ((int)acceptedsocket);

#elif FMX_WIN_TARGET

closesocket ( acceptedsocket ) ;

// returning because freeying gets us in trouble (why?), don't know what impact will be ( memory leak? )

return ;

#endif

free( &acceptedsocket ) ;

}

}

[andries]

voor mij is HTTP meer dan voldoende, maar ik krijg het niet voor elkaar om er data mee mee te sturen.

 

als ik gewoon in mijn browser "http://127.0.0.1:10234/" invoer krijg ik

 

***** ERROR *****
first letter is not recognized as a command.
*** END ERROR ***

 

wat mij doet vermoeden dat ik wel degelijk op de socket zit, maar idd geen data meestuur.

 

dan al de mogelijke combinaties in de URL geprobeerd, maar dat is het ook niet, en dan dacht ik : "ah mss moet ik het meesturen als body", dus heb ik

verder geprobeerd met "POSTMAN" (REST client) om data in de body mee te sturen, maar krijg telkens hetzelfde terug.

[Peter Wagemans]

Andries, het probleem zit'm in de http header die je meestuurt. Daar zit op de eerste lijn van de communicatie al "GET /"... en de rest.

Ik heb zo stilletjesaan door dat javascript nog niet klaar is voor raw IP sockets: http://stackoverflow.com/questions/12407778/connecting-to-tcp-socket-from-browser-using-javascript?rq=1

 

Maar geen nood. Ik zal eens kijken of ik op een simpele manier het toch via een http call voor mekaar krijg.

Een beetje zoals we het gedaan hebben met de DoScript 3 beta.

Ik moet eerst even (terug) eens onderzoeken wat er in een simpele HTTP GET request als header zit. Terug even in de source code van DoScript 3 duiken en zien wat ik kan gebruiken voor onze plug-in.

Een request in de vorm http://:/e%20Get(FileName) zou moeten resulteren in een header die er zo uit ziet:

 

GET /e Get(FileName) HTTP/1.1

 

En dat zou dan wel simpel uit te parsen zijn. Maar ik ben nog niet zeker. To be continued.

[Peter Wagemans]

OK, ik heb een header parsertje geschreven:

 

    if ( IsHTTPGetRequest(receivedText) ) {
       tempText->Assign ( "GET /") ;
       receivedText->DeleteText( receivedText->Find ( *tempText , 0 ) , 5 ) ;
       tempText->Assign ( "HTTP/") ;
       receivedText->DeleteText( receivedText->Find ( *tempText , 0 ) , fmx::Text::kSize_End ) ;
       tempText->Assign ( "%20") ;
       fmx::TextAutoPtr mySpace ; mySpace->Assign ( " " ) ;
       uint32 myFoundPos ;
       while (myFoundPos = receivedText->Find ( *tempText , 0 ) , myFoundPos != fmx::Text::kSize_End ) {
           receivedText->DeleteText ( myFoundPos , 3 ) ;
           receivedText->InsertText ( *mySpace, myFoundPos ) ;
       }
   }

 

Dit wil zeggen dat ik uit de gekregen data string de "GET /" uit strip, vanaf de string "HTTP/" tot het einde er ook af strip.

Vervolgens vervang ik de "%20" dingen terug door spaties. Vervolgens gaat het ding gewoon verder met de code die ik al had.

Je hebt dus volgende 2 voorbeelden in http vorm:

 

http://localhost:10234/e%20Get(FileName)

en

http://localhost:10234/s%20Hello%20World

 

OSX versie toegevoegd. Dan kan je al testen. Als je de Windows versie nodig hebt dan compileer ik die.

WebViewerHelper.fmplugin.zip

[andries]

Peter

 

dit werkt, maar nu wordt het denk ik tricky...

 

als we echt asynchroon programmeren willen toelaten, dan moet de "server" Cross Origin toelaten, anders wordt het geblokkeerd door de browers (security reasons).

 

dit krijg ik nu als error terug

XMLHttpRequest cannot load http://localhost:10234/e%20Get%20(%20FileName%20). Origin null is not allowed by Access-Control-Allow-Origin. 

 

Ik heb dit al eens opgelost op een eigen webserver, gebouwd met nodeJS, waar ik in de headers dit moest aanpassen:

 

var allowCrossDomain = function(req, res, next) {
   res.header('Access-Control-Allow-Origin', '*');
   res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');
   res.header('Access-Control-Allow-Headers', 'Content-Type,Authorization');

   // intercept OPTIONS method
   if ('OPTIONS' == req.method) {
       res.send(200);
   }
   else {
       next();
   }
}

 

ik hoop dat je hier iets aan hebt

[Peter Wagemans]

De server laat alles toe, die trekt zich niks aan van cross origin, hij weet zelfs niet wat dat is.

 

Ik denk dat je me eerder moet vertellen hoe de server moet antwoorden. Een raw reply is blijkbaar niet OK, je moet me dus vertellen wat ik als header string vooraf moet toevoegen in de reply bij zo'n HTTP request.

[Peter Wagemans]

Ik lees hier iets over op wikipedia en zie dat een

 

Access-Control-Allow-Origin: *

 

in de header voldoende zou zijn. Moet daar nog iets voor of achter?

[Peter Wagemans]

Hier heb je'm inclusief die header.

WebViewerHelper.fmplugin.zip

[andries]

ik denk dat je nog moet zeggen dat "GET" toegelaten is, zoals

res.header('Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE');

 

zal al eens testen!

[andries]

[andries]

ik heb ook het gevoel dat je het nu allemaal meezendt in de body, en niet in de header.

 

als ik het test met POSTMAN (chrome extensie om webservices te testen) zie ik dat alles toekomt in de body, en dat de headers leeg zijn.

 

ps: ik weet zelf niet goed hoe je dit allemaal moet doen he ik zeg maar wat ik denk

[Peter Wagemans]

OK, deze geeft een

 

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Access-Control-Allow-Origin: *

En hopelijk kunt je het zonder een "Content-Length:" doen.

 

De 2 linefeeds doen het 'm natuurlijk. Ik herinner me dit van de Sharky tijd.

WebViewerHelper.fmplugin.zip

[Peter Wagemans]

Er is nog wat mis ergens. Een pointer die naar een variabele die ik niet zou mogen vrij maken omdat diet toegewezen is.

Wordt zoekwerk. C is heel plezierig op dat gebied.

Buiten dat die misschien af en toe crasht zou hij moeten werken voor de rest.

[Peter Wagemans]

Deze is een stuk stabieler.

 

Denk erom dat een listener poort altijd wat tijd nodig heeft tussen sluiten en opnieuw openen.

Als je dus de plug-in herinstalleert terwijl FileMaker draait, wacht een paar seconden vooraleer de poort te starten, of hij zal zeggen dat het niet lukt.

WebViewerHelper.fmplugin.zip

[andries]

hierbij een geimplementeerd voorbeeldje.

 

works like a charm

 

nu nadenken over hoe we die responses gaan doen, want die "*****REPLY****" en zo maakt het niet makkelijk om te gaan parsen in javascript .

 

Groetjes

 

Andries

WebViewerHelper.fmp12.zip

[andries]

ivm die header, doet mij trouwens denken aan een implementatie met SimpleTalk die ik ooit heb gedaan

 

Set Variable [ $send ; STalk_Send ( Get ( ScriptParameter ) ; "HTTP/1.1 200 OK" & Char(10) & Char(13) & Get ( ScriptResult ) ) ]

[andries]

er zit nog een probleem met het versturen van een lege parameter bijvoorbeeld ScriptNames ( "" ).

 

het probleem is meer generiek, en gaat hem om het gebruik van quotes... mss dat het wel aan mij ligt en dat ik die deftig moet coderen

 

als ik echter de code goed kan interpreteren die je hebt gepost voor het parsen van de inkomende datastroom, check je enkel voor de %20 en verander je die in een spatie, en wordt er geen algemene URL decoding toegepast. Klopt dit?

[andries]

nog een bugje, en ik denk dat we gaan moeten nadenken of we niet beter met GET parameters gaan werken (zoals fmp script protocol)

 

als een scriptnaam een spatie heeft werkt het niet, want wat na de tweede spatie komt geldt als scriptparameter.

 

Voorstel:

 

kunnen we niet zoiets doen:

 

http://localhost:10234/e?fn=Get(FileName)

 

http://localhost:10234/s?name=SCRIPTNAME&param=PARAMETER

 

Peter, ik bedoel niet dat jij dit allemaal moet doen he, het is gewoon om tot een degelijke "communicatie protocol" te komen dat ik wat opmerkingen post. Het kan ook allemaal in een javascript object worden opgenomen, zoals ik nu doe om het resultaat te parsen.

Alleen moet ik dan een manier hebben om een scriptnaam met spaties te kunnen doorsturen.

[andries]

nog een mini opmerking, de evaluatie speelt zich altijd af in de file wiens venster actief is, voor mij geen probleem!

[Peter Wagemans]

er zit nog een probleem met het versturen van een lege parameter bijvoorbeeld ScriptNames ( "" ).

 

het probleem is meer generiek, en gaat hem om het gebruik van quotes... mss dat het wel aan mij ligt en dat ik die deftig moet coderen

 

als ik echter de code goed kan interpreteren die je hebt gepost voor het parsen van de inkomende datastroom, check je enkel voor de %20 en verander je die in een spatie, en wordt er geen algemene URL decoding toegepast. Klopt dit?

 

Dat klopt. Ik heb er een simpele url decode functie ingestoken. Dit zou nu wel moeten werken.

WebViewerHelper.fmplugin.zip