Flytte records op og ned
Anders M
er der nogen der ligger inde med en funktion til at flytte
records op og ned p� en php side?
Mvh Anders
--
Vil du l�re at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- P�dagogiske tutorials p� dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials
Bertel Lund Hansen
> er der nogen der ligger inde med en funktion til at flytte
> records op og ned p� en php side?
Det m� du forklare n�rmere. Jeg forst�r ikke hvad du mener.
--
Bertel
http://bertel.lundhansen.dk/ FIDUSO: http://fiduso.dk/
Anders M
dk.edb.internet.webdesign.serverside.php:
Jeg har en masse records (afsnit), som skal vises i en bestemt
r�kkef�lge.. det skal man s� kunne styre fra en php side med f�
klik (op eller ned)
Birger Sørensen
> hej,
>
> er der nogen der ligger inde med en funktion til at flytte
>
> Mvh Anders
Hvad er en "record"?
(Og hvad er en php side?)
Hvis det du mener er rï¿œkker fra en database, kan det ikke umiddelbart
lade sig gï¿œre. (Ikke simpelt i hvert fald).
Rï¿œkker vises i den rï¿œkkefï¿œlge de findes/hentes fra databasen.
Hvis du ikke har nogen sortering (ORDER BY i SQL), vil det typisk (men
ikke nï¿œdvendigvis) vï¿œre rï¿œkkefï¿œlgen data er lagt i tabellen.
Sￜ det enkle svar pￜ det jeg tror dit spￜrgsmￜl handler om, er at sￜtte
data ind i databasen, i den rï¿œkkefï¿œlgge du vil have dem ud...
Birger
--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk
Anders M
> Anders M formulerede sp�rgsm�let:
> >
> > er der nogen der ligger inde med en funktion til at flytte
> > Mvh Anders
>
> Hvad er en "record"?
> (Og hvad er en php side?)
>
> lade sig g�re. (Ikke simpelt i hvert fald).
> R�kker vises i den r�kkef�lge de findes/hentes fra databasen.
> S� det enkle svar p� det jeg tror dit sp�rgsm�l handler om, er at s�tte
> data ind i databasen, i den r�kkef�lgge du vil have dem ud...
Jeg har lavet et felt "sort (int)"
Bertel Lund Hansen
> Jeg har en masse records (afsnit), som skal vises i en bestemt
> r�kkef�lge.. det skal man s� kunne styre fra en php side med f�
> klik (op eller ned)
Skal brugeren kunne v�lge forskellige, foruddefinerede
r�kkef�lger?
Bertel Lund Hansen
> Jeg har lavet et felt "sort (int)"
Pr�v om ikke du kan forklare det hele p� �n gang s� det er til at
forst�. Hvis vi skal tr�kke oplysningerne ud af dig �n ad gangen,
mister vi t�lmodigheden.
Anders M
dk.edb.internet.webdesign.serverside.php:
Du g�r det mere kompliceret end det er.. det skal bare v�re ligesom
dette (under move) hvor man kan rytte siderne op og ned
http://www.headscape.co.uk/images/cms.jpg
Birger Sørensen
> Birger Sï¿œrensen wrote in dk.edb.internet.webdesign.serverside.php:
>> Anders M formulerede spï¿œrgsmï¿œlet:
>>>
>>> er der nogen der ligger inde med en funktion til at flytte
>>> Mvh Anders
>>
>> Hvad er en "record"?
>> (Og hvad er en php side?)
>>
>> lade sig gï¿œre. (Ikke simpelt i hvert fald).
>> Rï¿œkker vises i den rï¿œkkefï¿œlge de findes/hentes fra databasen.
>> Birger
>>
>> --
>> http://varmeretter.dk - billig, sund og hurtig mad
>> http://bbsorensen.dk
>>
>>
>
> Jeg har lavet et felt "sort (int)"
Sￜ er det du skal vel, at ￜndre vￜrdierne i det felt, nￜr brugeren
klikker...
Jeg holder lidt med Bertel - du giver ikke ret mange oplysninger ;o)
Og det er ikke nemt at give et brugbart svar, nï¿œr man skal gï¿œtte sig
til det du har, hvad der kan vï¿œre galt, og hvordan det er tï¿œnkt at
skulle fungere..
Peter Farsinsen
> Jeg har lavet et felt "sort (int)"
S� skal du sortere din query efter det felt. F.eks.:
SELECT * FROM `dintabel` ORDER BY `sort` DESC
L�s mere her: http://dev.mysql.com/doc/refman/5.0/en/sorting-rows.html
Du skal desuden have noget logik, der kan opdatere feltet 'sort' i din
database, n�r en r�kke tilf�jes, slettes eller flyttes en plads op eller
ned. Det kan v�re lidt tricky ... eksempler:
N�r en r�kke rykkes en placering op:
- 'sort' dekrementeres med �n
- R�kken der f�r havde denne placering, skal inkrementeres med �n i
feltet 'sort'
N�r en r�kke slettes:
- R�kker med en h�jere v�rdi i feltet 'sort', end den slettede, skal
dekrementeres med �n.
Hvis du kan implementere ovenst�ende, kan du vist ogs� regne de to
sidste tilf�lde ud ;)
--
Peter Farsinsen
for...@efternavn.dk
Bertel Lund Hansen
> Du g�r det mere kompliceret end det er.. det skal bare v�re ligesom
> dette (under move) hvor man kan rytte siderne op og ned
Her er en testside:
http://temp.lundhansen.dk/movetest.php
Og koden:
<?
session_start();
if (!isset($_SESSION['infolines']))
$_SESSION['infolines'] = array (
'Tekst der skrives til sk�rmen',
'En anden tekst der skrives til sk�rmen',
'En tredje tekst der skrives til sk�rmen',
);
$infolines=&$_SESSION['infolines'];
$last=count($infolines)-1;
?>
<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN' 'http://www.w3.org/TR/html4/strict.dtd'>
<html>
<head>
<title>Movetest</title>
<meta http-equiv='Content-Type' content='text/html; charset=ISO-8859-1'>
<meta http-equiv='imagetoolbar' content='no'>
</head>
<body>
<?
for ($nr=0; $nr<count($infolines); ++$nr) {
if (isset($_POST['down'.$nr])) {
$temp=$infolines[$nr];
$infolines[$nr]=$infolines[$nr+1];
$infolines[$nr+1]=$temp;
}
if (isset($_POST['up'.$nr])) {
$temp=$infolines[$nr];
$infolines[$nr]=$infolines[$nr-1];
$infolines[$nr-1]=$temp;
}
}
echo "<form action='' method='post'>
<table>
";
foreach ($infolines as $nr => $line) {
echo "<tr><td>$line</td>";
if ($nr<$last) echo "<td><input type='submit' name='down$nr' value='Ned'></td>";
else echo "<td> </td>";
if ($nr) echo "<td><input type='submit' name='up$nr' value='Op'></td>";
else echo "<td> </td>";
echo "</tr>\n";
}
echo "</table>
</form>";
?>
</body>
</html>
Stefan Kristensen
>> dette (under move) hvor man kan rytte siderne op og ned
>
> Her er en testside:
>
> http://temp.lundhansen.dk/movetest.php
>
> Og koden:
Hmm...
Ikke noget jeg har brug for lige nu, men det ryger helt sikkert i
v�rkt�jskassen - Takker :-)
Mvh
Stefan
Anders M
dk.edb.internet.webdesign.serverside.php:
Det vil jeg t�nke over i fremtiden..
Jeg har gjort det, at jeg har sat mig grundigt ind i AJAX og PHP, s�
jeg har lavet en funktion "Drag and drop"..
Mvh Anders M
Martin
> Anders M wrote:
>> Jeg har lavet et felt "sort (int)"
>
> S� skal du sortere din query efter det felt. F.eks.:
>
> SELECT * FROM `dintabel` ORDER BY `sort` DESC
Bem�rk lige at sort er et reserveret ord, s� uden plinger ` s� vil man
f� kylet en query error retur.
>
> L�s mere her: http://dev.mysql.com/doc/refman/5.0/en/sorting-rows.html
>
> Du skal desuden have noget logik, der kan opdatere feltet 'sort' i din
> database, n�r en r�kke tilf�jes, slettes eller flyttes en plads op eller
> ned. Det kan v�re lidt tricky ... eksempler:
>
> N�r en r�kke rykkes en placering op:
>
> - 'sort' dekrementeres med �n
> - R�kken der f�r havde denne placering, skal inkrementeres med �n i
> feltet 'sort'
Hvis man bruger javascript / ajax, s� er det meget nemmere at f� alle
produkter/sider/you.name.it i den korrekte r�kkef�lge - s� slipper man
for 3 database queries :)
Et lille friskt eksempel her
http://jsbin.com/uqebe3/
> - R�kker med en h�jere v�rdi i feltet 'sort', end den slettede, skal
> dekrementeres med �n.
Beh�vs man da ikke.
sort 1-3-5
giver jo stadig den korrekte r�kkef�lge.
Martin
> Anders M skrev:
>
>> Du g�r det mere kompliceret end det er.. det skal bare v�re ligesom
>> dette (under move) hvor man kan rytte siderne op og ned
>
> Her er en testside:
>
> http://temp.lundhansen.dk/movetest.php
Hehehe.... har du nogensinde pr�vet at bruge s�dan en, n�r man skulle
flytte 19 elementer... GAL det tager kedelig tid.
http://jsbin.com/uqebe3/
Lidt hurtigere m�ske :)
Bertel Lund Hansen
> Hehehe.... har du nogensinde pr�vet at bruge s�dan en, n�r man skulle
> flytte 19 elementer...
Nej da. Men det var heller ikke det der blev spurgt om.
> http://jsbin.com/uqebe3/
> Lidt hurtigere m�ske :)
M�ske, men den l�ser ikke det problem du rejser. I �vrigt
for�rsager den en JavaScript-note som skal klikkes v�k hver gang.
Peter Farsinsen
>> Anders M wrote:
>>> Jeg har lavet et felt "sort (int)"
>>
>> S� skal du sortere din query efter det felt. F.eks.:
>>
>> SELECT * FROM `dintabel` ORDER BY `sort` DESC
>
> Bem�rk lige at sort er et reserveret ord, s� uden plinger ` s� vil man
> f� kylet en query error retur.
Bem�rk plingerne ;) Det er desuden OP, der har valgt feltnavnet 'sort'.
>> L�s mere her: http://dev.mysql.com/doc/refman/5.0/en/sorting-rows.html
>>
>> Du skal desuden have noget logik, der kan opdatere feltet 'sort' i din
>> database, n�r en r�kke tilf�jes, slettes eller flyttes en plads op
>> eller ned. Det kan v�re lidt tricky ... eksempler:
>>
>> N�r en r�kke rykkes en placering op:
>>
>> - 'sort' dekrementeres med �n
>> - R�kken der f�r havde denne placering, skal inkrementeres med �n i
>> feltet 'sort'
>
> Hvis man bruger javascript / ajax, s� er det meget nemmere at f� alle
> produkter/sider/you.name.it i den korrekte r�kkef�lge - s� slipper man
> for 3 database queries :)
Jeg har lidt sv�rt ved at se relevansen? Ja, hvis du vil flytte en r�kke
uden at gemme �ndringen, s� fint nok, men hvis �ndringen skal gemmes i
en database, vil logikken v�re den samme uanset, hvordan din request sendes.
>> - R�kker med en h�jere v�rdi i feltet 'sort', end den slettede, skal
>> dekrementeres med �n.
>
> Beh�vs man da ikke.
> sort 1-3-5
> giver jo stadig den korrekte r�kkef�lge.
Go' pointe ;)
--
Peter Farsinsen
for...@efternavn.dk
Stig Johansen
>>> SELECT * FROM `dintabel` ORDER BY `sort` DESC
>>
>
> Bem�rk plingerne ;) Det er desuden OP, der har valgt feltnavnet 'sort'.
Det er i det hele taget en god id� at undg� reserverede ord, og ikke mindst
plinger (og [] ved MS SQLServer), s� man undg�r database afh�ngighed.
Hvorfor har du plinger omkring dintabel ?
(Hvis man kun bruger mySQL nu, og i fremtiden, s� se bort fra mit indl�g)
--
Med venlig hilsen
Stig Johansen
Peter Farsinsen
> Peter Farsinsen wrote:
>
>>>> SELECT * FROM `dintabel` ORDER BY `sort` DESC
>> Bem�rk plingerne ;) Det er desuden OP, der har valgt feltnavnet 'sort'.
>
> Det er i det hele taget en god id� at undg� reserverede ord, og ikke mindst
> plinger (og [] ved MS SQLServer), s� man undg�r database afh�ngighed.
Det skal vi ikke sk�ndes om. Nu tog jeg bare udgangspunkt i OP's
eksisterende layout.
> Hvorfor har du plinger omkring dintabel ?
Gammle vane... Det er ik' s� tit, jeg rent faktisk skriver SQL l�ngere.
> (Hvis man kun bruger mySQL nu, og i fremtiden, s� se bort fra mit indl�g)
Nu svarede jeg alligevel ;)
--
Peter Farsinsen
for...@efternavn.dk
Philip Nunnegaard
> Det er i det hele taget en god id� at undg� reserverede ord,
Og nok en af de v�sentligeste grunde til at jeg hurtigt begyndte at
bruge danske felt- og variabelnavne (det var i 2002, mens jeg var ved at
l�re asp og brugte Access-database).
S� var sandsynligheden for at ramme et reserveret ord langt mindre.
Eneste problem jeg da har oplevet, var med "by", hvor jeg s� valgte
enten "city", "bynavn" eller noget lignende.
--
Philip - http://chartbase.dk | http://www.hitsurf.dk
Leif Neland
> Martin skrev:
>
>> Hehehe.... har du nogensinde pr�vet at bruge s�dan en, n�r man skulle
>> flytte 19 elementer...
>
> Nej da. Men det var heller ikke det der blev spurgt om.
>
>> http://jsbin.com/uqebe3/
>> Lidt hurtigere m�ske :)
>
> M�ske, men den l�ser ikke det problem du rejser. I �vrigt
> for�rsager den en JavaScript-note som skal klikkes v�k hver gang.
>
Selvf�lgelig skal alert-boxen ikke komme i produktionsudgaven.
Leif
Martin
> Martin skrev:
>
>> Hehehe.... har du nogensinde pr�vet at bruge s�dan en, n�r man skulle
>> flytte 19 elementer...
>
> Nej da. Men det var heller ikke det der blev spurgt om.
Det rigtigt nok, men det ligger nu alligevel i baggrunden af sp�rgsm�let
- men nok fordi jeg engang havde en liste p� 200+ elementer hvor de
skulle kunne sorteres, og fra dengang der ved jeg hvor irriterende det
er at bruge op og ned pile/knapper :)
>
>> http://jsbin.com/uqebe3/
>> Lidt hurtigere m�ske :)
>
> M�ske, men den l�ser ikke det problem du rejser. I �vrigt
> for�rsager den en JavaScript-note som skal klikkes v�k hver gang.
Ja, debug er altid rart - s� man kan se hvad der bliver sendt afsted til
ajax scriptet - nu kan man jo ikke ligefrem lave et ajax kald p� jsbin :)
Martin
>> Hvis man bruger javascript / ajax, s� er det meget nemmere at f� alle
>> produkter/sider/you.name.it i den korrekte r�kkef�lge - s� slipper man
>> for 3 database queries :)
>
> Jeg har lidt sv�rt ved at se relevansen? Ja, hvis du vil flytte en r�kke
> uden at gemme �ndringen, s� fint nok, men hvis �ndringen skal gemmes i
> en database, vil logikken v�re den samme uanset, hvordan din request
> sendes.
Nej, absolut ikke...
Hvis du kun f�r sortering fra 1 produkt, s� skal du lave 3 opkald til
databasen.
1. opkald finde produkterne f�r og efter dit valgte produkt
2. opkald opdater nuv�rende produkt
3. opkald sorterer de produkter skal v�re f�r og efter.
Bahh, er nok liidt sv�rt at forst� hehe
Stig Johansen
> Stig Johansen skrev:
>
>> Det er i det hele taget en god id� at undg� reserverede ord,
>
> Eneste problem jeg da har oplevet, var med "by", hvor jeg s� valgte
> enten "city", "bynavn" eller noget lignende.
Ja, by er en klassiker.
Men mit indl�g var lige s� meget et hint om at undg� diverse database
's�regne' - ting (aka vendor lockin)
Normalt skal man slet ikke bruger plinger, eller lignende.
Standard ville man bruge(I Peters tilf�lde):
SELECT * FROM "dintabel" ORDER BY "sort" DESC
Uvist af hvilke �rsager, s� har mySQL valgt de d�r m�rkelige plinger:
SELECT * FROM `dintabel` ORDER BY `sort` DESC
som (formentlig) ikke underst�ttes af andre databaser.
P� samme m�de vil William nok foresl�:
SELECT * FROM [dintabel] ORDER BY [sort] DESC
(I MS SQLSever 6.5, hvilket var sybase, var default dog "-er).
S� hintet var bare, at hvis man har planer om databaseuafh�ngighed, s� undg�
disse 'm�rkelige' konstruktioner.
S�:
SELECT * FROM dintabel ORDER BY sortnbr DESC
ville nok v�re et bedre bud.
Peter Farsinsen
> Peter Farsinsen wrote:
>>> Hvis man bruger javascript / ajax, s� er det meget nemmere at f� alle
>>> produkter/sider/you.name.it i den korrekte r�kkef�lge - s� slipper man
>>> for 3 database queries :)
>> Jeg har lidt sv�rt ved at se relevansen? Ja, hvis du vil flytte en r�kke
>> uden at gemme �ndringen, s� fint nok, men hvis �ndringen skal gemmes i
>> en database, vil logikken v�re den samme uanset, hvordan din request
>> sendes.
>
> Nej, absolut ikke...
Kan vi blive enige om at en HTTP request (groft) er det samme uanset,
hvordan den submittes?
> Hvis du kun f�r sortering fra 1 produkt, s� skal du lave 3 opkald til
> databasen.
Jeg forst�r stadig ikke, hvad din pointe er, men jeg vil naturligvis
gerne forst� den, hvis du sidder og gemmer p� en genial l�sning p�
problemet ;)
Foresl�r du, at 'logikken' laves client side i javascript, hvorefter man
submitter sorteringen for /alle/ r�kker, som s� opdateres i databasen
med �t kald?
--
Peter Farsinsen
for...@efternavn.dk
Martin
> Martin wrote:
>> Peter Farsinsen wrote:
>>>> Hvis man bruger javascript / ajax, s� er det meget nemmere at f� alle
>>>> produkter/sider/you.name.it i den korrekte r�kkef�lge - s� slipper man
>>>> for 3 database queries :)
>>> Jeg har lidt sv�rt ved at se relevansen? Ja, hvis du vil flytte en r�kke
>>> uden at gemme �ndringen, s� fint nok, men hvis �ndringen skal gemmes i
>>> en database, vil logikken v�re den samme uanset, hvordan din request
>>> sendes.
>>
>> Nej, absolut ikke...
>
> Kan vi blive enige om at en HTTP request (groft) er det samme uanset,
> hvordan den submittes?
Jo, men mere hvor meget der submittes - med pile op og ned, s� submittes
der 1 produkt, og 1 sortering - s� er det serverside sproget der skal
finde ud af hvordan en del af de andre produkter skal sorteres, og
opdateres i databasen.
>
>> Hvis du kun f�r sortering fra 1 produkt, s� skal du lave 3 opkald til
>> databasen.
>
> Jeg forst�r stadig ikke, hvad din pointe er, men jeg vil naturligvis
> gerne forst� den, hvis du sidder og gemmer p� en genial l�sning p�
> problemet ;)
Alts� hvis det kun drejer sig om 1-5 produkter, s� er det egentlig lige
meget, men jeg har pr�vet at sidde med en liste p� 200+ produkter hvor
der kun var op og ned pil - og det tog LANG TID, s� jeg lavede hurtigt
et plugin til firefox, som gjorde det af sig selv (der var ikke mulighed
for nogle javascript l�sning desv�rre)
>
> Foresl�r du, at 'logikken' laves client side i javascript, hvorefter man
> submitter sorteringen for /alle/ r�kker, som s� opdateres i databasen
> med �t kald?
Nemlig! - 1 kald med alle produkter og sorteringer p� 1 gang, s� kan der
laves 1 update query og vupti s� er alt opdateret.
Peter Farsinsen
>>> Nej, absolut ikke...
>>
>> Kan vi blive enige om at en HTTP request (groft) er det samme uanset,
>> hvordan den submittes?
>
> Jo, men mere hvor meget der submittes - med pile op og ned, s� submittes
> der 1 produkt, og 1 sortering - s� er det serverside sproget der skal
> finde ud af hvordan en del af de andre produkter skal sorteres, og
> opdateres i databasen.
Godt s�. Jeg er enig med dig i at drag n' drop nok er en mere langsigtet
l�sning, men OP har meget eksplicit �nsket pile, hvorfor jeg forholdt
mig til det.
>> Foresl�r du, at 'logikken' laves client side i javascript, hvorefter
>> man submitter sorteringen for /alle/ r�kker, som s� opdateres i
>> databasen med �t kald?
>
> Nemlig! - 1 kald med alle produkter og sorteringer p� 1 gang, s� kan der
> laves 1 update query og vupti s� er alt opdateret.
Lad os nu forestille og, at der er tale om mange r�kker - f.eks. 20.000.
Din l�sning vil kun virke, hvis der postes et id (eller lign.) for alle
r�kker - alts� 20.000 i eksemplet.
P� et eller andet tidspunkt tror jeg, kurven kn�kker, s� det er
hurtigere at lave to-tre queries end at loope et gigantisk array igennem
og konkatenere stumperne sammen til en gigantisk query.
Jeg har ikke t�nkt mig at lave benchmarks, men feel free... ;)
--
Peter Farsinsen
for...@efternavn.dk
Leif Neland
>
> Godt s�. Jeg er enig med dig i at drag n' drop nok er en mere langsigtet
> l�sning, men OP har meget eksplicit �nsket pile, hvorfor jeg forholdt
> mig til det.
>
Det skader ikke at komme med et bedre forslag end det, "kunden" har
t�nkt p�. M�ske ved "kunden" slet ikke at man kan lave drag 'n' drop.
>
> Lad os nu forestille og, at der er tale om mange r�kker - f.eks. 20.000.
> Din l�sning vil kun virke, hvis der postes et id (eller lign.) for alle
> r�kker - alts� 20.000 i eksemplet.
>
Antallet af r�kker, der skal h�ndteres, er nok begr�nset af hvad der kan
v�re p� en sk�rm.
Jeg vil *meget n�dig* skulle sortere 20.000 r�kker i h�nden.
Leif
Chano Andersen
> S� hintet var bare, at hvis man har planer om databaseuafh�ngighed, s� undg�
> disse 'm�rkelige' konstruktioner.
Det er vel langt mere logisk, blot at samle al database adgang i f�
klasser, s� kan man n�jes med at �ndre SQL s�tninger i database
klasserne, hvis man skulle finde p� at skifte database system.
Der er alt for mange forskelle p� SQL mellem forskellige database
systemer, til at man kan undg� at rette koden alligevel, s� at samle
sine queries i f� klasser og s� blot levere parametre og arrays (Eller
lignende) retur til scriptet, vil sikre, at man blot �ndre f� filer, i
stedet for at skulle gennemg� al kode. (Med mindre, naturligvis, man
n�jes med simple select, insert, update og delete queries.)
- Chano Andersen