Hi Brian,
From my early experiments, it's quite straightforward to replace the parser, as long as it implements the SAC API (And the Eclipse CSSParser interface). Part
of the difficulty is indeed in the selectors/conditions implementation, since Batik CSS implements them (Using a custom "ExtendedSelector/ExtendedCondition" interface). It takes some time to refactor the selector/condition implementation from the Parser to
the Engine, but it’s mostly a structural change (The implementation of the selectors/conditions is easily reused)
When the parser doesn’t implement the SAC API, it’s a little bit more complicated, since we have to wrap their API into a SAC connector (Or change the engine
implementation, which is even worse). But it’s doable (There are not so many concepts in the CSS grammar).
Finally, even with Batik and CSSParser (which implement SAC), you need some of their internal APIs because SAC itself is not really maintained and doesn’t expose
all the required concepts (Especially for CSS3). So even if the logic is separated from the parser, it’s never straightforward to replace a parser with another.
Max,
Ø
have you asked if the project would be willing to consider an alternative license ?
There are some additional issues with the CSSParser, which doesn’t support some of the concepts we need, and the project seems a little bit less active than
the Phloc parser. It’s a little bit difficult to compare the two parsers since it’s not possible to switch between them seamlessly, and I don’t really want to implement both :) Thus my favorite choice for the one which could be used quickly (Supports all the
concepts we need, and is already released under a compatible license). But if anyone has an experience with CSS3 Parsers in Java, I’ll be happy to reconsider this (That was also the point of the discussion)
Regards,
Camille
De : cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
De la part de Brian de Alwis
Envoyé : lundi 2 mars 2015 21:09
À : Cross project issues
Objet : Re: [cross-project-issues-dev] CSS Parsers & Eclipse
Hi Camille.
I’d be somewhat interested from the Platform/UI perspective as Batik’s CSS seems unmaintained, and I think there are some CSS3 selectors that would be useful to bring in. But for us the parser is only part of the issue: the underlying rules
engine is the much bigger piece.
In Papyrus, we’re considering a migration to the CSS version 3 (Instead of the CSS 2.1 we’re currently using). Until now, we were partially relying on the E4 CSS Engine,
and the underlying Batik/CSS Parser. However, the parser doesn’t support CSS3. We’ve been investigating different CSS3 parsers for Java, and found that all parsers implementing the W3C SAC API are hardly maintained (With an exception for CSSParser [1], but
it is distributed under the LGPL License, so it is not an option).
So we’re now seriously considering the Phloc CSS Parser [2], which unfortunately doesn’t implement SAC (So the translation is not straightforward). This means that we’ll
have to re-implement most of the engine as well. Are there any other projects interested in moving to a more recent version of CSS? The parser/API is the main concern here IMO, since CSS3 is split into several optional modules (You can simply ignore some of
the parsed elements if you don’t need to support a given module, but the parser needs to recognize every elements to successfully parse the file).
We also provide an XText editor for CSS (Currently 2.1), but it’s not good enough to be used at runtime, so we only use it as a file editor (especially for Papyrus-specific
auto-completion and such). We’ll incrementally update it to support the CSS3 concepts we need, but we’re not planning to go much further.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
