Portal op basis van gebruiker

[burggraaf]

Stel een multiple user database (met FMServer en clients). Voor elke gebruiker is een record met een eigen id. Het aantal gebruikers kan varieren.

 

Een portal laat de waarden uit een tabel zien. De bedoeling is dat als gebruiker A een zoekopdracht uitvoert alleen de gevonden waarden van gebruiker A in de portal worden getoond. Als gebruiker B een zoekopdracht uitvoert moet gebruiker B alleen de waarden zien in de portal die voor hem zijn gevonden. Dus ook als gebruiker A en B een verschillende opdracht hebben uitgevoerd moeten zijn hun eigen gevonden set records in de portal zien en niet die van elkaar.

 

Om een 'waarom geen' vraag voor te zijn: een list view is geen optie, het moet in een portal.

 

Hoe is dit het beste aan te pakken?

[AvD]

Maak van de primary key een global: die kan voor iedereen verschillend zijn. Hiertoe moete je het "zoeken" natuurlijk wel vervangen door "relationeel tonen".

[burggraaf]

Maak van de primary key een global: die kan voor iedereen verschillend zijn. Hiertoe moete je het "zoeken" natuurlijk wel vervangen door "relationeel tonen".

Inderdaad maar... Hoe toon je het dan relationeel... het keyfield in de te tonen tabel moet dan steeds wijzigen afhankelijk van de zoekopdracht moet soms geen, soms 1 en soms meerdere gebruikers bevatten, kortom moet steeds kunnen wiijzigen en kan geen global zijn...

28 mei 2007 aangepast door Gast

[AvD]

Dan vrees ik dat ik je vraag en probleemstelling niet begrepen heb.

[burggraaf]

De portal moet een set gevonden records bevatten van de desbetreffende gebruiker. De relatie die je legt met de tabel van de portal kan dus verschillen. Gebruiker A moet andere records kunnen zien als gebruiker B (afhankelijk van de zoekopdracht die de afzonderlijke gebruikers hebben gegeven). Het veld in van de tabel in de te tonen portal moet natuurlijk een indexeerbaar veld zijn anders lukt de relatie niet. Deze moet dus niets of de waarde:

 

A

 

OF

 

B

 

OF

 

A

B

 

