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
)
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" <mwalker(a)wikimedia.org> 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 <jdlrobson(a)gmail.com> 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…
[4]
http://www.gossamer-threads.com/lists/wiki/wikitech/355021
On Mon, May 13, 2013 at 3:27 PM, Yuri Astrakhan
<yastrakhan(a)wikimedia.org> 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 <hashar+wmf(a)free.fr>
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
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l