Portalen dynamisch sorteren

[menno]

Op de volgende url http://www.filemakertips.nl/?p=79 heb ik een (fmp12-)voorbeeldje gepost hoe je portaalrecords kan sorteren op ieder willekeurig veld. De techniek vrij gemakkelijk to kopiëren en te plakken in je eigen oplossing.

 

Ik heb het idee gekregen van een voorbeeld van mindfire-solutions, maar dat vond ik een te ingewikkelde techniek om over te nemen en heb er dus mijn eigen draai aan gegeven

 

Oh ja, dit werkt ook prima in een multiuseromgeving

er is ook nog een kanttekening: wil je op deeplink-velden sorteren, dan zal je een berekening van dat veld in je portaaltabel moeten opnemen

 

[edit dd=19-05-2015]Links aangepast tbv verplaatste website[/edit]

19 september 2015 aangepast door Gast

[Roger]

Ik vind het zeer indrukwekkend Menno maar kun je de scripts van beide oplossingen misschien nog wat nader toelichten? Want het ziet er toch nog best ingewikkeld uit hoor (voor sommigen onder ons).

[Felix]

.

4 oktober 2015 aangepast door Gast

[menno]

Ik had een pracht uitleg geschreven, om er achter te komen, dat jij het beter had uitgelegd .... mijn uitleg gescrapt ,hahaha

 

Even over je slotopmerking: je hebt gelijk, dit is iets wat veel mensen al jaren willen en m.i. dankzij executeSQL kan het met één of twéé velden (ik heb het voorbeeld uitgebreid met een tweede variant) en dan is het vrij simpel op te nemen in een systeem.

 

Je kan in bijvoorbeeld tabel-layout de mogelijkheid aanzetten om op kolomkoppen te sorteren door er op te klikken en het zou leuk zijn dat die eigenschap ook aan portalen zou kunnen worden gehangen. Ik denk dat ze dat vast ook al in een lab-versie van FM7 hebben gehad ..... je kan echter in portalen ook deep-linken en dat lijkt me een stuk lastiger. De techniek in mijn voorbeeld vereist daar dat je daarvoor een berekend veld in je portaalrecord opneemt (die hoef je natuurlijk niet te tonen, je kan gewoon de gedeeplinkte waarde tonen en eventueel op zoeken).

[WJ]

Mooie techniek,

 

Ik vraag me alleen af hoe het zit met de snelheid. Je vraagt immers alle records op gesorteerd op. Vervolgens laat je ieder records uitrekenen welke positie hij inneemt in deze lijst. Daarna sorteer je op deze unstored.

 

Hoe zit het met grote datasets gaat dat goed ?

 

Groet,

 

WJ

[Roger]

Hartelijk dank Felix voor de uitleg en Menno voor het delen van de techniek. Leuk om eens proberen na te bouwen op een regenachtige zondagmiddag.

[menno]

Mooie techniek,

 

Ik vraag me alleen af hoe het zit met de snelheid. Je vraagt immers alle records op gesorteerd op. Vervolgens laat je ieder records uitrekenen welke positie hij inneemt in deze lijst. Daarna sorteer je op deze unstored.

 

Hoe zit het met grote datasets gaat dat goed ?

 

Groet,

 

WJ

 

Je vraagt niet alle records op want daar zorgt in dit voorbeeld

WHERE "_OrganisationID"='$uuid'

voor.

Wat je dus opvraagt zijn alleen de gerelateerde records van het record waar je op dat moment naar kijkt. Als je echter een soort "global" record hebt waarmee je naar bijvoorbeeld alle facturen in je systeem kijkt, dan kan je vanaf 500+ record zichtbare vertragingen verwachten. Je kan je dan echter wel afvragen of die manier van werken wel de way to go is, want als je naar een abstracte hoeveelheid records kijkt, dan kan je dat beter met een lijstview doen ipv via een portaal.

 

Heb je gezien dat op de layout ook een scripttrigger zit op "onrecordload"?

 

Misschien is dit een sessie op de FM-summit waard, daar wil ik het graag uitleggen

[WJ]

Ik bedoelde ook alle records uit de relatie waarop de portal is gebaseerd, die je eigenlijk namaakt via de het SQL commando. Als de relatie verandert moet je niet vergeten het SQL commando ook aan te passen.

500 records is ongeveer de limiet begrijp ik, dat lijkt inderdaad best acceptabel. Maar dan moeten er niet meerdere portalen op de layout staan denk ik zo. En via het WAN ? zal de limiet nog eerder bereikt zijn. En is dat met een lichte tabel of uitgebreide tabel?

 

Beetje mee oppassen zou ik zeggen, perfomance is toch belangrijker dan funky stuff. Zou het toch niet zo snel inzetten. Wellicht kan je het tweaken met de SQL limit functie maar volgens mij wordt deze niet door FM ondersteund.

 

Zou mooi zijn als FM het eens inbouwd en dan ook meteen dat je de breedte van een kolom kunt wijzigen.

 

Groet,

 

WJ

[menno]

