Ik vraag me af op welke manier je een efficiënt nieuwe data/gegevens enz laadt in dezelfde pagina.
Dit is nogal een vage omschrijving dus hier zijn een voorbeeld van wat ik graag zou bekomen maar waar ik zelf geen goed idee van heb hoe dit het best gedaan wordt.
voorbeeld:
Een pagina met daarin een formulierveld, in het formulierveld een paar standaard inputs zoals textboxen en checkboxen enz. daarnaast ook een drop-down menu met gegevens die uit een database worden gehaald, bv een opsomming van categorieën. de enige reden waarom die uit een database gehaald worden is vrij simpel, voor als er bijvoorbeeld een nieuwe wordt aangemaakt.
Hoe wordt het nu dus juist gedaan dat alle gegevens gecontroleerd worden zonder dat er naar een andere pagina verwezen wordt en waarna nieuwe content geladen wordt. Wat ik dus wil is dat ofwel de foutmelding, nieuwe content, een bevestiging, ... op dezelfde pagina getoond wordt.
Worden hiervoor gegevens via POST doorgestuurd op de achtergrond en wordt er bv met hidden fields gewerkt of ...?
Ik zou zulke problemen graag op een efficiënte manier oplossen. Kunnen jullie me hierbij helpen?
Alvast bedankt
Mvg
7 antwoorden
Gesponsorde links
Thomas - 17/12/2013 10:59 (laatste wijziging 17/12/2013 11:25)
Moderator
Tenzij het formulier megagroot is, dit formulier intensieve operaties moet uitvoeren bij de verwerking ervan (denk aan het uploaden van bestanden of afbeeldingen waar nog bewerkingen op uitgevoerd moeten worden) of wanneer je verwacht dat dit formulier in een heel kort tijdsbestand supervaak ingevuld gaat worden, lijkt mij dat de efficiëntie (wat bedoel je hier precies mee? CPU- of geheugen-gebruik? de moeite die je browser heeft met het renderen van je (complexe? grote?) formulier?) niet zo snel in het gedrang komt?
Als je een "normaal" formulier verstuurt om verwerkt te worden duurt dit verwerken meestal enkele of enkele tientallen milliseconden. Daarnaast is dit (vanwege de aard van HTTP) een stapsgewijs proces; het is niet iets wat constant een beroep op je resources doet?
In het algemeen is het denk ik waarschijnlijk belangrijker dat het formulier gebruiksvriendelijk is, en dat mag (vind ik) best wat kosten. Je moet het zo zien, je zult altijd een soort van afweging moeten maken. Het meest "efficiënte" is waarschijnlijk een platte HTML pagina met een rigoreuze JavaScript controle. Pas als alles helemaal klopt volgens deze controle stuur je het door naar een (PHP-)script om het te verwerken. Heel efficiënt, maar knetter onvriendelijk. Wat nu als er ergens bij het invullen iets mis gaat waardoor de JavaScript breekt, of dat de JavaScript wel accepteert maar PHP (want daar moet je die controles ook uitvoeren! JavaScript controles alleen zijn NOOIT genoeg) niet? Dan moet iemand het formulier opnieuw invullen? Lijkt mij een goede manier om mensen weg te jagen. Ook zijn alerts knetter lelijk en irritant. We leven niet meer in de jaren 90 . Een veel gebruiksvriendelijkere variant is een formulier wat je te allen tijde kunt versturen, en wanneer er iets fout blijkt te zijn, krijg je het formulier weer te zien, met ALLE invoer die je reeds hebt ingevuld, en de ontbrekende/verkeerd ingevulde velden voorzien van een markering en een foutboodschap met een toelichting van wat er fout is, of een hint van wat men verwacht dat je dan wel in moet vullen. Om dit allemaal bij te houden moet je wel wat werk verrichten, bijvoorbeeld door je POST data tijdelijk op te slaan in een sessie, of de navigatie van je formulier zo in elkaar steken dat je de POST data direct terug in kunt vullen in het formulier.
tl;dr: het is een tradeoff; gebruiksvriendelijkheid lijkt mij bij formulieren belangrijker dan efficiëntie (weet niet eens precies wat ik hier onder zou moeten verstaan).
Je zou het ook zo kunnen zien: uit oogpunt van "efficiëntie" van de gebruiker zou het formulier zo gebruiksvriendelijk moeten zijn dat deze het formulier in één poging goed invult .
Neemt niet weg dat je "common sense" kunt gebruiken bij het maken van een gebruiksvriendelijk formulier. Inefficiënte queries en code moet je altijd van wegsturen...
EDIT: spelling en laatste noot
EDIT: wat ik wel vaak zie, bijvoorbeeld bij registratieformulieren waarbij je een handle/nickname moet kiezen is dat er middels AJAX-calls op de achtergrond wordt gecontroleerd of deze nog beschikbaar is. Dat kost ook wat (HTTP requests, script parsing, databasequeries) maar dat is wel heel erg netjes en gebruiksvriendelijk. Niets is zo irritant als een registratieformulier 20x versturen waarbij je telkens de boodschap krijgt dat die NICKNAME AL IN GEBRUIK IS grrrrrrr.
EDIT: Of bedoel je dat je vaak formulieren maakt, en daarbij niet elke keer het wiel opnieuw wilt uitvinden? Dat soort efficiëntie? Dan loont het misschien de moeite om een framework te gebruiken of er zelf eentje te schrijven, toegespitst op het maken van formulieren. Dat stelt je dan in staat om snel formulieren te bouwen en standaard controles uit te voeren op invoer. Je zou hierbij objectgeoriënteerde code kunnen schrijven. Speerpunten van object georienteerd programmeren zijn herbruikbaarheid en uitbreidbaarheid. Is ook, mits correct toegepast, efficiënt.
EDIT: En het ironische daarvan is, dat doordat je extra complexiteit introduceert, bijvoorbeeld in de vorm van een framework, het geheel ("de code") over het algemeen wat trager wordt.
Wederom een tradeoff:
+complexiteit/gebruikersgemak (voor zowel programmeur als eindgebruiker)
-snelheid
Maar hardware is vandaag de dag (stukken) snel(ler) dus het maakt minder uit dan voorheen hoe (in)efficiënt code is, neemt niet weg dat dit aspect maar buiten beschouwing moet worden gelaten, het speelt -in ieder geval hier- een minder grote rol.
Ik had meer gehoopt op een iets praktische beschrijving van hoe dit effectief geprogrammeerd wordt?
Zoals bijvoorbeeld:
Je hebt een pagina met een aantal geregistreerde gebruikers. Per gebruiker heb je de optie om deze te verwijderen, admin te maken enz.
De code om telkens zo een extra opdracht uit te voeren per gebruiker, neem je die ofwel in dezelfde pagina op of roep je telkens een aparte verwijderpagina op om die bewerking uit te voeren.
En stel dat je het in dezelfde pagina opneemt, hoe wordt dit dan geschreven? Door telkens gegevens in sessies te plaatsen, door te sturen via hidden fields met POST of ...?
Als je dit zelf wilt gaan schrijven hangt dit af van je programmeerniveau, wat voor kwaliteit het systeem moet hebben en hoe je deze in wilt gaan zetten (wat moet het doen/kunnen).
Is het voor een professionele site, voor een kleine groep gebruikers of is dit meer een soort van programmeeroefening?
Ook zijn er een heleboel standaard pakketten verkrijgbaar, denk bijvoorbeeld aan Joomla.
In je bovenstaande voorbeeld, wat nou niet direct het eenvoudigste is (een beheersysteem voor leden), kun je een heleboel zaken onderscheiden, die je ook apart kunt behandelen:
- een ledenadministratie ("leden admin")
- een rollen/rechten administratie ("rechten admin")
- een soort van authorisatiesysteem die je toegang geeft tot deze functionaliteit ("loginsysteem")
- een formuliersysteem voor het snel bouwen van formulieren/het valideren van de data
Je kunt dit op een heleboel manieren indelen en programmeren, maar welke vorm je ook gebruikt, je indeling zal waarschijnlijk gecentreerd zijn rondom "acties", bijvoorbeeld in het geval van de "leden admin" hierboven:
- het toevoegen van een lid
- het wijzigen van informatie van een lid
- het verwijderen van een lid
- het zoeken van informatie over een lid op grond van zoektermen
- het tonen van een overzicht van leden, gesorteerd en gepagineerd
Dat zijn zaken (acties) die ik in een "leden admin" zou verwachten.
Al deze acties moeten op een of andere manier herkend/geinterpreteerd kunnen worden door een machine. Dit kun je doen door deze acties toegankelijk te maken door het aanroepen van een unieke URL. Stel bijvoorbeeld dat je alle leden-admin-functionaliteit groepeert in één PHP-bestand ledenadmin.php, dan zou je de acties beschikbaar kunnen maken via een parameter in je URL:
ledenadmin.php?actie=gebruiker_toevoegen
En voor bepaalde bewerkingen die betrekking hebben op één specifiek lid, zal je moeten vertellen welk lid dit is:
ledenadmin.php?actie=gebruiker_wijzigen&id=12
ledenadmin.php?actie=gebruiker_verwijderen&id=12
en als je zoekt, geef je de zoekparameters mee:
ledenadmin.php?actie=zoeken&naam=henk
Dan heb je nog de routering van deze URL naar de code die de actie daadwerkelijk uitvoert, want je moet het systeem ook vertellen hoe je dit moet doen als je deze code zelf schrijft.
En je moet er natuurlijk voor zorgen dat niet ieder (ongeauthoriseerd) persoon toegang heeft tot deze acties, het zou namelijk vervelend zijn als iemand leden kan verwijderen door het simpelweg aanroepen van:
ledenadmin.php?actie=gebruiker_verwijderen&id=1
ledenadmin.php?actie=gebruiker_verwijderen&id=2
ledenadmin.php?actie=gebruiker_verwijderen&id=3
et cetera...
De ledeninformatie zit in je database en trek je uit je database op het moment dat je die nodig hebt. Dit hangt af van je actie.
In je sessie zou ik enkel informatie stoppen die te maken heeft met:
- authorisatie informatie, op deze manier wordt onthouden dat je bent ingelogd
- mogelijk zoektermen of de laatst bekeken pagina van je ledenoverzicht
Hier zou ik niet allerhande informatie in proppen die je toch maar 1% van de tijd nodig hebt... Je sessie is NIET bedoeld als rijdend archief, daarvoor heb je je database.
Als je het niet helemaal zelf wilt schrijven, maar snel iets wil bouwen, zou je Zend Framework kunnen proberen. Ik weet verder niet hoe het zit met jouw programmeerniveau of -ervaring, maar op sitemasters staan best een aantal tutorials over Zend Framework die goed te volgen zijn. Je hebt dan wel webruimte nodig die PHP/MySQL ondersteunt en enige ervaring met object georienteerd programmeren en (in het verlengde daarvan) MVC. Als deze termen je niets zeggen zou ik met iets eenvoudigers beginnen. In dat geval is het bekijken van scripts hier (al was het maar voor inspiratie) en het zelf uitproberen / beredeneren van zaken nog de beste leerschool. Dit is ook een geleidelijk proces, het lijkt me niet verstandig in het midden te beginnen als je de basis nog niet helemaal begrijpt...
Ik zou zeggen, probeer eens wat uit, en kom dan met vragen als je vastloopt. Bekijk de tutorials en scripts.
Wel het is namelijk zo dat ik php graag wel zou kunnen de basis ken ik toch wel al denk ik. Ik ben overlaatst een tijdje bezig geweest met onderstaande code om het probleem van vorige post op te lossen. Daar ik dus totaal niet wist of ik wel juist bezig was ben ik er dan ook maar even mee gestopt. Zou je eens even onderstaande code kunnen bekijken en eventuele opmerkingen geven van wat beter kan of van wat op een andere manier moet worden uitgewerkt?
Zoals je zal zien werk ik dus via commando's (cmd) die ik meegeef in de url samen met de user_id waarna ik dan ook telkens controleer of de persoon over de juiste rechten beschikt.
Hartelijk bedankt voor je tijd die je al aan eerdere reacties spendeerde.
Wow haha. echo echo echo echo. Je kunt PHP blokken starten en stoppen hoor .
Anyway, dit is niet echt leesbaar/onderhoudbaar met het stapelen van al die if/elseif/else blokken. Als je zo code schrijft zou ik op zijn minst wat annotatie (commentaar in de code) toevoegen om ervoor te zorgen dat je weet welk deel wat doet.
Voor al deze blokken zou ik aparte actions maken, immers, ze vervullen verschillende rollen: het afdrukken van een formulier, het verwerken van een formulier etc.
Zo kun je voorkomen dat je al die controles op elkaar moet stapelen. En als je die controles dan ook nog eens netjes opdeelt in acties wordt het geheel een stuk overzichtelijker.
Ik heb ff supersnel iets in OOP in elkaar geflanst, onder andere geinspireerd door Zend Framework en een CMS waar ik in het verleden aan/mee gewerkt heb. Hiermee kun je best snel pagina's etc bouwen, misschien ga ik hier nog een soort van frameworkje van bouwen, probeer het eens uit.
Ook een goede programmeergewoonte is "one entry" (of hoe het ook heet) oftewel één voordeur voor je applicatie, in dit geval index.php. Ik geef hierbij aan hoe de folderstructuur zou moeten zijn:
<?php
require_once './pagetype.php'; // the PageType class, from which all other pagetypes are derived
$rootDir = getcwd(); // for security, we do not want to include external sources...
$defaultPage = 'default/page';
$page = isset($_GET['page']) ? $_GET['page'] : $defaultPage;
$page = str_replace('/', DIRECTORY_SEPARATOR, $page); // Windows/Linux style directory (back)slashes
// check if the page we are trying to load exists
if (file_exists($rootDir.DIRECTORY_SEPARATOR.$page.'.php')) {
$content = $rootDir.DIRECTORY_SEPARATOR.$page.'.php';
} else {
// page did not exist after all, load default page, or perhaps an error page
$page = str_replace('/', DIRECTORY_SEPARATOR, $defaultPage);
$content = $rootDir.DIRECTORY_SEPARATOR.$defaultPage.'.php';
}
require_once $content;
// rewrite $page to a classname (for example admin/members becomes AdminMembers)
$className = implode('', array_map('ucfirst', explode(DIRECTORY_SEPARATOR, $page)));
if (class_exists($className)) {
// create an instance of this class and execute its routing routine (will select an appropriate action to perform)
$contentInstance = new $className();
$contentInstance->exec();
} else {
// some error in the naming convention...
die('classname not found: '.$className);
}
?>
<?php
require_once'./pagetype.php';// the PageType class, from which all other pagetypes are derived
$rootDir=getcwd();// for security, we do not want to include external sources...
<?php
abstract class PageType
{
// determine which action (method) to perform; the default action (method) is actionDefault
public function exec() {
$action = 'action'.(isset($_GET['action']) ? ucfirst($_GET['action']) : 'Default');
if (method_exists($this, $action)) {
$this->$action();
} else {
$this->actionDefault();
}
}
// a link function, for convenience
protected function link($page='', $args=array(), $escape=false) {
$link = 'index.php?page='.$page;
if (count($args)) {
$temp = array();
foreach ($args as $k => $v) {
$temp[] = urlencode($k).'='.urlencode($v);
}
$link .= '&'.implode('&', $temp);
}
return ($escape ? htmlentities($link) : $link);
}
// all classes which are derived from PageType need to at least implement this method (actionDefault)
// all action-methods you write should either be protected (so you can still extend these)
// or private; they do not have to be public because they should be called through the
// only public method all these PageType classes have: exec()
protected abstract function actionDefault();
}
?>
<?php
abstract class PageType
{
// determine which action (method) to perform; the default action (method) is actionDefault
aanroepen met jouw_folder/index.php?page=admin/members&action=test et cetera.
Includes voor sessie/database zou je in index.php op kunnen nemen, of in de indivdiuele pagetype classes.
En dit is maar een variant, er zijn er legio verschillende denkbaar, alleen deze werkt redelijk intuitief en is supersimpel. Mogelijk geeft je dit wat inspiratie hoe je je code beter kunt organiseren.
Je kunt ook in eerste instantie voor een tussenvorm kiezen, in PHP is het prima toegestaan om zowel OOP als procedureel (rechttoe-rechtaan) te programmeren.
Overigens is objectgeoriënteerd programmeren geen noodzakelijke voorwaarde voor het aanbrengen van structuur in je eigen code, maar het kan helpen.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
. Een veel gebruiksvriendelijkere variant is een formulier wat je te allen tijde kunt versturen, en wanneer er iets fout blijkt te zijn, krijg je het formulier weer te zien, met ALLE invoer die je reeds hebt ingevuld, en de ontbrekende/verkeerd ingevulde velden voorzien van een markering en een foutboodschap met een toelichting van wat er fout is, of een hint van wat men verwacht dat je dan wel in moet vullen. Om dit allemaal bij te houden moet je wel wat werk verrichten, bijvoorbeeld door je POST data tijdelijk op te slaan in een sessie, of de navigatie van je formulier zo in elkaar steken dat je de POST data direct terug in kunt vullen in het formulier.
.
Actiefste leden van de maand
