Jump to content
  • 0

WebViewer Helper [1.0.0.28]


Peter Wagemans

Question

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]

Link to comment
  • Answers 136
  • Created
  • Last Reply

Top Posters For This Question

Top Posters For This Question

Posted Images

Recommended Posts

  • 0

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.

Link to comment
  • 0

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 :D

 

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 ) ;

}

}

Link to comment
  • 0

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.

Link to comment
  • 0

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.

Link to comment
  • 0

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

Link to comment
  • 0

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 :)

Link to comment
  • 0

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

Link to comment
  • 0

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?

Link to comment
  • 0

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.

Link to comment
  • 0
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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...