Meerdere (gesorteerde) portalen op een layout moet je eigenlijk altijd mee oppassen. Meestal probeer ik het niet te doen, maar daar heeft de klant uiteindelijk meer invloed op dan ik ... hij is degene die betaalt en uiteindelijk dus ook bepaalt hij, ondanks mijn kanttekeningen wat er wordt gebouwd.

 

Ik heb bij geen enkele klant een dashboard oid met meerdere portalen, maar wel in enkele systemen een projectoverzicht waar soms meerdere portalen op staan. Daar staan in de portaaltabellen eigenlijk nooit meer dan 50 portaalrecords bij één header-record, met 5 of 6 portalen is dat ook gesorteerd op ongeïndexeerde waarden is dat nog steeds snel.

 

Die 500+ is ook geen wet, de snelheid is evenzogoed afhankelijk van de optelsom van hardware, infrastructuur, de rest van je programmering etc. daarbij vind ik al wanneer je meer dan 100 records in een portaal toont, dat je moet gaan nadenken om een andere oplossing te gaan verzinnen. Maar dat is uiteraard maar mijn mening, als een gebruiker het prima vindt/acceptabel vindt om even 10 seconden op resultaat te wachten .... dan vind ik het ook best en krijgt hij het van me. Je kan geen tegengas blijven geven

[rgaros]

Dag Menno,

 

Is het een uitdaging om het te vereenvoudigen en zonder SQL op te lossen? Als er belangstelling is wil ik een prototype bestand van mij wel presentabel maken en uploaden.

 

Mvg,

René

[menno]

Hi René,

 

laat jouw voorbeeld gerust zien, leuk!

 

mvg, Menno

[Ari]

Bijgaand een voorbeeldje van ascending en descending sort in portaal

Sorteren.fmp12

[menno]

Natuurlijk zijn er meerdere wegen die naar Rome leiden en dat geldt hier ook, er is geen manier die dé manier is. Voor elke methode is wel een goede reden om hem te gebruiken.

 

In dit geval is de gedachte om altijd op dezelfde manier en op dezelfde basis een sortering voor elkaar te krijgen ... in een portaaltabel is er altijd maar één berekening die er altijd op dezelfde manier uitziet en dat is in deze opzet

Position ( PrimaryKeyList ; PrimaryKey ; 1 ; 1 )

De PrimaryKeyList mag een global zijn of een variabele, maar dat hoeft niet persé, dat is een keuze van de ontwikkelaar. De methode is simpel en altijd en overal toe te passen en je hoeft er niet (meer) over na te denken.

Uiteraard is het wel zaak om de PrimaryKeys altijd even lang te hebben óf de formule een klein beetje aan te passen zoals:

Position ( ¶ & PrimaryKeyList & ¶ ; ¶ & PrimaryKey & ¶ ; 1 ; 1 )

 

De rest van het voorbeeld is eigenlijk totaal onbelangrijk, behalve dat je op één of andere manier de PrimaryKeyList zult moeten samenstellen. In dit geval heb ik ExecuteSQL gebruikt, maar kan je dat even gemakkelijk doen met de list()-functie ... ik zat op het moment dat ik dit voorbeeld maakte in een stevige ExecuteSQL-fase, maar eigenlijk is dat niet de essentie van het voorbeeld, dat is de berekening in de portaalrecords

[Ari]

Hoe generieker hoe beter Menno dus in dat opzicht heb je helemaal gelijk! Mijn voorbeeld kan wat eenvoudiger worden toegepast door alleen een SortText en een SortNum veld toe te passen. Meestal wordt er toch alleen oplopend gesorteerd en datum en tijd velden kunnen met getasnumber naar numeriek worden omgezet.

[menno]

Is het een uitdaging om het te vereenvoudigen en zonder SQL op te lossen?

Bij deze een voorbeeld zonder gebruik te maken van executeSQL, het is te vinden op:

Het artikel met de beschrijving en

Hier het nieuwe voorbeeldbestand (Het oude voorbeeld is ook nog steeds te downloaden )

Mijn persoonlijke mening: het werkt, maar ik vind executeSQL beduidend eenvoudiger en sneller in te bouwen. Echter als je niet gediend bent van executeSQL of gewoon nog niet zo handig, dan kan deze techniek prima van pas komen. Veel plezier!

 

[edit dd=19-05-2015]Links aangepast tbv verplaatste website[/edit]

19 september 2015 aangepast door Gast

[rgaros]

Ik heb mijn demo-bestandje even opgepoetst. Kleurtjes maar vooral volgestampt met opmerkingen en toelichtingen.

Verschilt niet zo veel van die van Menno behalve dat ik alle getal, datum, tijd en tijdstempel-velden op dezelfde manier behandel. En GetField() gebruikt ipv Evalueren() en IsEmpty() ipv = ""

Qua veldnamen doe ik aan gewoon Nederlands, geen veldtype-aanduiding in de naam en wel spaties.

 

De techniek heb ik voor een aantal klanten ingebouwd, waaronder een met portalen die vaak meer dan 300 gerelateerde records bevatten en ook qua snelheid prima werken.

