Twig View Support, Deprecate Translated View Support

[mbabker]

Fixes #1

This adds a Pagerfanta\View\ViewInterface implementation which allows rendering pagers using Twig instead of using the PHP views and templates the default implementation provides. Twig templates are provided for each of the views that are presently supported with the markup structure appropriately documented (each block should correspond to each of the method calls from Pagerfanta\View\DefaultView::generatePages()). A default template can be set with the babdev_pagerfanta.default_twig_template configuration node (similar to the default view).

The BabDev\PagerfantaBundle\View\TranslatedView classes are deprecated with this change. The way this was implemented actually introduces a fair bit of complexity as it tries to retain the default message format from the decorated views, but looking at it again to me it seems it could be done in a simpler manner (as these shouldn't be more much more complex than Pagerfanta\View\OptionableView) even if it means losing the default arrows some of the views arbitrarily add to the messages, so for now these classes are deprecated.

The test environment for the Twig view consists of two parts:

• A basic unit test for the BabDev\PagerfantaBundle\View\TwigView class
• A more advanced integration test which builds a Twig environment with the PagerfantaExtension and Symfony's TranslationExtension and tests the actual rendering of the templates

Realistically, this is good to ship as is, but a couple of lingering points:

• The prev_message and next_message options that exist in all of the Pagerfanta templates/views aren't present in the Twig view and the trans filter is used for those, should that option be supported?

• Trying to explain some of the Pagerfanta\View\DefaultView methods in Twig isn't the easiest thing. The intent of secondIfStartIs3() or dotsIfStartIsOver3() are decently well copied over, but dotsIfEndIsUnder3ToLast() or secondToLastIfEndIs3ToLast() are kind of strange.

[rimas-kudelis]

This is of course outside of this PR scope, but, erm, why?..

[mbabker]

From what I can tell it traces back to sampart#45 and is essentially a "this is how the PropertyPath class works" thing.

[rimas-kudelis]

The string could just be wrapped in brackets before being used. That would both make PropertyPath happy and leave this bit of config simpler. This could even be optional, to make the migration from white-october bundle easier. Shall I file a new issue?

[mbabker]

Yeah, that'd be a good thing to look at. It's been a behavior deeply rooted in the bundle for ages and would help the DX a bit if that hard requirement could go away.

[rimas-kudelis]

That's #5 now.

[rimas-kudelis]

Is this not possible without using OptionableView, just via config?

[mbabker]

Not right now, the bundle doesn't expose a notion of "these are global options applied to all {{ pagerfanta() }} uses. Even if that existed, I'd still leave this doc section in place since it's a good guide for setting up more specific reusable configurations for different occasions (say you've got an application that has different frontend and backend themes, you might want to default the backend pager to a different set of options from the frontend pager).

[rimas-kudelis]

What I meant is, what is the difference between using OptionableView and this:

    pagerfanta.view.twig:
        class: App\Pagerfanta\View\TwigView
        arguments:
            - '@twig'
            - '@@BabDevPagerfantaBundle/default.html.twig'
        public: false
        tags: [{ name: pagerfanta.view, alias: twig }]

    pagerfanta.view.shop:
        class: App\Pagerfanta\View\TwigView
        arguments:
            - '@twig'
            - '@@BabDevPagerfantaBundle/shop.html.twig'
        public: false
        tags: [{ name: pagerfanta.view, alias: shop }]

Oh wait, this is about options other than the template, right?

[mbabker]

Right. A default template can be set through the constructors on the Twig view (same way the default_view parameter is pushed into the Twig runtime class constructor to allow not explicitly specifying a view every time you call {{ pagerfanta(pager) }}), but not a default $options array. And TBH, I'd just use the OptionableView decorator for that instead of trying to duplicate its logic.

[rimas-kudelis]

You mentioned the similarity of this case to forms in the original issue. I think it would make sense to call this option default_theme in line with forms, no?

[mbabker]

I'd stick to default_twig_<whatever> to make it clear that it only applies to the TwigView. default_<whatever> might imply it's used with all Pagerfanta views.

[rimas-kudelis]

I get that it doesn't make an awful lot of sense, but it might still be convenient to just pass this option if one wants to use a distinct message in just that one place only. Why not allow this option for twig view as well (probably without running the message received this way through the translator) and fall back to the translatable default if the message has not been passed? (Note: an empty passed message should still be honored in such case)

[mbabker]

Still on my "think about it" list. It was 3 AM by the time I had gotten to a "this is good enough" state and didn't even think to go through all the options that the default views expose.

[rimas-kudelis]

prev_message and next_message are the only really missing bits from my PoV. But they can be added later if you don't feel like doing it here.