> > 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
