Hi - I’m currently the maintainer of facebook/xhp-lib; as XHP’s been mentioned
a few times here, if someone’s interested in making a PHP7 version:
- while I won’t be able to directly work on a PHP7 port, I’ll be happy to help
in any other way (eg any questions about design/decisions)
- the mai
Hi!
> True, but the difference is that safety is the default instead of
> the exception. Every system has an assumption. It's better that
This sounds as the major assumption is there's some procedure ("the
safety") that allows to render any output safe. This could not be more
wrong. Escaping is h
On Tue, Mar 22, 2016 at 7:43 AM, Colin O'Dell wrote:
> This is a really interesting idea! However, I'm unsure whether it's wise
> to bring this feature in without having the community test and validate it
> first. Would it be possible to release this as an extension first so we
> can gauge its s
Daniel,
This is a really interesting idea! However, I'm unsure whether it's wise
to bring this feature in without having the community test and validate it
first. Would it be possible to release this as an extension first so we
can gauge its stability and desirability in "the real world"?
As fa
On Tue, 22 Mar 2016 14:01:09 +0100, Craig Duncan wrote:
Why do you assume that Latte parser is limited by regexp ability to
parse
HTML?
Because it is:
https://github.com/nette/latte/blob/19b759b550caaad75ca0dee5f0d85f9ffb59c845/src/Latte/Parser.php#L124
No. That argument would only be
>
>
> Why do you assume that Latte parser is limited by regexp ability to parse
> HTML?
Because it is:
https://github.com/nette/latte/blob/19b759b550caaad75ca0dee5f0d85f9ffb59c845/src/Latte/Parser.php#L124
On Tue, 22 Mar 2016 13:32:58 +0100, Marco Pivetta
wrote:
On 22 March 2016 at 13:24, Jan Tvrdík wrote:
The escape context could be detected (e.g. Latte template engine
supports
context-aware escaping for years –
https://latte.nette.org/en/#toc-context-aware-escaping) but the logic is
quit
On 22 March 2016 at 13:24, Jan Tvrdík wrote:
> The escape context could be detected (e.g. Latte template engine supports
> context-aware escaping for years –
> https://latte.nette.org/en/#toc-context-aware-escaping) but the logic is
> quite complex for it to be included in PHP core.
Sorry, I h
On Mon, 21 Mar 2016 07:35:46 +0100, Daniel Beardsley
wrote:
Issue is "Escaping is done on a specific context".
I understand your proposal is focused on HTML escaping. However,
setting names like
__auto_escape_exempt_class
is not good choice. It has to be
__auto_html_escape_exempt_class
at le
"Rowan Collins" wrote in message news:56efe897.3070...@gmail.com...
Daniel Beardsley wrote on 21/03/2016 06:35:
You are right. Though not all those problems are serious:
* URI escaping:
Does anyone really use or echo when generating a uri?
* Javascript:
Good point, though I would say it
Hi,
basically I agree to you while I see the issue, but I don't think this
is the solution (it might have been a solution if introduced 20 years
ago, making it "secure by default" and let users opt-out where needed,
but now might lead to a BC hell now)
But a comment here:
On Mon, 2016-03-21 at 1
Honestly, as it stands this is a pretty terrible idea.
1. It has a huge potential for introducing BC breaks.
- I have some code somewhere which uses output buffering and echo to
write cached copies of html pages to disk. This would break that.
- Writing out html like structures when running as
Daniel Beardsley wrote on 21/03/2016 06:35:
You are right. Though not all those problems are serious:
* URI escaping:
Does anyone really use or echo when generating a uri?
* Javascript:
Good point, though I would say it's fairly rare to create javascript
code using a php template with v
> I think having the behaviour of language features depend in an incompatible
> way on a global runtime setting is a bad idea because it creates nonlocal
> effects and means code cannot be realiably composed.
This is probably the best argument against this RFC. Though how often
that issue would co
I think having the behaviour of language features depend in an incompatible
way on a global runtime setting is a bad idea because it creates nonlocal
effects and means code cannot be realiably composed. Effectively, every
function and method will have an implicit assumption about whether or not
it
> The similarity is that magic quotes assumed that the input data was going to
> be embedded within an SQL query without escaping, and therefore needed
> escaping. Of course that's an invalid assumption, the input data could be
> re-rendered, processed in some arbitrary way, written to a file, sent
On Mon, Mar 21, 2016 at 4:53 PM, Daniel Beardsley wrote:
> > This approach has the smell of magic quotes which we got rid of for
> > very good reason. XHP is much more explicit in separating markup from
> > data and relies far less (not at all when you do it right) on escape
> > hatches.
>
> Huh
> Wouldn't this __auto_escape setting effectively break libraries that depend
> on it being on or off?
The settings was meant to be turned on *only* during template
rendering. So, yes, if outside code is run during your template
rendering that also uses templating, but is unaware of
auto escaping,
> Issue is "Escaping is done on a specific context".
>
> I understand your proposal is focused on HTML escaping. However,
> setting names like
> __auto_escape_exempt_class
> is not good choice. It has to be
> __auto_html_escape_exempt_class
> at least because it is for HTML escaping.
Yes, the ini
> I agree XHP really is the right solution for this problem. It enables HTML
> to be created structurally and composably with a concise inline syntax, just
> like JSX/React does for JavaScript, and just like LINQ does for SQL in C#.
> It's much better than passing around snippets of HTML as strings
On Mar 21, 2016 12:53 PM, "Daniel Beardsley" wrote:
>
> > > T_ECHO (echo, > > ZEND_AST_ECHO_ESCAPE node in the syntax tree.
> > >
> > Interesting approach, I assume an explicit `echo $foo;` takes the
> > normal ZEND_ECHO route then?
>
> No, looking at the code and tests: echo, print, and parsing
Wouldn't this __auto_escape setting effectively break libraries that depend
on it being on or off?
People often write code to generate HTML like this:
ob_start();
?>
some HTML
more HTML
wrote:
> Hi Daniel,
>
> On Mon, Mar 21, 2016 at 7:11 AM, Daniel Beardsley
> wrote:
> > I'd like to su
> > T_ECHO (echo, > ZEND_AST_ECHO_ESCAPE node in the syntax tree.
> >
> Interesting approach, I assume an explicit `echo $foo;` takes the
> normal ZEND_ECHO route then?
No, looking at the code and tests: echo, print, and > Which allows instances of `HtmlString` to pass straight through a
> > tem
Hi Daniel,
On Mon, Mar 21, 2016 at 7:11 AM, Daniel Beardsley wrote:
> I'd like to submit an RFC (with a pull request) for adding auto-escaping to
> the php language.
>
> We at iFixit.com have used PHP for nearly a decade to run our website.
> Several years ago, we abandoned the Smarty templating
I agree XHP really is the right solution for this problem. It enables HTML
to be created structurally and composably with a concise inline syntax,
just like JSX/React does for JavaScript, and just like LINQ does for SQL in
C#. It's* much* better than passing around snippets of HTML as strings that
On Sun, Mar 20, 2016 at 3:11 PM, Daniel Beardsley wrote:
> I'd like to submit an RFC (with a pull request) for adding auto-escaping to
> the php language.
>
> T_ECHO (echo, ZEND_AST_ECHO_ESCAPE node in the syntax tree.
>
Interesting approach, I assume an explicit `echo $foo;` takes the
normal ZEN
I'd like to submit an RFC (with a pull request) for adding auto-escaping to
the php language.
We at iFixit.com have used PHP for nearly a decade to run our website.
Several years ago, we abandoned the Smarty templating engine and used php
files directly as templates. This worked, but was a bit uns
27 matches
Mail list logo
