[OO] Resolver classen
Op aanraden van Wouter heb ik een aparte klasse gemaakt voor het parsen van Controller strings als "Application::HelloController::index".
Ik heb nu volgende code:
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
namespace Symply\Mvc\Controller;
class ControllerResolver
{
public function resolve($name)
{
$parts = explode('::', $name);
if(count($parts) != 3)
{
throw new Exception\InvalidControllerException(sprintf(
'Controller string %s is invalid',
$name
));
}
$class = '\\' . ucfirst($parts[0]) . '\\Controller\\' . ucfirst($parts[1]);
return array(
'controller' => new $class,
'action' => lcfirst($parts[2]) . 'Action',
);
}
}
?>
namespace Symply\Mvc\Controller;
class ControllerResolver
{
public function resolve($name)
{
$parts = explode('::', $name);
if(count($parts) != 3)
{
throw new Exception\InvalidControllerException(sprintf(
'Controller string %s is invalid',
$name
));
}
$class = '\\' . ucfirst($parts[0]) . '\\Controller\\' . ucfirst($parts[1]);
return array(
'controller' => new $class,
'action' => lcfirst($parts[2]) . 'Action',
);
}
}
?>
Maar ik had graag gehad dat ControllerResolver de Resolvable class implements waardoor de resolve() method verplicht gesteld word.
Zo zou het dan eruit zien:
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
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
<?php
interface Resolvable
{
public function resolve($name);
}
class ControllerResolver implements Resolvable
{
public function resolve($name)
{
$parts = explode('::', $name);
if(count($parts) != 3)
{
throw new Exception\InvalidControllerException(sprintf(
'Controller string %s is invalid',
$name
));
}
$class = '\\' . ucfirst($parts[0]) . '\\Controller\\' . ucfirst($parts[1]);
return array(
'controller' => new $class,
'action' => lcfirst($parts[2]) . 'Action',
);
}
}
?>
interface Resolvable
{
public function resolve($name);
}
class ControllerResolver implements Resolvable
{
public function resolve($name)
{
$parts = explode('::', $name);
if(count($parts) != 3)
{
throw new Exception\InvalidControllerException(sprintf(
'Controller string %s is invalid',
$name
));
}
$class = '\\' . ucfirst($parts[0]) . '\\Controller\\' . ucfirst($parts[1]);
return array(
'controller' => new $class,
'action' => lcfirst($parts[2]) . 'Action',
);
}
}
?>
Nu mijn vraag: waar gaat zo'n resolvable class? Ik wil er geen nieuw component voor maken. En die class in de \Symply\Mvc\Controller namespace zetten heb ik liever ook niet want ik wil zo'n Resolvable ook voor andere dingen gebruiken ipv enkel controllers parsen.
Iemand een idee?
Raoul
Gewijzigd op 09/02/2013 11:19:27 door - Raoul -
En je moet je ook afvragen of je wel alle resolvers op 1 hoop moet gooien. Symfony2 heeft bijv. een aparte ControllerResolverInterface en een ResourceResolverInterface ect.
Nog wat andere tips:
- maak je exception message duidelijker. Je weet nu totaal niet wat er precies verkeerd is, maak hem bijv:
Code (php)
- Nog mooier is het als je je exception klasse wat aanpast:
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
class InvalidControllerStringException
{
public function __construct($string, $message = null, $code = 0, \Exception $previous = null)
{
parent::__construct(
sprintf(
'Controller string "%s" is invalid%s',
$string,
(null === $message ? ', '.$message : null)
),
$code,
$previous
);
}
}
// in gebruik
if(count($parts) != 3) {
throw new Exception\InvalidControllerException(
$name,
sprintf(
'a controller string should at least have 3 parts separted with "::", %d parts given',
count($parts)
)
);
}
?>
class InvalidControllerStringException
{
public function __construct($string, $message = null, $code = 0, \Exception $previous = null)
{
parent::__construct(
sprintf(
'Controller string "%s" is invalid%s',
$string,
(null === $message ? ', '.$message : null)
),
$code,
$previous
);
}
}
// in gebruik
if(count($parts) != 3) {
throw new Exception\InvalidControllerException(
$name,
sprintf(
'a controller string should at least have 3 parts separted with "::", %d parts given',
count($parts)
)
);
}
?>
- een resolver heeft als taak het omzetten van een 'humanized' string in een string die de computer begrijpt, hij moet niet opeens al klassen gaan aanmaken
- je bent zo'n PSR fan en toch gebruik je de standaards niet in je code...?
Quote:
- een resolver heeft als taak het omzetten van een 'humanized' string in een string die de computer begrijpt, hij moet niet opeens al klassen gaan aanmaken
Inderdaad, ik pas het zo aan.
Quote:
- je bent zo'n PSR fan en toch gebruik je de standaards niet in je code...?
Waar kom ik ze dan niet na?
Quote:
Resolvable class? En allereerst, een class? Waarom niet gewoon een ResolveInterface interface?
En je moet je ook afvragen of je wel alle resolvers op 1 hoop moet gooien. Symfony2 heeft bijv. een aparte ControllerResolverInterface en een ResourceResolverInterface ect.
En je moet je ook afvragen of je wel alle resolvers op 1 hoop moet gooien. Symfony2 heeft bijv. een aparte ControllerResolverInterface en een ResourceResolverInterface ect.
Je hebt gelijk. Ik las dit in de documentatie van de Symfony API
Quote:
public mixed|Boolean getController(Request $request)
Returns the Controller instance associated with a Request.
Returns the Controller instance associated with a Request.
Ze returnen een Controller instance in een Resolver, dat mocht toch niet?
Raoul
Quote:
Waar kom ik ze dan niet na?
moet zijn:
Haal je project anders eens door de PHP CS Fixer met de optie '--level=all' en kijk eens wat er allemaal veranderd wordt.
Quote:
Ze returnen een Controller instance in een Resolver, dat mocht toch niet?
Je moet zelf weten wat mag en niet mag. Ik zou het zelf nooit doen.
Edit:
Of tja, nu ik er over na denk. Een ControllerStringParser zou alleen een string mogen parsen en niks meer, een ControllerResolver is natuurlijk weer een stapje verder en zou dus wel een controller mogen aanmaken.
Gewijzigd op 09/02/2013 12:38:10 door Wouter J
Zou een ControllerResolver dan ook gebruik mogen maken van een ControllerStringParser of is dat dan weer overkill?
Ik lees het nu net ook, dat if/foreach/for/while/switch statements zo moeten gedaan worden. Denk dat ik het verwarde aangezien bijna alle {} ge-entered worden (classes, functies).
Gewijzigd op 09/02/2013 12:51:15 door - Raoul -
Quote:
Zou een ControllerResolver dan ook gebruik mogen maken van een ControllerStringParser of is dat dan weer overkill?
Ik zou me dan houden aan het KISS principe en gewoon alleen een resolver gebruiken.