(eigenlijk ID's) bevatten. Maar als gebruiker A een nieuwe zoekopdracht uitvoert zal de waarde van dit veld moeten wijzigen. In sommige records zal de A uit het veld gehaald moeten worden (maar als B erin staat moet deze natuurlijk blijven staan) in andere zal A erbij gezet moeten worden.

[WJ]

Hoi,

 

Ik heb het ook niet helemaal begrepen. Maar je kunt records tonen regelen in je privilege sets. Daarmee ook dus in een portal.

 

Groet,

 

WJ

[WJ]

2de poging.

 

Je kunt een global vullen met de ID's die de gebruiker heeft gevonden. MutliKey relatie maken met de tabel en het is gelukt. Je moet dan dus wel altijd de zoek scripten en de standaard zoek vervangen. Niet echt ideaal. Je kunt ook zelf een portal maken met recursie. Dan kan de gewone zoek nog gebruikt blijven.

 

Groet,

 

 

WJ

[burggraaf]

Mmm toch maar anders proberen voor te stellen, weet niet goed hoe het anders uit te leggen.... Privilegesets is niet wat ik zoek...

 

Gebruiker Record zichtbaar in portal na zoekopdracht

A ---------> 1

-----------> 2

-----------> 3

 

B ---------> 2

-----------> 3

-----------> 5

 

C -------- > 1

-----------> 5

 

Dus er moet een relatie zijn tussen gebruiker A en Record 1 maar ook tussen gebruiker C en record 1.

 

Nu wijzigt gebruiker A de zoekopdracht en wil dus bijv. de records 3 en 5 zien.

 

Dit betekent dat de relatie tussen gebruiker A en record 1 en 2 niet meer mag bestaan die tussen A en 3 mag blijven en tussen A en 5 moet dus gelegd worden.

 

A ---------> 3

-----------> 5

 

B ---------> 2

-----------> 3

-----------> 5

 

C -------- > 1

-----------> 5

 

De relaties van de andere gebruikers mogen daarbij niet gewijzigd worden...

[burggraaf]

Je kunt een global vullen met de ID's die de gebruiker heeft gevonden. MutliKey relatie maken met de tabel en het is gelukt.

Eh, stof tot nadenken.... Kan nl. een veld gaan geven met 100.000 waardes...

 

Je kunt ook zelf een portal maken met recursie. Dan kan de gewone zoek nog gebruikt blijven.

Eh. die begrijp ik weer even niet... Beter geformuleerd: ik zie niet zo hoe...

[JeanWM]

Je moet dan dus wel altijd de zoek scripten en de standaard zoek vervangen. Niet echt ideaal.

 

Niet helemaal akkoord (voor het niet ideaal gedeelte).

Er zit enorm veel kracht en flexibiliteit in scripting.

 

We schijnen nog teveel te denken: relatie = matching fields = matching values, waar we gewoon zouden moeten denken: relatie = matching values.

 

En hier kun je via scripting en de nu beschikbare variables (geen extra globals meer) elke combinatie maken die je wil...via scripts.

Via script = flexible = dynamic.

 

Dat geeft je ongekende mogelijkheden die niet haalbaar zijn indien je enkel op matching fields niveau blijft.

 

Maar dit is even off topic....

[burggraaf]

Je kunt een global vullen met de ID's die de gebruiker heeft gevonden. MutliKey relatie maken met de tabel en het is gelukt.

Eh, stof tot nadenken.... Kan nl. een veld gaan geven met 100.000 waardes...

Even getest maar is helaas niet echt een optie een zoekopdracht van 20.000 records duurt dan minimaal 7 minuten...

[WJ]

Hoi,

 

Ik denk dat de magic list van de clarify in jouw geval een ideale oplossing is.

 

Gr,

 

WJ

[burggraaf]

Tja, klinkt leuk maar geen idee waar je 't over hebt... Is er confituursessiemateriaal beschikbaar...?

[WJ]

Heb je de list funtie gebruikt bij je test ? Die moet toch behoorlijk snel zijn ?

[WJ]

Nee die heb ik gepresenteerd op de confituur sessie.

Het is een "fake" portal d.m.v. recursie.

 

Gr,

 

WJ

[Guido]

Niet heel moeilijk!

 

Als je bijvoorbeeld wilt zoeken op bedrijfsnaam;

 

Je maakt een global als zoekvak met bijvoorbeeld de naam "zoekveld"

Je maakt een berekening met de naam "relatie":

 

Case(not IsEmpty(zoekveld)

zoekveld & "aaa" [enter teken]

Zoekveld & "zzz"

)

 

(niet perse nodig maar ik gebruik dit wel altijd, hij vult zichzelf aan)

 

Je maakt een relatie met:

relatie > bedrijfsnaam

relatie < bedrijfsnaam

 

Klaar

[burggraaf]

@Guido

 

Zo simpel is 't helaas niet...

[Guido]

Want? het doet precies wat je zegt...

Wil je op meerdere velden zoeken? Dan moet je gewoon "bedrijfsnaam" een berekend veld laten worden met de belangrijkste indices

[burggraaf]

Heb je de list funtie gebruikt bij je test ? Die moet toch behoorlijk snel zijn ?

Eh ja maar dan zal dan toch moeten op basis van een relatie die eerst middels een zoekopdracht is gelegd hetgeen het weer kwetsbaar maakt.

[burggraaf]

Want? het doet precies wat je zegt...

Wil je op meerdere velden zoeken? Dan moet je gewoon "bedrijfsnaam" een berekend veld laten worden met de belangrijkste indices

Je hebt de 'casus' niet helemaal goed begrepen...

[burggraaf]

Nee die heb ik gepresenteerd op de confituur sessie.

Het is een "fake" portal d.m.v. recursie.

 

Ik hou me aanbevolen voor meer info... (alhoewel me bijstaat dat recusive functies niet verder gaan als 10.000 waarden, maar wellicht is dit een klok en klepel verhaal)

[WJ]

Tail recusie kan tot 60.000 dacht ik ?!

 

Maar goed in mijn voorbeeld hoeft hij maar 10 recursies te doen.

Ik zal een voorbeeld posten. Maar ik heb het nu alleen maar in klanten oplossingen zitten. Ik zal het daar dus uit moeten halen en een voorbeeld maken. Heb ik even tijd voor nodig.

 

Gr,

 

WJ

[burggraaf]

WJ, toch alvast bedankt, ben heel benieuwd...

[burggraaf]

Ik vond deze hele mooie van JMO.

 

De verschillende technieken worden daarin uitgelegd incl. doorlooptijden. De recursive functie werkt maar voor max. 10.000 keer (dus in mijn geval geen optie) maar de 'Variable Loop Prepend' is wellicht wel acceptabel...

 

Weer voldoende om te testen...

GetNthRecord.zip

[burggraaf]

'Variable Loop Prepend' doet 35 sec. op bijna 20.000 records. De recursive zou ongetwijfeld nog beter doen... (maar zoals al aangegeven in dit geval geen optie).

 

En toegegeven 35 sec. is al vele malen beter dan 7 minuten en vooralsnog zeker acceptabel.

 

WJ, mijn dank is groot voor alle hints en tips welke me hiertoe brachten!

[WJ]

Toch nog even opgezocht kon het niet laten

Tail recursie max 50.000

 

Gr,

 

Willem-Jan