Symfony readiness - Githubissues

TorbenKoehn commented 8 years ago

Tale Jade works with Symfony, but not too well right now.

I've created an implementation (will put it online soon), a JadeBundle, for Symfony2/3.

Some of the problems have already been taken care of in 1.5, but there might be a possibility for a 1.4.3 bringing in Symfony compatibility until 1.5 is finally there

The following problems arised and need to be taken care of;

No : in paths allowed. Right now // acts as a workaround, which is ugly
A real Filename Resolver is needed that can be swapped out with a Symfony-specific implementation using Symfony's TemplateNameParser and TemplateLoader. Right now resolving consists of Compiler->resolvePath only.
The rendererer adapters shouldn't ever modify the original path that is passed to the resolver. Right now the File adapter strips the .jade/.jd extension from the path.
Renderer adapters should filter cache keys better (Any kind of invalid path character should be replaced with e.g. -. Another possibilty would be something like basename($path).'-'.md5($path) since the only reason to even keep the file names is to look up some PHTML code that bugs, the base name would be sufficient.
No real extensions possible (e.g. Twig's asset()-function). Right now the solution is passing it as a variable (link(rel=$asset('style.css'))). This isn't even too shabby and it's valid PHP. I honestly don't want to bring in any new fancy syntax and we can't put it into a new element or merge it with mixins, because we also want to use them in attributes and maybe even PHP code.
Configuration overhaul might be needed before 1.5, which would make it 1.5. I don't know yet. I'm converting the keys right now which is just a useless performance loss. Would be stubborn from my side not converting the camelCase keys to under_scores.

Well...the other parts are really cool. It can replace Twig completely.

import JadeBootstrapBundle::mixins.html.jade will be pretty awesome as well.

Stay tuned.

hason commented 8 years ago

The real Twig extensions should be possible with compiler to Twig #69. I will make PR for 1.5.

TorbenKoehn commented 8 years ago

Don't you think that would just be too much?

The main target is replacing Twig with Jade, not making Jade compile to Twig. Most features overlap, especially the block/extend/include part and the control statements.

I don't see any bigger problem with just using $asset('logo.png'), do you?

hason commented 8 years ago

Jade is only syntactic sugar for Twig, for me. I want to use Jade in Symfony ecosystem and all bundles provides extensions for Twig. Twig offers more robust language constructs than Jade (dot . to access attributes of a variable, embed, filters for variables etc.). I think that the journey of MtHaml is the best as for this project as for users.

TorbenKoehn commented 8 years ago

Let's discuss this please, I think we will get quite a few interesting new features for Tale Jade out of it. Thanks for your input in any case, I really appreciate it.

What are you missing in Tale Jade?

What features does Twig have that Jade isn't able to handle with what it is right now (and it will be quite extensible with 1.5, deep to the core). I thought a lot about implementating a subset of JavaScript into the Jade compiler, so it would essentially be able to use .-notation as well and to give people the ability to just copy their JavaScript-Jade-Templates, but I wrote Tale Jade for PHP developers, not for JavaScript developers and not for people that need .-notation to be happy. I didn't want ambiguous constructs like If you do a.b, b can be b, b(), getB() or isB()! In reality, you never really know what b really is and if you have to look it up in the code, you're searching.

If you're missing auto-access of variables of any kind, you extend the renderer Look at my example, you could use it as it is, but I'll give everyone the freedom of having it or not. https://gist.github.com/TorbenKoehn/107187eb5c33c550b2e9a87bd509f5b4

Missing and and or? Never forget that PHP has them natively. Things like each $post in $posts: if $post->published and $post->isRecent(): h1= $post->title are perfectly possible. With : you can extend most nodes in Tale Jade, other than official Jade where it's only possible on elements. Just look at it

Twig can't change your document type from XHTML to HTML by replacing doctype default with doctype html and it changes the complete HTML rendering style to match HTML5 standards. Jade can enforce that your designers avoid writing <br />.

Tale Jade is also able to handle XML really well, you can write your RSS feeds or XML apis with it. It handles stuff like self-closing <br /> automatically, but doesn't restrict you in the way you actually want to output it.

But what it doesn't do is the way you write PHP. It's a wrapper around PHP that just strips the HTML part and replaces it with Jade as well as making the block-PHP-parts (loops, control statements) Jade-compatible (you don't need endifs, endforeachs and endwhiles, Twig needs those. Even endblocks.)

What I'd rather see is a bridge für Twig-extensions, I don't think it would be too hard to just implement Twig's extension system and make them compatible to Tale Jade. It's essentially getting the extension from the DI container and making a closure out of it. Or a function. Or a static helper. Or an object with methods. You might even just pass the extension instance to Jade.

Jade is also enforcing. It enforces clean code (indentation is required) and removes characters that make stuff look overly complex.

But honestly, Jade's biggest capability is transforming CSS selectors to HTML elements.

.container#mainContainer

    header.header-default: h1.article-title= Title
    article.article.article-main#mainArticle: p=$content
    footer.footer-default: nav.footer-nav.nav-stacked: ul
        li: a(href='#') First
        li: a(href='#') Second

This is valid Jade syntax. The bottom one is the one you'd have to write in Twig.

I'm working really hard on bringing Jade into the Symfony ecosystem, but I don't want it to end up as just another Twig extension.

After some thinking I came to the conclusion that it might have some advantages to merge those two. It just feels so wrong stacking 2 template languages. In fact, it shouldn't be too hard to compile Jade to Twig and Jade still eases things up in this case, since you're still writing less code.

hason commented 8 years ago

I want to use strength of Jade and Twig together. Your use case is another. That's all. This library is great, that can be very simple refactor to support multiple compilers (php, twig, ...). Please respect user preferences, make great library and not war. The compiler to Twig can be in another repository.

TorbenKoehn commented 8 years ago

Sorry, I just got a little offended when you say that Jade is just syntactic sugar. Jade has many things to offer that Twig doesn't.

embed is actually something I'd like to discuss, filters aren't needed at all imo, but maybe you have a neat way it could be implemented.

In any other case, I'll happily support you writing a Twig-compiler for Jade. If you want it and other people might want it, it can only help spreading Jade. It will be a separate repository for sure.

If you like, we can develop it together, I'll give you a repo for it. You just need the output of Tale\Jade\Parser->parse, the parser in the compiler-enhancements branch is finished, only the compiler is missing (and that's the one you want to replace).

TorbenKoehn commented 8 years ago

This is my JadeBundle right now. If you're interested, I could need help :)

Talesoft / tale-jade

Symfony readiness #78