[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [Wtp-wst-dev] Issues when embedding CSS-support in the XML editor
|
Jason Parekh wrote:
Quick background: I work on the Google Plugin for Eclipse. We're
adding Google Web Toolkit UiBinder support to our plugin. (For the
curious, see the hello world examples at
http://code.google.com/p/google-web-toolkit/wiki/UiBinder.)
We're running into issues trying to get embedded CSS support for the XML
editor. Unfortunately, all the existing helper classes for getting
embedded CSS support assume the parent tag of the embedded CSS will be
"<style>" (like in HTML), which doesn't work for us (we namespace-prefix
the style tag, e.g. "<ui:style>"). We're circumventing this by
extracting the CSS text from the XML document, and creating a new,
temporary CSS document and model. For proposals, we work off this and
give an adjusted document offset. For formatting, we work off this and
paste the formatted text back into the original XML document. This is
working, though hasn't been stress tested.
The parent tag issue is one we might want to improve in WTP itself
by making it more generalized.
The latest issue which we don't have a clear workaround for is support
UiBinder-specific CSS at-rules (for example, @if or @def.) It looks
like the CSS scanner and parser don't work well with custom at-rules.
For example, the scanner marks "@" as an undefined type, and the
following "if" gets marked as a selector name. Things go downhill from
there :( CSS formatting gets thrown off, as do content proposals.
Our current approach is to replace the CSSTokenizer with our
implementation (based off the original), and masquerade our custom
at-rules as other tokenizer types. For example, if we encounter an @if,
we would return CSS_DELIMETER (or something similar, haven't dug around
to see which type would be best.) This should let the existing CSS
formatter and content proposal logic work properly (obviously ignoring
our custom CSS at-rules, which is fine for now.)
Ideally, instead of our custom at-rules masquerading as other types,
we'd like to extend the CSS model, but I don't think this is possible
since CSSNodeImpl and its subclasses have default (package-private)
visibility.
Do you guys have any suggestions? (I'll take all suggestions, even
those that don't pertain to my issue ;) .) Please let me know if I
should clarify or explain further.
I haven't managed to try this out myself, but does an unmodified
parser include your custom rules in the model with a type of
org.w3c.dom.css.CSSRule.UNKNOWN_RULE? I have to wonder if it just
requires some tweaking in
CSSModelParser#insertBraceOpen(IStructuredDocumentRegion) or
CSSModelParser#insertStructuredDocumentRegion(IStructuredDocumentRegion)
to support their proper inclusion in the model, and perhaps some
minor redesign to allow for rules with names we don't know about at
compile time.
--
---
Nitin Dahyabhai
Eclipse WTP Source Editing
IBM Rational