Wel kwam ik er achter dat mijn demo-bestand (en ook die van Menno) negatieve getallen niet goed sorteert. Daarvoor heb ik een aanpassing gemaakt.

 

Het bestand is gratis en kan zonder opgave van e-mail adres e.d. gedownload worden: http://www.reneros.biz/filemaker/tips-trucs/bestanden/Portaal_Sorteren.fmp12

Algemene info op: http://www.reneros.biz/filemaker/tips-trucs/index.php#N117

 

Echter als je niet gediend bent van executeSQL of gewoon nog niet zo handig

'Niet handig' slaat hopelijk niet op mij.

Maar ook ben ik best gediend van SQL en heb het ook in FM toegepast. Ik heb echter de sterke overtuiging dat eerst alle FM functionaliteit benut moet worden (die moet de ontwikkelaar dan wel kennen) omdat het de eenvoudigste methodes biedt waarvan FileMaker Inc. zorgt dat het goed en snel blijft werken. Plug-ins, AppleScript en SQL hebben die zekerheid minder.

Het is wat overdreven maar ik moet altijd even denken aan een bedrijf waar ik ooit ben gevraagd langs te komen. De in-house developer had zelf een database gemaakt. Al snel werd duidelijk dat hij deskundiger was in AppleScript omdat 'AppleScript uitvoeren[]' de enige gebruikte scriptstap was. Verder had hij alles in AppleScript nagebouwd - op zich best knap. De vraag aan mij was hoeveel tijd het kost om de database geschikt te maken voor Windows...

 

Mvg,

René

[Infomatics]

Mooie demo René!

 

Groet,

 

Ruben

[rgaros]

Eenmaal weer wakker blijkt sorteren op negatieve getallen toch niet te werken.

Berekening in voorbeeldbestand heb ik aangepast, het ondersteunt voorlopig geen negatieve getallen.

 

Zie even geen oplossing. Het zou mooi zijn als we gemakkelijk een unieke getalwaarde van een tekst konden achterhalen, dan is geklooi met getallen naar tekst niet nodig.

Hash met MD5 enzo. Code() werkt niet goed om te sorteren. Ga ik later in duiken.

 

René

[Ari]

Gebruik ook een numeriek sorteerveld (zie mijn voorbeeldbestand eerder op deze draad)

[menno]

Hi Rene,

 

leuk voorbeeld en je legt meer uit dan ik én ook het mijne zonder SQL doet negatieve getallen verkeerd sorteren, zal er ook nog eens naar kijken, maar niet vandaag. Ik ben het met je eens dat als FM de functionaliteit biedt, dat je die eerst zou moeten toepassen, alleen verschillen jij en ik dan toch van mening wanneer het punt bereikt is dat je daar vanaf zou moeten wijken.

 

Overigens als ik jouw (en trouwens ook mijn eigen) voorbeeld vergelijk met het voorbeeld met daarin SQL toegepast, dan kies ik toch voor de versie met SQL, gewoon omdat het minder werk is. Uiteraard geldt hier dat de toepassing niet ongelimiteerd kan zijn, maar dat geldt voor noSQL-methode denk ik ook.

 

groet, Menno

[menno]

Ik heb het probleem met negatieve getallen die verkeerd worden gesorteerd opgelost met de onderstaande functie:

Let ( [ 
fieldtype = GetValue ( Substitute ( FieldType ( Get ( FileName ) ; SortField ) ; " " ; ¶ ) ; 2 ) ; 
fielddata = Evaluate ( SortField ) ; 
numdata = If ( fieldtype = "Number" ; Round ( 10^6 * GetAsNumber ( fielddata ) ; 6 ) ) ; 
numvalue = If ( numdata ≠ "" ; GetAsText ( If ( numdata < 0 ; "0" ) & 10^100+ numdata ) ) ;  
sortdata = Case ( fieldtype = "Text" ; fielddata ; 
				fieldtype = "Number" ; numvalue ; 
				Right ( "000000000000000" & GetAsNumber ( fielddata ) ; 15 ) 
		) 
] ; 
If ( PortalSortDirection = CalcSortDirection ; 
		Case ( fieldtype = "Text" ; fielddata ; 
				fieldtype ≠ "number" ; sortdata ; 
				Right ( "00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000" & Left ( sortdata ; 100 ) ; 100 ) 
	) 	// end-case
) 		// end-if
) 			// end-let

en dat werkt (met een paar beperkingen) prima.

 

Het nieuwe voorbeeld kan weer vanaf dezelfde plek worden gedownload.

 

Er zijn 2 beperkingen:

• # De getallen met fracties worden afgerond op 6 cijfers achter de komma, omdat bij grotere fracties soms onverwachte resultaten optreden
  # Getallen (afgerond op 6 cijfers) met een mantisse van meer dan 100 cijfers kunnen eveneens onverwachte resultaten geven

 

[edit dd=19-05-2015]Links aangepast tbv verplaatste website[/edit]