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
