PHP Framework
Niels Kieviet op 15/08/2011 18:56:56:
In object.php zie ik de methode toString? Waarom? Gewoon echo van het object is toch prima? Dat vind ik overkill ;) Daar kan je jezelf beter druk om maken dat het bovenstaande denk ik .. Of niet?
Moet het niet zijn getObject? Maar wat voor nut heeft deze functie? Denk je zelf dat hij heel veel gebruikt gaat worden?
Daarnaast, in heel methode ontbreken controles of bijvoorbeeld: De file bestaat, de class bestaat, de methode bestaat.. Etc
Voor de basis van een MVC framework zou je misschien deze tutorial kunnen volgen? klik
Voor de rest ziet het er wel leuk uit!
Wat ook wel een mooi Framework is, één van onze bezoekers in het volgende: klik.. Er is ook nog een topic over: klik
Veel succes, goed op weg!
Niels
Moet het niet zijn getObject? Maar wat voor nut heeft deze functie? Denk je zelf dat hij heel veel gebruikt gaat worden?
Daarnaast, in heel methode ontbreken controles of bijvoorbeeld: De file bestaat, de class bestaat, de methode bestaat.. Etc
Voor de basis van een MVC framework zou je misschien deze tutorial kunnen volgen? klik
Voor de rest ziet het er wel leuk uit!
Wat ook wel een mooi Framework is, één van onze bezoekers in het volgende: klik.. Er is ook nog een topic over: klik
Veel succes, goed op weg!
Niels
1). toString is inderdaad nutteloos.
2). Deze methode geeft de Class_ instance van dit object wat reflectie makkelijk maakt.
3). Heb je een voorbeeld, ik zou het graag willen fixen.
Ook de Class_ klasse. Welk probleem wil je daar in godsnaam mee oplossen?
Verder is autoloading nogal noodzakelijk voor elk groot script.
#data/core.ini.php
; FaabBB Configuration file 3.008
Hoezo foutgevoelig? Gewoon de server juist configureren...
Je mapstructuur is ook onbegrijpelijk...
#core/mvc/MVCBootstrap.php
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
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
<?php
public static function getMvcUrlParser() {
$path = CORE_FOLDER . DS . 'mvc' . DS . 'url' .
DS . 'impl' . DS;
$name = CoreConfiguration::getInstance()->mvc_urlparser;
if ($name == null)
$name = "DefaultMVCUrlParser";
$file = $path . $name . PHP_SUFFIX;
if (!file_exists($file) || !is_readable($file)) {
$name = "DefaultMVCUrlParser";
$file = $path . $name . PHP_SUFFIX;
}
include($file);
if (!class_exists($name)){
throw new Exception("MVCUrlParser class with the name " . $name . " not found.");
return null;
}
return new $name();
}
?>
public static function getMvcUrlParser() {
$path = CORE_FOLDER . DS . 'mvc' . DS . 'url' .
DS . 'impl' . DS;
$name = CoreConfiguration::getInstance()->mvc_urlparser;
if ($name == null)
$name = "DefaultMVCUrlParser";
$file = $path . $name . PHP_SUFFIX;
if (!file_exists($file) || !is_readable($file)) {
$name = "DefaultMVCUrlParser";
$file = $path . $name . PHP_SUFFIX;
}
include($file);
if (!class_exists($name)){
throw new Exception("MVCUrlParser class with the name " . $name . " not found.");
return null;
}
return new $name();
}
?>
Eeeh? Als je nou een autoloader maakt, kan dat veel makkelijker.
Je CoreErrorHandler laat geen enkele ruimte over voor mooie/aanpasbare foutmeldingen.
Waarom zit de PharCreator in je core lib?
De constants van je CoreLoggingLevel kunnen toch ook in de logging klasse?
Waarom gebruik je sowieso niet systematische naamgeving?
Je script wel netjes, maar ik vind veel keuzes die je maakt echt onbegrijpelijk...
Pim - op 16/08/2011 13:14:06:
Die Object klasse van jou is een gruwel. Waarom???
Ook de Class_ klasse. Welk probleem wil je daar in godsnaam mee oplossen?
Verder is autoloading nogal noodzakelijk voor elk groot script.
#data/core.ini.php
; FaabBB Configuration file 3.008
Hoezo foutgevoelig? Gewoon de server juist configureren...
Je mapstructuur is ook onbegrijpelijk...
#core/mvc/MVCBootstrap.php
Eeeh? Als je nou een autoloader maakt, kan dat veel makkelijker.
Je CoreErrorHandler laat geen enkele ruimte over voor mooie/aanpasbare foutmeldingen.
Waarom zit de PharCreator in je core lib?
De constants van je CoreLoggingLevel kunnen toch ook in de logging klasse?
Waarom gebruik je sowieso niet systematische naamgeving?
Je script wel netjes, maar ik vind veel keuzes die je maakt echt onbegrijpelijk...
Ook de Class_ klasse. Welk probleem wil je daar in godsnaam mee oplossen?
Verder is autoloading nogal noodzakelijk voor elk groot script.
#data/core.ini.php
; FaabBB Configuration file 3.008
Hoezo foutgevoelig? Gewoon de server juist configureren...
Je mapstructuur is ook onbegrijpelijk...
#core/mvc/MVCBootstrap.php
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
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
<?php
public static function getMvcUrlParser() {
$path = CORE_FOLDER . DS . 'mvc' . DS . 'url' .
DS . 'impl' . DS;
$name = CoreConfiguration::getInstance()->mvc_urlparser;
if ($name == null)
$name = "DefaultMVCUrlParser";
$file = $path . $name . PHP_SUFFIX;
if (!file_exists($file) || !is_readable($file)) {
$name = "DefaultMVCUrlParser";
$file = $path . $name . PHP_SUFFIX;
}
include($file);
if (!class_exists($name)){
throw new Exception("MVCUrlParser class with the name " . $name . " not found.");
return null;
}
return new $name();
}
?>
public static function getMvcUrlParser() {
$path = CORE_FOLDER . DS . 'mvc' . DS . 'url' .
DS . 'impl' . DS;
$name = CoreConfiguration::getInstance()->mvc_urlparser;
if ($name == null)
$name = "DefaultMVCUrlParser";
$file = $path . $name . PHP_SUFFIX;
if (!file_exists($file) || !is_readable($file)) {
$name = "DefaultMVCUrlParser";
$file = $path . $name . PHP_SUFFIX;
}
include($file);
if (!class_exists($name)){
throw new Exception("MVCUrlParser class with the name " . $name . " not found.");
return null;
}
return new $name();
}
?>
Eeeh? Als je nou een autoloader maakt, kan dat veel makkelijker.
Je CoreErrorHandler laat geen enkele ruimte over voor mooie/aanpasbare foutmeldingen.
Waarom zit de PharCreator in je core lib?
De constants van je CoreLoggingLevel kunnen toch ook in de logging klasse?
Waarom gebruik je sowieso niet systematische naamgeving?
Je script wel netjes, maar ik vind veel keuzes die je maakt echt onbegrijpelijk...
1). Een voorbeeld: De hashcode functie is nodig voor een hashmap.
2). Gemakkelijker voor mensen die met reflectie werken. Nooit met java gewerkt?
3). Ten eerste, wat is er zo noodzakelijk aan autoloading. Nooit met java gewerkt?
Ten tweede, hier worden programmeurs slordig van.
4). Ik gebruik geen .htaccess omdat ik vind dat het beschikbaar moet zijn voor alle servers.
5). Waarom is mijn mapstructuur onbegrijpelijk?
6). Nee. Geen autoloader.
7). Het is nog niet af.
8). ....
9). Zoals.. Ik kan altijd verbeteren ;)
Gewijzigd op 16/08/2011 15:01:25 door Fabian M
2) Hoezo zou je dan zo'n dunne en nutteloze laag eroverheen gebruiken? En waarom zo'n onduidelijke naam?
3) Het is toch gewoon heel handig en waarom zou je er slordig van worden? Ook maakt het systematische naamgeving van je klassen noodzakelijk en dat is toch alleen maar handig als je je klassen nog eens wil terugvinden?
4) Maar met deze vorm van beveiliging ben je heel kwetsbaar... En waarom zou je niet een bepaalde klasse mogen gebruiken als je niet de core gebruikt? Verder is .htaccess (zeker deny from all) overal beschikbaar.
5) Je hebt een map 'classes', hoewel er ook klassen in andere mappen staan. Ook lijken de klassen in classes deel van de 'core', al is dat nu niet zo. En waarom is er een map genaamd classes/org/faabtech/mvc waarin oa je abstrace controller staat?
6) Maak dan iig een fileloader, zodat je niet bij elke load exceptions moet gaan schrijven voor als je iets niet kan vinden.
Pim - op 16/08/2011 16:25:46:
1) Maar dan hoeft toch niet elk object deze klasse uit te breiden?
2) Hoezo zou je dan zo'n dunne en nutteloze laag eroverheen gebruiken? En waarom zo'n onduidelijke naam?
3) Het is toch gewoon heel handig en waarom zou je er slordig van worden? Ook maakt het systematische naamgeving van je klassen noodzakelijk en dat is toch alleen maar handig als je je klassen nog eens wil terugvinden?
4) Maar met deze vorm van beveiliging ben je heel kwetsbaar... En waarom zou je niet een bepaalde klasse mogen gebruiken als je niet de core gebruikt? Verder is .htaccess (zeker deny from all) overal beschikbaar.
5) Je hebt een map 'classes', hoewel er ook klassen in andere mappen staan. Ook lijken de klassen in classes deel van de 'core', al is dat nu niet zo. En waarom is er een map genaamd classes/org/faabtech/mvc waarin oa je abstrace controller staat?
6) Maak dan iig een fileloader, zodat je niet bij elke load exceptions moet gaan schrijven voor als je iets niet kan vinden.
2) Hoezo zou je dan zo'n dunne en nutteloze laag eroverheen gebruiken? En waarom zo'n onduidelijke naam?
3) Het is toch gewoon heel handig en waarom zou je er slordig van worden? Ook maakt het systematische naamgeving van je klassen noodzakelijk en dat is toch alleen maar handig als je je klassen nog eens wil terugvinden?
4) Maar met deze vorm van beveiliging ben je heel kwetsbaar... En waarom zou je niet een bepaalde klasse mogen gebruiken als je niet de core gebruikt? Verder is .htaccess (zeker deny from all) overal beschikbaar.
5) Je hebt een map 'classes', hoewel er ook klassen in andere mappen staan. Ook lijken de klassen in classes deel van de 'core', al is dat nu niet zo. En waarom is er een map genaamd classes/org/faabtech/mvc waarin oa je abstrace controller staat?
6) Maak dan iig een fileloader, zodat je niet bij elke load exceptions moet gaan schrijven voor als je iets niet kan vinden.
1). Nooit Java gebruikt? Daar zit extend elke klasse Object.
2). Die underscore heb ik gebruikt omdat PHP Class niet toestaat.
3). Het gaat ook weer meer tijd kosten, omdat m'n Framework ook moet zoeken waar dat bestandje is te vinden.
4.1). Ik snap niet wat er mis is met
4.2). Ik verwacht dat je die klasse niet gebruikt als je met m'n core werkt. Anders mag je hem gebruiken.
4.3). Alsnog, ik wil geen .htaccess gebruiken.
5.1). Deze folder bevat bestanden voor de m'n PHP class library.
5.2). Ja, oke... de Object klasse is een kern klasse omdat elke klasse het zou moeten extenden, maar het maakt geen deel uit van de 'core' omdat de Object klasse, de Core niet beinvloed.
5.3). Een MVC pattern heeft niks met PHP te maken.
6). Alleen de core moet dit doen, omdat deze alleen gebruik moet maken van ken klasse en van de standaard PHP functie bibliotheek. De klasse bibliotheek zal in de toekomst hier een mogelijkheid voor bieden.
- Clonen van php.lang.Object(en) werkt nu.
- String klasse gooit alle string functies in een klasse:
Bedenk wel dat je dan ALLE string functies en heel veel andere functies moet gaan mappen. Dat wordt een nachtmerrie...
Pim - op 22/08/2011 14:47:50:
Bedenk wel dat je dan ALLE string functies en heel veel andere functies moet gaan mappen. Dat wordt een nachtmerrie...
Ik ga niet alle string functies toevoegen.
En afgezien van typehinting, wat voor voordeel heeft het überhaupt?
Pim - op 22/08/2011 16:25:36:
En hoe ga je ze dan gebruiken? Of laat je gewoon een groot deel van de PHP lib liggen?
En afgezien van typehinting, wat voor voordeel heeft het überhaupt?
En afgezien van typehinting, wat voor voordeel heeft het überhaupt?
Sommige mensen (Waaronder ik) vinden het eerste fijner.
Die eerste is echter onmogelijk, omdat trim() al een php-functie is.
Alles een object maken werkt wel in principe fijn, maar omdat PHP geen operator overloading heeft wordt het al snel een ramp. Tel daarbij op dat je new X en $x->method niet kan combineren, en PHP ook geen autoboxing of autocasting heeft:
Code (php)
1
2
3
2
3
<?php
echo '<input type="text" value="' . htmlspecialchars($value, ENT_QUOTES) . '">';
?>
echo '<input type="text" value="' . htmlspecialchars($value, ENT_QUOTES) . '">';
?>
versus:
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
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
<?php
class String
{
private $data;
public function __construct($c_str)
{
$this->data = $c_str;
}
public function concat(String $other)
{
return new String($this->data . $other->data);
}
public function encodeSpecialChars($mode = ENT_COMPAT)
{
return new String(htmlspecialchars($this->data, $mode));
}
public function c_str()
{
return $this->data;
}
}
// trucje om (new String('xxx'))->concat mogelijk te maken
function r($x)
{
return $x;
}
$value = new String('Tony "Sterretje" Star');
echo r(new String('<input type="text" value="'))
->concat($value->encodeSpecialChars())
->concat(new String('">'))
->c_str();
?>
class String
{
private $data;
public function __construct($c_str)
{
$this->data = $c_str;
}
public function concat(String $other)
{
return new String($this->data . $other->data);
}
public function encodeSpecialChars($mode = ENT_COMPAT)
{
return new String(htmlspecialchars($this->data, $mode));
}
public function c_str()
{
return $this->data;
}
}
// trucje om (new String('xxx'))->concat mogelijk te maken
function r($x)
{
return $x;
}
$value = new String('Tony "Sterretje" Star');
echo r(new String('<input type="text" value="'))
->concat($value->encodeSpecialChars())
->concat(new String('">'))
->c_str();
?>
PHP is geen Java, en ook geen C++, en ook geen Javascript en ook geen Ruby. Al die talen hebben hun eigen kracht, en de kracht van PHP is dat je een heleboel standaard functies gratis krijgt die allemaal compatible met elkaar zijn. Als je nu Java gaat nabouwen gooi je al dat voordeel weg (want die functies accepteren en returnen niet jouw String object)
Gewijzigd op 22/08/2011 17:35:12 door Jelmer -
Jelmer rrrr op 22/08/2011 17:30:45:
Nee hoor, kan prima.
Alles een object maken werkt wel in principe fijn, maar omdat PHP geen operator overloading heeft wordt het al snel een ramp. Tel daarbij op dat je new X en $x->method niet kan combineren, en PHP ook geen autoboxing of autocasting heeft:
versus:
PHP is geen Java, en ook geen C++, en ook geen Javascript en ook geen Ruby. Al die talen hebben hun eigen kracht, en de kracht van PHP is dat je een heleboel standaard functies gratis krijgt die allemaal compatible met elkaar zijn. Als je nu Java gaat nabouwen gooi je al dat voordeel weg (want die functies accepteren en returnen niet jouw String object)
Alles een object maken werkt wel in principe fijn, maar omdat PHP geen operator overloading heeft wordt het al snel een ramp. Tel daarbij op dat je new X en $x->method niet kan combineren, en PHP ook geen autoboxing of autocasting heeft:
Code (php)
1
2
3
2
3
<?php
echo '<input type="text" value="' . htmlspecialchars($value, ENT_QUOTES) . '">';
?>
echo '<input type="text" value="' . htmlspecialchars($value, ENT_QUOTES) . '">';
?>
versus:
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
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
<?php
class String
{
private $data;
public function __construct($c_str)
{
$this->data = $c_str;
}
public function concat(String $other)
{
return new String($this->data . $other->data);
}
public function encodeSpecialChars($mode = ENT_COMPAT)
{
return new String(htmlspecialchars($this->data, $mode));
}
public function c_str()
{
return $this->data;
}
}
// trucje om (new String('xxx'))->concat mogelijk te maken
function r($x)
{
return $x;
}
$value = new String('Tony "Sterretje" Star');
echo r(new String('<input type="text" value="'))
->concat($value->encodeSpecialChars())
->concat(new String('">'))
->c_str();
?>
class String
{
private $data;
public function __construct($c_str)
{
$this->data = $c_str;
}
public function concat(String $other)
{
return new String($this->data . $other->data);
}
public function encodeSpecialChars($mode = ENT_COMPAT)
{
return new String(htmlspecialchars($this->data, $mode));
}
public function c_str()
{
return $this->data;
}
}
// trucje om (new String('xxx'))->concat mogelijk te maken
function r($x)
{
return $x;
}
$value = new String('Tony "Sterretje" Star');
echo r(new String('<input type="text" value="'))
->concat($value->encodeSpecialChars())
->concat(new String('">'))
->c_str();
?>
PHP is geen Java, en ook geen C++, en ook geen Javascript en ook geen Ruby. Al die talen hebben hun eigen kracht, en de kracht van PHP is dat je een heleboel standaard functies gratis krijgt die allemaal compatible met elkaar zijn. Als je nu Java gaat nabouwen gooi je al dat voordeel weg (want die functies accepteren en returnen niet jouw String object)
PHP vraagt dan naar de __toString method. En omdat ik deze klassen maak, zijn standaard functies niet meer nodig.
Quote:
PHP vraagt dan naar de __toString method. En omdat ik deze klassen maak, zijn standaard functies niet meer nodig.
Dat is dubbel op toch? En, je bent dan nog wel even bezig als je alles opnieuw wilt maken..
@Jelmerr
Met wat extra classes is autoboxing wel mogelijk: klik
Zou ik namespaces gebruiken?
Op dit moment ben ik nog bezig met de Core en de Exception's. Ik wil zo snel mogelijk beginnen met het MVC en de Routes.
Super, ga zo door! ;-)
Bedankt, en ik ben ook wel nieuwschierig naar jouw framework. Link?
Sorry, ik heb hem niet online staan ;-)
PHP Scripter op 31/08/2011 22:14:29:
Sorry, ik heb hem niet online staan ;-)
Ok.