Currently we are experimenting with lazy loading pages and talk pages that are loaded within a page. Both need templates to render in both PHP and JavaScript. The fact that we use sections in mobile requires looping so it's not possible to determine a template for a page with sections from the html in a stub page for example. We are also thinking about separating language from HTML. The JavaScript would need an equivalent PHP fallback.. (see https://bugzilla.wikimedia.org/show_bug.cgi?id=40678)
twig reminds me of jinja python templates. It looks far too powerful for my liking (casual glance so sorry if I've read this wrong). Personal experience tells me a powerful templating language encourages bad habits. Filters like upper belong in code not templates in my opinion. The thing Juliusz and I liked about Hogan was the fact it was very simple and close to logic less (only has ifs and loops). The dumber the better :) Also is there a JS implementation? That said I like the idea that MediaWiki could be template agnostic and work with various templating languages and we could RESOLVED LATER a standard :) On 13 May 2013 18:18, "Matthew Walker" <[email protected]> wrote: > > > > In the mobile team we are increasingly finding overlap in things we need > > to render in javascript and in PHP > > Out of curiosity -- what are you rendering in JS that you wouldn't already > have in the DOM or wouldn't be able to render server side? > > We'd love the same for PHP - there's even a bug for that. > > Not that it's ready for General release yet but Fundraising has been using > Twig for a while in parts of it's code (our thank you email generator, and > unsubscribe processor). I enjoy the ability the create code reusable and > code-review-able extensions like [1] -- which seems to be a plus for Twig > over Mustache. I also enjoy the built in file system loader and template > inheritance mechanisms that twig offers. > > Chris S. has it in his review queue to security review twig so that I can > make my Twig/MediaWiki integration more official. > > [1] https://gerrit.wikimedia.org/r/#/c/63252/ > > ~Matt Walker > Wikimedia Foundation > Fundraising Technology Team > > > On Mon, May 13, 2013 at 5:23 PM, Jon Robson <[email protected]> wrote: > > > Personally as a frontend developer I find maintaining html the > > Html::openElement way in PHP a nightmare. > > > > Following on from Antoine's post, I experimented recently with using a > > template engine Mustache that works on both javascript and PHP and > > allows separation of HTML templates from PHP code. In the mobile team > > we are increasingly finding overlap in things we need to render in > > javascript and in PHP. MobileFrontend currently uses Hogan (which is > > essentially Mustache) in our javascript code base and it helps make > > our javascript easier to maintain and read. We'd love the same for PHP > > - there's even a bug for that [1]. > > > > These templates make escaping simple - you either do {{variable}} to > > render escaped or {{{html}}} to render HTML. > > > > My personal belief is taking this approach would lead to much more > > readable code (especially when it comes to skins). The proof is in the > > pudding - [2][3] > > > > We also have an HTML validation script [4] that I wrote about earlier > > which allows us to validate pages and avoid submitting invalid code so > > I wouldn't use this as an argument against... > > > > [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=44130 > > [2] > > > https://github.com/jdlrobson/Minerva/blob/evenmorevanilla/Minerva.php#L72 > > [3] > > > https://github.com/jdlrobson/Minerva/blob/evenmorevanilla/minerva/templates/main.html > > [4] http://www.gossamer-threads.com/lists/wiki/wikitech/355021 > > > > On Mon, May 13, 2013 at 3:27 PM, Yuri Astrakhan > > <[email protected]> wrote: > > > On one hand, I prefer to have a properly formatted code, but on the > > other, > > > most systems i have worked with have a very high cost of string > > > concatenation, and I have a strong suspicion PHP is guilty of that too. > > > Constructing HTML one element/value at a time might prove to be on of > the > > > bigger perf bottlenecks. > > > > > > From my personal experience, once I worked on a networking lib for > > > proprietary protocol, and noticed that there was a lot of logging calls > > in > > > the form of Log("value1=" + value1 + " value2=" + value2 ...). After I > > > switched it to the form "Log("value1={0}, value2={1}", value1, value2), > > the > > > code became an order of magnitude faster because the logging > > > framework deferred concatenation until the last moment after it knew > that > > > logging is needed, and the actual concatenation was done for the whole > > > complex string with values, not one substring at a time. > > > > > > > > > On Mon, May 13, 2013 at 6:10 PM, Antoine Musso <[email protected]> > > wrote: > > > > > >> Le 13/05/13 19:26, Max Semenik a écrit : > > >> > Hi, I've seen recently a lot of code like this: > > >> > > > >> > $html = Html::openElement( 'div', array( 'class' => 'foo' ) > > >> > . Html::rawElement( 'p', array(), > > >> > Html::element( 'span', array( 'id' => > > $somePotentiallyUnsafeId ), > > >> > $somePotentiallyUnsafeText > > >> > ) > > >> > ) > > >> > . Html::closeElement( 'div' ); > > >> > > > >> > IMO, cruft like this makes things harder to read and adds additional > > >> > performance overhead. > > >> > > >> Html is just like our Xml class, that let us raise the probability > that > > >> the result code will be valid. That is also a good way to make sure > the > > >> content is properly escaped, though in the example above that could > lead > > >> to some mistake due to all the nested calls. > > >> > > >> For the performance overhead, it surely exist but it is most probably > > >> negligible unless the methods are in a heavily used code path. > > >> > > >> > > >> Ideally we would use templates to generate all of that. That will let > us > > >> extract the views logic out of the PHP code. > > >> > > >> > > >> -- > > >> Antoine "hashar" Musso > > >> > > >> > > >> _______________________________________________ > > >> Wikitech-l mailing list > > >> [email protected] > > >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > >> > > > _______________________________________________ > > > Wikitech-l mailing list > > > [email protected] > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > > > -- > > Jon Robson > > http://jonrobson.me.uk > > @rakugojon > > > > _______________________________________________ > > Wikitech-l mailing list > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
