eigen framework / beheersysteem
Pagina: « vorige 1 2 3 ... 6 7 8 9 10 11 12 volgende »
Quote:
Da's een korte htaccess :-))))
Klopt, maar meer heb je niet nodig :)
Quote:
Kun je nog iets zeggen over mijn versie...
Zie bovenstaande ;) En die van mark is eigenlijk ook nog te groot vind ik, maar ja iedereen zijn eigen mening he :)
En deze? Om te voorkomen dat bestanden (waaronder htaccess) direct worden aangeroepen? RewriteCond %{REQUEST_FILENAME} .(inc|ini|p?ht.*|php.*|txt)$
Ozzie PHP op 07/01/2011 22:39:53:
Oke, maar waarom deze niet: Options All -Indexes (beveiligen tegen het tonen van directories)
Options All? All? Is dat wel zo'n goed idee? En heb je dat allemaal nodig? -Indexes kan handig zijn, maar als je geen bestanden in je webroot hebt, of alleen de publieke bestanden zoals css en js, dan kan het ook geen kwaad als het wel aan staat. +FollowSymLinks toevoegen kan nog nuttig zijn.
Quote:
En deze? Om te voorkomen dat bestanden (waaronder htaccess) direct worden aangeroepen? RewriteCond %{REQUEST_FILENAME} .(inc|ini|p?ht.*|php.*|txt)$
Betere oplossing: niet in je webroot zetten, zodat ze nooit toegankelijk zijn via http. Dan hoef je toegang ook niet te blokkeren. Ook als je server dan faalt en plots vergeet je htaccess te lezen, of mod_rewrite even niet meer werkt omdat iemand die apache module heeft uitgeschakeld, zijn je bestanden nog veilig.
Wat je nog wel kan toevoegen is Options +FollowSymLinks. Volgens de handleiding is dat noodzakelijk voor mod_rewrite. To enable the rewrite engine in this context, you need to set "RewriteEngine On" and "Options FollowSymLinks" must be enabled..
Pfff, lastig dat htaccess. Ik dacht dat Options All -Indexes betekent dat er nooit een directory kan worden getoond. Dat kan dan toch geen kwaad om dit aan te zetten? Of is het slecht voor de performance of iets dergelijks?
"Betere oplossing: niet in je webroot zetten, zodat ze nooit toegankelijk zijn via http." Helemaal mee eens hoor, maar stel dat iemand mijn framework ooit gebruikt en toch een config file in de webroot zet.... Tuurlijk, dan kun je zeggen dat ie dat niet had moeten doen, maar waarom gewoon niet dichttimmeren via htaccess. Of heeft dit weer andere nadelige gevolgen als ik dat doe?
Die followsymlinks is volgens mij alleen van toepassing als je met <directory> gaat werken. De tekst "in this context" slaat op de zin erboven volgens mij.
Hoe dan ook, ik wil een htaccess bestand dat zoveel mogelijk bescherming biedt. Ik snap niet zo goed waarom iedereen die opties weglaat. Je wil toch juist een soort van bescherming bieden? Zelfs in je webroot? Baadt het niet dan schaadt het niet zou ik dan zeggen. Of wordt je site soms traag van die extra opties?
Gewijzigd op 08/01/2011 01:50:16 door Ozzie PHP
Niels Kieviet op 07/01/2011 22:24:36:
En die van mark is eigenlijk ook nog te groot vind ik, maar ja iedereen zijn eigen mening he :)
Ben het met je eens dat het beperken van request methoden niet echt in een .htaccess thuis hoort. Wel probeer ik altijd zo veel mogelijk binnen .htaccess te regelen. Denk hierbij aan algemene configuratie en response headers, GZip compressie en caching.
Aan de topicstarter zou ik meegeven dat je gewoon moet beginnen met programmeren en dan kijken waar het schip strandt. Het heeft weinig zin eeuwig door te gaan over een bepaald component (in dit geval .htaccess), in 99% van de gevallen maak je later toch nog wel wat aanpassingen. Succes!
Gewijzigd op 08/01/2011 21:37:38 door Mark PHP
Ik wil dat het bestandje ook voor veiligheid zorgt op het moment dat het terecht komt op een server die slecht geconfigureerd is. Het htaccess bestand moet dan voor extra veiligheid zorgen. Dat is wat ik wil.
"Het heeft weinig zin eeuwig door te gaan over een bepaald component (in dit geval .htaccess), in 99% van de gevallen maak je later toch nog wel wat aanpassingen. Succes!" Hier zit zeker wat in, maar ik wil in ieder geval een goede basis hebben snap je?
PS werkt de mail functie niet meer. Heb geen mail ontvangen dat ik een update had...
Quote:
Ik wil dat het bestandje ook voor veiligheid zorgt op het moment dat het terecht komt op een server die slecht geconfigureerd is. Het htaccess bestand moet dan voor extra veiligheid zorgen. Dat is wat ik wil.
Tja, dan kan je alles wel gaan beveiligen. denk eens aan, magic quotes en nog meer van dat onzin.
Ik houd hem altijd zo simpel mogelijk. Wil de programmeur hem uitbreiden omdat zijn host niet 'betrouwbaar' is dan kan hij dat toch zelf doen?
Quote:
Hier zit zeker wat in, maar ik wil in ieder geval een goede basis hebben snap je?
Precies zoals je zegt, een basis. Dat is in mijn ogen een niet al te groot maar toch functionele htaccess, en die heb ik je dus gegeven ;)
Maar goed, zoals Mark al zei: "dat je gewoon moet beginnen met programmeren en dan kijken waar het schip strandt".
Quote:
PS werkt de mail functie niet meer. Heb geen mail ontvangen dat ik een update had...
Uitgeschakeld bij voorkeuren? :)
Oke... stel je hebt een framework gebaseerd op het MVC model. Dan stop je je views dus in aparte view (phtml) bestanden. Maar nu vraag ik me het volgende af. Stel je hebt een CMS-systeem. Qua layout zijn de pagina's in een CMS-systeem veelal hetzelfde. Ik kan me bijvoorbeeld voorstellen dat je een pagina hebt waarop je een user aanmaakt en een pagina waarop je een product invoert. Deze pagina's hebben allebei dezelfde header en footer, maar ze hebben ook allebei een paginatitel en een formulier waar je de gegevens van een user of product kunt invoeren. Header en footer lijkt me vrij logisch dat je die standaard voor iedere pagina toont, maar de content daartussen hou je variabel.
De user aanmaken pagina en product invoeren pagina zoals hierboven genoemd zijn uitsluitend bedoeld als voorbeeld. Je kunt je voorstellen dat je nog veel meer pagina's hebt, die bestaan uit een titel en een formulier. Het gaat er in ieder geval om dat je een aantal pagina's hebt die er qua opmaak hetzelfde uitzien.
En nu komt mijn vraag. Volgens het MVC model maak je voor iedere pagina een eigen view maar wat nu als veel pagina's op elkaar lijken? Ga je nu voor iedere pagina een aparte view (lees phtml bestand) maken, of regel je dit met een soort overkoepelend script? In de 1e situatie krijg je in het geval van de user aanmaken en product invoeren pagina's dan 2 afzonderlijke bestanden. In die bestanden staat hardcoded een titel en een formulier. In het laatste geval zou je 1 bestand krijgen waarin je de titel als variabele echoot en waarin het formulier via een script wordt opgebouwd.
In situatie 1 zou je de view (ongeveer) als volgt maken waarbij alle gegevens hardcoded in de view worden geplaatst:
makeView('user.phtml');
makeView('product.phtml');
en in situatie 2 zou je een view genereren waarbij de gegevens via variabelen worden doorgegeven aan de 'formulier view'.
makeFormView('User aanmaken.', $array('naam', 'leeftijd'), 'verzenden');
makeFormView('Product invoeren.', $array('artikelnummer', 'naam'), 'voer in');
Wat is nu de juiste / handigste / meest gangbare manier? Manier 2 lijkt me de makkelijkste en snelste manier + het resultaat (de view) ziet er altijd hetzelfde uit. Echter, wellicht is deze manier niet de bedoeling van het MVC model. Manier 1 is wat lastiger omdat je voor iedere pagina een apart bestand moet maken. Je bent echter wel flexibeler dan in situatie 2.
Ben benieuwd naar jullie visie.
Kijk eens naar Zend_View zou ik zeggen, die hebben dat netjes oplost. En wanneer je de default layout niet nodig hebt kan je hem daar gewoon uitschakelen op switchen met een andere :)
Overigens hoeven je template bestanden niet per definitie de extensie .phtml te hebben. .tpl kan ook gewoon.
Wat ik normaal (nu nog via Zend) doe is dat ik een layout.phtml bestand heb met daarin de html structuur van de pagina (html, head, body) en in de body toon ik dan het variabele view (content) gedeelte, wat in feite het includen van een phtml bestand is.
Is dat wat jij bedoelt? Maar de vraag blijft nog steeds, ga je voor vergelijkbare views een "view script" maken of gewoon voor iedere pagina een view bestand. Wat is praktisch?
"Overigens hoeven je template bestanden niet per definitie de extensie .phtml te hebben. .tpl kan ook gewoon."
Dat heb ik dan weer wel van Zend :|
Gewijzigd op 20/01/2011 13:59:19 door Ozzie PHP
Ik kan me voorstellen dat een view script voor formulier pagina's heel handig is, maaaar... stel ik wil na een tijdje de lay-out van een specifieke formulier pagina aanpassen, dan gaat dit niet want dan pas ik alle formulieren aan. Dus dan moet ik alsnog een aparte view maken. Vandaar dus mijn vraag.. wat is wijsheid?
In de controllers/acties die ik bouw, zit ook een mogelijkheid om een andere layout op te geven, of zelfs geen layout (dat is wel fijn bij antwoorden op een XHR-verzoek, of bij een file-download); dat werkt ook zo. De ouderklasse zet (protected) $this->layout op 'default', de afgeleide klassen mogen 'm veranderen.
Hoe bedoel je dit precies? Ik snap niet helemaal wat je bedoelt eigenlijk. Kun je een voorbeeld geven?
Ik heb laatst dit gemaakt:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
<?php
class View extends ContainerAware
{
protected $extend;
protected $extendVars;
protected $helpers;
/**
* @param string $_viewFile The file, .phtml is appended
* @param array $_data The data for the view
* @return string The result
*/
public function render($_viewFile, $_data = array())
{
$this->helpers = $this->container->getSubContainer('view_helper_');
$_path = __DIR__.'/App/views/'.$_viewFile.'.phtml';
if(!file_exists($_path))
throw new InvalidArgumentException(sprintf(
"Viewfile '%s' not found at '%s'",
$_viewFile, $_path
));
extract($_data);
ob_start();
require_once $_path;
$content = ob_get_clean();
if(isset($this->extend)) {
$this->extendVars['content'] = $content;
return $this->container->view->render($this->extend, $this->extendVars);
} else
return $content;
}
/**
* Use a parent view. The result of the child view is set
* as the content variable in the parent view.
* @param string $viewFile The parent file, .phtml is appended
* @param array $_data The data for the parent view
*/
protected function extend($viewFile, $data = array())
{
$this->extend = $viewFile;
$this->extendVars = $data;
}
/**
* Include the result of another view
* @param string $_viewFile The file, .phtml is appended
* @param array $_data The data for the view partial
* @return string The result
*/
protected function partial($viewFile, $data = array())
{
return $this->container->view->render($viewFile, $data);
}
/**
* Escape a string for use in HTML
* @param string $string The string
* @return string The escaped result
*/
protected function e($string)
{
return htmlspecialchars($string, ENT_QUOTES);
}
}
?>
class View extends ContainerAware
{
protected $extend;
protected $extendVars;
protected $helpers;
/**
* @param string $_viewFile The file, .phtml is appended
* @param array $_data The data for the view
* @return string The result
*/
public function render($_viewFile, $_data = array())
{
$this->helpers = $this->container->getSubContainer('view_helper_');
$_path = __DIR__.'/App/views/'.$_viewFile.'.phtml';
if(!file_exists($_path))
throw new InvalidArgumentException(sprintf(
"Viewfile '%s' not found at '%s'",
$_viewFile, $_path
));
extract($_data);
ob_start();
require_once $_path;
$content = ob_get_clean();
if(isset($this->extend)) {
$this->extendVars['content'] = $content;
return $this->container->view->render($this->extend, $this->extendVars);
} else
return $content;
}
/**
* Use a parent view. The result of the child view is set
* as the content variable in the parent view.
* @param string $viewFile The parent file, .phtml is appended
* @param array $_data The data for the parent view
*/
protected function extend($viewFile, $data = array())
{
$this->extend = $viewFile;
$this->extendVars = $data;
}
/**
* Include the result of another view
* @param string $_viewFile The file, .phtml is appended
* @param array $_data The data for the view partial
* @return string The result
*/
protected function partial($viewFile, $data = array())
{
return $this->container->view->render($viewFile, $data);
}
/**
* Escape a string for use in HTML
* @param string $string The string
* @return string The escaped result
*/
protected function e($string)
{
return htmlspecialchars($string, ENT_QUOTES);
}
}
?>
Dat kan je dan als volgt gebruiken:
hello.phtml
Code (php)
layout.phtml
Code (php)
Dit geeft met naam 'Pim'
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Site - Hi Pim</title>
</head>
<body>
Hello Pim!
</body>
</html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Site - Hi Pim</title>
</head>
<body>
Hello Pim!
</body>
</html>
Gewijzigd op 24/01/2011 13:49:53 door Pim -
Stel dat ik nu een formulier script maak dan is het enige waarvoor ik bang ben dat ik straks pagina''s niet meer kan terugvinden omdat die geen eigen view hebben maar worden opgebouw via een view script. Ik zie mezelf al een half uur lang naar een bestand zoeken wat uiteindelijk helemaal niet blijkt te bestaan.
Misschien moet ik dan toch voor iedere formulier pagina een eigen bestand maken, maar daar dan een viewhelper fucntie in maken?
createuser.phtml
Code (php)
1
2
2
<h1>User aanmaken</h1>
<?php $view->generateForm($this->user_data); ?>
<?php $view->generateForm($this->user_data); ?>
Zoiets?
view
controller
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
<?php
if($_SERVER['REQUEST_METHOD'] == 'POST') {
$validator = $this->container->validator;
try {
// validate($string, $method)
$validator->validate($_POST['email'], 'email');
$validator->validate($_POST['username'], 'username');
$validator->validate($_POST['password'], 'password');
$user = new User;
$user->setName($_POST['name']);
$user->setEmail($_POST['email']);
$user->setPassword($_POST['password']);
$user->save();
} catch(ValidationException $e) {
// Doe er iets leuks mee
}
}
?>
Maar dit wordt erg ingewikkeld. Mooier zijn dingen als:
<?php
if($_SERVER['REQUEST_METHOD'] == 'POST') {
$form = $this->container->form->get('user');
// Geef de post informatie aan het form
$form->setData($_POST);
if($form->validate()) {
// Vul het user object in
$user = $form->populate(new User);
$user->save();
} else {
$this->view->form = $form->render(); // Ingevuld
}
}
?>
Maar dat zit een stuk ingewikkelder in elkaar. Je krijgt dan een form klasse die aan de hand van een configuratie bestand weet hoe een formulier eruit moet zien, hoe hij ingevuld wordt, hoe hij gecontrolleerd wordt en hoe die gegevens dan in een user object moeten worden gestopt.
Maar als je dat eenmaal hebt, dan heb je ook wat ;)
if($_SERVER['REQUEST_METHOD'] == 'POST') {
$validator = $this->container->validator;
try {
// validate($string, $method)
$validator->validate($_POST['email'], 'email');
$validator->validate($_POST['username'], 'username');
$validator->validate($_POST['password'], 'password');
$user = new User;
$user->setName($_POST['name']);
$user->setEmail($_POST['email']);
$user->setPassword($_POST['password']);
$user->save();
} catch(ValidationException $e) {
// Doe er iets leuks mee
}
}
?>
Maar dit wordt erg ingewikkeld. Mooier zijn dingen als:
<?php
if($_SERVER['REQUEST_METHOD'] == 'POST') {
$form = $this->container->form->get('user');
// Geef de post informatie aan het form
$form->setData($_POST);
if($form->validate()) {
// Vul het user object in
$user = $form->populate(new User);
$user->save();
} else {
$this->view->form = $form->render(); // Ingevuld
}
}
?>
Maar dat zit een stuk ingewikkelder in elkaar. Je krijgt dan een form klasse die aan de hand van een configuratie bestand weet hoe een formulier eruit moet zien, hoe hij ingevuld wordt, hoe hij gecontrolleerd wordt en hoe die gegevens dan in een user object moeten worden gestopt.
Maar als je dat eenmaal hebt, dan heb je ook wat ;)
Pagina: « vorige 1 2 3 ... 6 7 8 9 10 11 12 volgende »