-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unmaskUrl method: private to protected #99
Conversation
Why a canonical If so, I suppose you should provide an extension or something like this: this bundle isn't base on symfony so, the only advantage of this visibility change, seems to suite symfony user needs and I vote to keep this outside this extension and put it elsewhere. Moreover you can easily override open function to obtain what you need. Don't know if @jakzal agree with me or not |
Okay, it can lend itself to confusion. But, I think it would benefit those who use route components within our projects, such as Symfony or Laravel or any other With this change, the package will not be bound to any framework. If someone does not use a router packet or needs to generate the routes, you can still use it as-is. This opens the possibility of creating a SymfonyRouteExtension, based on page objects, for Behat . |
An alternative not to make this change, when using a componenten router is: abstract class SymfonyPage extends Page
{
private $router;
public function __construct(Session $session, Factory $factory, array $parameters = array(), RouterInterface $router)
{
parent::__construct($session, $factory, $parameters);
$this->router = $router;
}
protected function getPath()
{
if (null === $this->path) {
throw new PathNotProvidedException('You must add a path property to your page object');
}
return $this->router->getRouteCollection()->get($this->path)->getPath();
}
} |
In my humblest opinion and for this reason this should be an extension.
I'm pretty sure that overriding |
I would not change the If you do not get the change to The SymfonyPage class will not be embedded within PageObjects: it is a solution to which we use routing components. To be able to extend our pages: <?php
namespace Behat\Page\Security;
use Behat\Page\SymfonyPage;
class LoginPage extends SymfonyPage implements LoginPageInterface
{
protected $path = 'fos_user_security_login';
} |
If you need to open a page with a certain parameter, even with your method or the way it's already defined, |
Initially I thought this is a good idea, but after reading @DonCallisto's comments and looking at the code again I think we already have proper extension points in place - Currently overriding Could we improve this though?
Instead, you could imagine having a page rely on some kind of a abstract class Page extends DocumentElement implements PageObject
{
public function __construct(Session $session, Factory $factory, array $parameters = array(), UrlGenerator $urlGenerator)
{
parent::__construct($session);
$this->factory = $factory;
$this->parameters = $parameters;
$this->urlGenerator = $urlGenerator;
}
// ...
protected function getUrl(array $urlParameters = array())
{
return $this->urlGenerator->generateUrl($this->getPath(), $urlParameters);
}
} interface UrlGenerator
{
// not sure how to call the first argument - $locator, $name, $path?
public function generateUrl($locator, array $urlParameters = array()): string;
} class DefaultUrlGenerator implements UrlGenerator
{
public function generateUrl($locator, array $urlParameters = array()): string
{
return $this->makeSurePathIsAbsolute($this->unmaskUrl($name, $urlParameters));
}
private function makeSurePathIsAbsolute($path)
{
// this is actually not here, perhaps it should be passed via the constructor
$baseUrl = rtrim($this->getParameter('base_url'), '/').'/';
return 0 !== strpos($path, 'http') ? $baseUrl.ltrim($path, '/') : $path;
}
private function unmaskUrl($url, array $urlParameters)
{
foreach ($urlParameters as $parameter => $value) {
$url = str_replace(sprintf('{%s}', $parameter), $value, $url);
}
return $url;
}
} WDYT? |
I like it a lot ... it will be cleaner. Less confusing. More decoupled. It offers the possibility to extend the package to create new extensions from this... |
Now, the implementation of
|
|
@jakzal so, basically, you can define your own However this Only solution I found here is to create an interface and two different types of pages: one that won't be open, won't be that function, others will. Don't know if is possible and if is straightforward and no over-engeneerized. WDYT? |
Exactly.
We need to keep BC here. It's fine if we improve the situation a little bit for now and keep this in mind for future iterations. The path property doesn't have to be used at all by people who provide the UrlGenerator implementation. Short term it's fine by me.
Looking at how Mink code is being refactored we might need to stop extending their classes. It's hardly ever good idea to do it, yet I've done it here as it was very convinient for the initial audience of the extension - testers (this is also part of the reason why |
This would provide the ability to modify how routes and parameters are generated. It could easily extend and inject the services that are required to create the route depending on the project. Example: