[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] Adding Embedded Content/Regions to XML Editor
|
Maybe I'm missing the finer detailed picture :) but in general,
partition types are merely a handy way to configure things in the
Eclipse Document/Editor framework ... so that, at least to some
degree, what ever produces the partition type, doesn't have to know
anything about who uses that partition (and vice versa).
Correct, and PartitionTypes are also used to help limit the scope of
which Content Assist Processors are available in particular partitions.
I.e. you don't necessarily want full XML content assist within a XPath
Partition (I'll switch to that terminology as that is really what it is
identify).
So, I think there's some sense in having an XSL_Partition, though I
might call it an XSL_Select_Partition. That would just allow some code
divisions of all the complications of select attributes. But, I'm not
sure there would be much advantage on a finer level of detail in
partition types (but, I don't know XSL all that well).
As Jesper said, the XPath partition can actually appear in any attribute
within the XSL document. This is done by the use of { }, which is a
short cut for doing an xsl:value-of inside an attribute (you can't do
xsl:value-of inside an attribute becuase it's an element and you can't
have elements in attributes. Along with this the test and match
attributes also need to have the XPath partition type on them as well.
Don't forget, the processors ... content assist, highlighting, etc.,
can still do _some_ smart (complicated) things where they (possibly)
re-parse the attribute value, and do different things based on exactly
what's there and where the cursor is, etc. And, then, that could be
your own mini-parser that's specialized for that case, instead of
having to fit in and handle xml parsing in general.
Yeah, the problem is that it makes it more complicated than it needs to
be...lots of overriding and rewriting of the base functionality of the
content assisters and proposals. The issue is that the eclipse
standard content assist wants to start with all data from the beginning
of the region up to the current cursor position and use that to
determine the proposals. It also by default wants to overwrite the
entire contents instead of inserting the content. Again, you have to
get down pretty deep to start overriding some of this functionality.
It gets to be very messy as well.
By having a particular partition and specific content assist processors,
some content assist options can be better controled just for XSL. You
don't necessarily want to add { to the xml content assist processor, and
for doing XPath completion you may want to add [(/:: and a few others to
help offer proposals at certain points. By having it in the XPath
partition this is much easier to control.
A good example, I think, of where partitions are handy is the HTML
Script tag ... maybe you could see if XSL fits this model.
In the following examples, from the spec, the main partitioner doesn't
need to know much about the difference between vbscript, javascript,
and tlk, ... just know how to create partitions of the type SCRIPT_VB,
SCRIPT_JS, or SCRIPT_TLK, (based solely on the <script tag, then
others can create "smart processors" for those different languages
contained within the script tag. and, I believe, attributes such as
"onmouseover", etc., can also have different languages, so that's
where the similarity to XSL is. But ... can you really have different
"languages" in the select attributes? Or, is it something you, and the
XSL_Select processor would know about (i.e. always XPATH)?
<example>
<SCRIPT type="text/javascript">
... (SCRIPT_JS Partition)
</SCRIPT>
<SCRIPT type="text/vbscript">
... (SCRIPT_VB Partition)
</SCRIPT>
<SCRIPT type="text/tcl">
... (SCRIPT_TCL Partition)
</SCRIPT>
</example>
Hope it helps ...
I've got the partitions created already (well to a point, I need to
limit them to certain attributes, but when the
StructuredDocumentPartitioner classes are called I can't seem to find a
way to determine the element name that I'm on to help fine tune this. I
believe the above uses an Embedded Content type to help setup a
container for this. It's something I looked into but wasn't quite sure
how to implement the Embedded Content and Container so that I could
implement the XPath specific parsing and region setup. Any clues on
how to do this with the XML editor and not having to change the
XMLTokenizer would be appreciated.
Dave
------------------------------------------------------------------------
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev
