[HttpKernel][FrameworkBundle] SSI support #10702
Conversation
| @@ -70,7 +70,7 @@ protected function getOptions() | |||
| return array(); | |||
| } | |||
|
|
|||
| protected function createEsi() | |||
| protected function createSurrogate() | |||
| { | |||
| return new Esi(); | |||
There was a problem hiding this comment.
what about here ? shouldn't be Esi renamed too ?
There was a problem hiding this comment.
Couldn't decide myself (and later I forgot). Problem is, to what should I rename it? You can overwrite it in your applications AppCache-class with
protected function createSurrogate()
{
return new Ssi();
}That's not perfect, but it works and is backward compatible. The other solution is to provide two separate FrameworkBundle:HttpCache\HttpCache-classes...
|
Please implement the featur ein a BC way, otherwise it means it cannot be merged until we move to 3.0 |
|
Fixed. Did I miss something? Also do you have an idea about how to solve this? The So in my opinion it is fine for now, but maybe somebody has an idea? |
| * @param SurrogateInterface $surrogate An Surrogate instance | ||
| * @param FragmentRendererInterface $inlineStrategy The inline strategy to use when the surrogate is not supported | ||
| */ | ||
| public function __construct(SurrogateInterface $surrogate = null, FragmentRendererInterface $inlineStrategy) |
There was a problem hiding this comment.
This looks wrong, first param shouln't be optional if second is required...
There was a problem hiding this comment.
it is already the existing signature. = null is not really about making the argument optional, but about making it nullable
There was a problem hiding this comment.
Exactly (I've tried it out...)
|
Really looking forward to see this functionality in Symfony 👍 |
|
So, updated once more. Sorry for the inconvenience with the BC I've mentioned in the source, that the components are deprecated since 2.5, but actually I don't really know. It's too late for 2.5, isn't? Are there any other concerns? |
|
@kingcrunch yes it is. 2.5 is already feature-frozen. It will come in 2.6 now |
| } | ||
|
|
||
| if (!isset($options['virtual'])) { | ||
| throw new \RuntimeException('Unable to process an SSI tag without a "src" attribute.'); |
There was a problem hiding this comment.
Actually, this is the "virtual" attribute.
| use Symfony\Component\HttpKernel\UriSigner; | ||
|
|
||
| /** | ||
| * Defines the interface |
|
@kingcrunch Looks good to me. Can you fix the minor issues I've mentioned in the comments? Thanks. |
|
👍 |
|
@kingcrunch Thanks for that. Can you fix the fabbot errors (mainly about using |
| @@ -70,6 +70,18 @@ protected function getOptions() | |||
| return array(); | |||
| } | |||
|
|
|||
| protected function createSurrogate() | |||
| { | |||
| return new Esi(); | |||
There was a problem hiding this comment.
this is not BC. If someone overwrites createEsi, it is not called anymore
|
Rebase and pushed. Actually some days ago already, but I don't know, if it's fine to "ping" after every commit :X |
|
@kingcrunch Pinging is fine, but we now need 2 +1 from the core team before being able to merge this PR. http://symfony.com/doc/current/contributing/code/core_team.html#code-development-rules |
|
cough ping @stof @romainneutron @nicolas-grekas |
|
Thank you @kingcrunch. |
This PR was merged into the 2.6-dev branch. Discussion ---------- [HttpKernel][FrameworkBundle] SSI support | Q | A | ------------- | --- | Bug fix? | No | New feature? | Yes | BC breaks? | No | Deprecations? | No | Tests pass? | Yes | Fixed tickets | #9419 (, #10684) | License | MIT It does not support comments, or alternative URIs, or "continue" in case of errors. Maybe I can workaround that, but I've decided to left it out for this PR. Especially as far as I can see a "alternative URIs"-hack would _always_ lead to two requests, even if it's not needed. Commits ------- 06cea08 SSI support
|
Thanks for this nice work @kingcrunch and all reviewers. This is a great new feature ✨ . |
It does not support comments, or alternative URIs, or "continue" in case of errors. Maybe I can workaround that, but I've decided to left it out for this PR. Especially as far as I can see a "alternative URIs"-hack would always lead to two requests, even if it's not needed.