Whats next - Githubissues

laytoneverson commented 9 years ago

I would like to help you move this forward. Whats next? How do we collaborate?

robfrawley commented 9 years ago

Ditto.

headzoo commented 9 years ago

Right now I'm getting comfortable with the Polymer 1.0 API changes. I've just started using 1.0 in some personal projects. Some minor changes need to be made to the bundle to get it working with 1.0, but nothing too complicated. I think I'll feel a little more comfortable when Polymer 1.1 comes out, then I'll know for sure the new API isn't going to change.

My concerns right now are a few weaknesses in the bundle API. I made a couple design choices that aren't going to work and need to changed.

The way the {% polymer import %} tag handles paths doesn't work. Instead of using the short path syntax like {% polymer import "@AcmeBundle:hello-world.html.twig" %}, the bundle will have to use full paths like {% polymer import "@AcmeBundle:Resources/elements/hello-world.hello-world.html.twig" %}. I don't remember exactly why the short path syntax doesn't work (I'll have to get reacquainted with the code), but I remember a couple months ago thinking, "Crap, this isn't going to work."

I'm also not happy that the bundle needs to override the default "twig" and "twig.loader" services in order to slip in some magical {% verbatim %} tags, which prevents Twig from parsing the contents of the {% polymer element %} tag. The approach I'm taking is kind of sloppy and will interfere with other bundles doing the same thing. I spent a weekend trying to find ways to make Twig treat the {% polymer element %} like a {% verbatim %} tag, and that's the only approach I found that works.

So right now my goals in priority order are:

Change the {% polymer import %} tag so full paths are required.
Find a better way to make Twig ignore the contents of the {% polymer element %} tag, or at least decide once and for all that the current approach is the only way it will work.
Update the bundle API to work with Polymer 1.0.
Rewrite all of the documentation.

I've created a new branch called polymer_1, which is where these changes will be made. Any fixes made to the current bundle implementation will go into dev and be merged into master.

So, if there's any changes you want to make I'm happy to accept pull requests. Changes related to Polymer 0.8 should go into the dev branch, and changes related to Polymer 1.0 should go into the polymer_1 branch.

headzoo commented 9 years ago

There's a couple other minor things I have on my todo list.

Element aliases?

config.yml

polymer:
    aliases:
        hello_world: "@AcmeBundle:Resources/elements/hello-world.hello-world.html.twig"

Usage: {% polymer import "hello_world" %}

Vulcanize elements?

Some kind of vulcanize support to inline elements instead of linking to them. Would be especially useful during development.

robfrawley commented 9 years ago

Everything here is amazing. I can contribute most to the twig-related aspects, most likely, so I'm gonna fork your release_1 branch and look into some of the Twig-related items you mentioned, including:

The polymer tag (and the related paths/verbatim issues you mentioned)
Vulcanize (OMG YES!)

Regarding vulcanize, I would really like to be able to figure a method to do the following:

dev environment: import your elements using their singular definitions as defined in the respective twig template files.
production environment: I'm interested in taking this a bit further than squishing all dependencies that exist in your app globally into a single (large) import. Instead, I'd like to figure a method for determining the dependency chain of all the "leaf" template files, and, moving through that dependency chain, vulcanize those dependencies. For example, given the following twig files:

File: app/Resources/views/base.html.twig

<!DOCTYPE html>
<html lang="en">
{% polymer import "someGlobalElement" %}
{% block body %}{% endblock %}
</html>

File: src/AppBundle/Resources/views/base.twig.html

{% extends '::base.html.twig' %}
{% polymer import "someElement1" %}
{% polymer import "someElement2" %}
{% polymer import "someElement3" %}
{% block body %}{% endblock %}

File: src/AppBundle/Resources/views/users/lists.twig.html

{% extends 'AppBundle::base.html.twig' %}
{% polymer import "someElement4" %}
{% polymer import "someElement5" %}
{% block body %}{% endblock %}

Such would result in the following:

File: app/Resources/views/base.html.twig

<!DOCTYPE html>
<html lang="en">
{% polymer import "elements_base" %}
{% block body %}{% endblock %}
</html>

File: src/AppBundle/Resources/views/base.twig.html

{% extends '::base.html.twig' %}
{% polymer import "elements_appbundle_base" %}
{% block body %}{% endblock %}

File: src/AppBundle/Resources/views/users/lists.twig.html

{% extends 'AppBundle::base.html.twig' %}
{% polymer import "elements_appbundle_users_list" %}
{% block body %}{% endblock %}

