CSS Selector parsing

[Jordi Boggiano]

Heya,

I have encountered some difficulties with CSS selectors that could not
be converted to XPath correctly, which ended up in the xpath ->query
call returning false, and then php isn't happy with the resulting :

foreach(false as $foo)

I would like to suggest that you replace the internal CSS>XPath layer
with this freshly released code, which is a straight port of a much
older Python lib, so I expected it to be fairly stable.

You can read the announcement here :
http://fabien.potencier.org/article/42/parsing-xml-documents-with-css-selectors

Cheers,
Jordi

[BrianS]

I like the idea of using third-party libraries for some of our
functionality. This one sounds promising in it's support of CSS, but
there is one drawback ... the code written specifically for symfony.
If we decide to use it there will be a bit of rewriting necessary to
integrate it with DOMPDF. I'm not saying that's out of the question,
but that does mean we'll need to maintain our own port.

We'll definitely take a look, though.

> You can read the announcement here :http://fabien.potencier.org/article/42/parsing-xml-documents-with-css...
>
> Cheers,
> Jordi
>
>  signature.asc
> < 1KViewDownload

[Jordi Boggiano]

On Sat, Apr 3, 2010 at 12:12 AM, BrianS <eclect...@gmail.com> wrote:
> I like the idea of using third-party libraries for some of our
> functionality. This one sounds promising in it's support of CSS, but
> there is one drawback ... the code written specifically for symfony.

I don't see what you mean, Fabien knows better than to create
cross-dependencies between components. The whole point of releasing
them as "components" outside of the symfony framework is that they are
independent pieces. The only symfony reference you have in there is
the namespace, but that really doesn't matter for code re-use.

One real issue however is that the code won't run in PHP <5.3 due to
the namespace declarations. So if you want to proceed with the massive
code cleanup, class renaming etc, you might as well throw namespaces
in there and require PHP5.3 for the next DOMPDF release. The other
approach is as you pointed out to fork it on github and remove
namespaces, then you should be able to merge bugfixes etc fairly
easily, but it's not as nice as just dropping in the code.

Cheers,
Jordi

[Woody Gilk]

Requiring PHP 5.3 is a non-starter. DOMPDF will _certainly_ be forked
if it requires 5.3.

-Woody

> --
> You received this message because you are subscribed to the Google Groups "dompdf-dev" group.
> To post to this group, send email to dompd...@googlegroups.com.
> To unsubscribe from this group, send email to dompdf-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/dompdf-dev?hl=en.
>
>

[Fabien Ménager]

This is a good idead, and would make dompdf even more robust.
I found another CSS selector to XPath parser here :
http://code.google.com/p/phpquery/source/browse/trunk/phpQuery/phpQuery/phpQueryObject.php#311
We should look at which is the best implementation. The one you
proposed may be easier to use, as it looks like a standalone solution.

This discussion is a little bit related to this one :
http://code.google.com/p/dompdf/issues/detail?id=127#c3
We should create a global discussion about a new implementation of the
CSS parser.

With a very robust CSS parser, we maybe could add an acid2.html in our
test files ... Why not ? ;)

> You can read the announcement here :http://fabien.potencier.org/article/42/parsing-xml-documents-with-css...
>
> Cheers,
> Jordi
>
>  signature.asc
> < 1 000AfficherTélécharger

[BrianS]

On Apr 3, 7:53 am, Jordi Boggiano <j.boggi...@seld.be> wrote:

> On Sat, Apr 3, 2010 at 12:12 AM, BrianS <eclecticg...@gmail.com> wrote:
> > I like the idea of using third-party libraries for some of our
> > functionality. This one sounds promising in it's support of CSS, but
> > there is one drawback ... the code written specifically for symfony.
>
> I don't see what you mean, Fabien knows better than to create
> cross-dependencies between components. The whole point of releasing
> them as "components" outside of the symfony framework is that they are
> independent pieces. The only symfony reference you have in there is
> the namespace, but that really doesn't matter for code re-use.

Ah, yes. You are correct. I didn't look too closely at the code before
I opened my mouth :(

> One real issue however is that the code won't run in PHP <5.3 due to
> the namespace declarations. So if you want to proceed with the massive
> code cleanup, class renaming etc, you might as well throw namespaces
> in there and require PHP5.3 for the next DOMPDF release. The other
> approach is as you pointed out to fork it on github and remove
> namespaces, then you should be able to merge bugfixes etc fairly
> easily, but it's not as nice as just dropping in the code.

As Woody has pointed out, I think at this point it's not a good idea
to require PHP 5.3. Certainly it would be nice to be able to use some
of the features available in the newer release, but I think that's
pushing things a bit too far for our user base.