Where each extends actually includes all the dependencies required in the chain (so elements_appbundle_users_list would have everything from the elements it extends, elements_appbundle_base would have all the elements from the templates it extends, etc, but during runtime it would only load the single import from the leaf template file --- if you render src/AppBundle/Resources/views/base.twig.html, it would only have {% polymer import "elements_appbundle_base" %} whereas if you rendered src/AppBundle/Resources/views/users/lists.twig.html it would only have {% polymer import "elements_appbundle_users_list" %}, etc).

This could be configurable, as well, as this method has both benefits and negatives, depending on your use-case.

I'm also very interested in extending Twig's native PHP extension (https://github.com/twigphp/Twig/tree/master/ext/twig) to directly support some of these features, as speed is a huge priority for my application (this would of course be an optional install, just as it is for the normal twig package, that would speed things if the module was compiled and loaded in your PHP SAPI, but would also be properly implemented in explicit PHP for those who either do not want to or cannot utalize the PHP module).

FYI: My timeline won't let me get to even looking at this prior to next weekend, most likely, as I'm in the middle of a release for the main web-service for my company. That said, my development roadmap has incorporating your bundle into that for the January release, meaning I'll be able to dedicate some substantial (and, wonderfully, paid) time to this in a few weeks. I've used your bundle in a few personal projects as a test-run, and I've been very happy with the results overall!

Thoughts?

robfrawley commented 9 years ago

Any thoughts on what you want to aim for with regard to minimum Symfony requirements. Keeping in mind that Symfony 2.6 will be unsupported for bug fixes at the end of this month and security fixes will stop being pushed January, I'd really like to aim for a >=2.7 minimum requirement for the release_1 branch (which is the current "long term support" release). This also means that this project would gain 3.0 support without any code changes (as Symfony 2.7 introduced deprecation notices for all BC breaks that will be introduced in 3.0, due for release in November) without any additional work.

@headzoo What are your thoughts on this, specifically?

robfrawley commented 9 years ago

Forgot to link to this in my previous post:

My understanding from the IRC channel and speaking to some of the maintainers is 2.8 will simply be 2.7 (with bug fixes, of course) with more harsh BC notifications for 3.0, and that 2.8 and 3.0 will be released simultaneously in November and originate from the exact same codebase, the only changes in 3.0 being the removal of the BC changes, whereas 2.8 will continue to implement the collection of backwards-compatibility classes that proxy to the new 3.0 APIs.

So, basically, if we have our code running on 2.7 with no deprecation warning, our code would work moving forward into the next major release --- we simply wouldn't be able to utilize and new features added in 3.1, etc.

headzoo commented 9 years ago

I'm also very interested in extending Twig's native PHP extension

I was thinking the same thing. Or at least I was thinking about creating a regular Twig extension and then wrapping that extension in a Symfony bundle. Two different projects, two different repos.

If you like we can create a new github account or organization for these related projects. Polyphonic is already taken, but using it as an example we could have https://github.com/polyphonic/twig-extension-php, https://github.com/polyphonic/twig-extension-native, https://github.com/polyphonic/symfony-bundle, https://github.com/polyphonic/vulconize-filter, etc.

I'd like to figure a method for determining the dependency chain of all the "leaf" template files

That's fine if you think you can pull it off. My only experience writing Twig extensions is through Symfony. So I'm not sure what's possible and what isn't. I'm not sure if we can hook into the Twig lexing phase to create an import tree.

We can take the Assetic approach and turn these types of actions into configurable filters.

We of course also want to cache the results so we're not creating the import tree on each request. We also have to be mindful that the import tag can handle multiple files, eg {% polymer import "someElement1" "someElement2" "someElement3" %}.

I'd really like to aim for a >=2.7 minimum requirement for the release_1 branch

That works for me. I'm using 2.7 in my projects now, and if we're already aiming to support Polymer 1.0, which is kind of "bleeding edge", then I don't see any reason to support older version of Symfony. In other words, anyone with the mindset to use Polymer 1.0 probably also has the mindset to use the most recent version of Symfony.

Anyway, let me know if you want to create a github organization for these related projects, and what you had in mind for a name.

headzoo commented 9 years ago

On a related note, the Symfony bundle could be configurable to use either the plain PHP Twig extension, or the native extension. Similar to the way the Redis bundle lets you choose between Predis (written in PHP) or the native Redis extension.

skyred commented 8 years ago

Looks like http://www.polyphonic-symfony.org/ is down?

headzoo / polymer-bundle

Whats next #2

Element aliases?

Vulcanize elements?