[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] Experimental Stylesheet view
|
DOUG SATCHWELL wrote:
I've checked in a new 'Stylesheet' view. Its just experimental at this stage, so don't get raising any bugs just yet!
It displays the stylesheet's model (imports, variables and templats) - and could potentially be the outline viewer for xsl files, but at the moment its just a standalone view that you have to open via 'Show View', in the XML category.
The view makes use of the IWorkbenchAdapter mechanism for displaying the XSL elements. What I needed to do was:
- write an IAdapterFactory (org.eclipse.wst.xsl.ui.internal.XSLModelAdapterFactory)
- register it via the extension point org.eclipse.core.runtime.adapters
Then when displaying the model in a TreeViewer, I just use these two standard classes from org.eclipse.ui.model:
As well as being simple, the big advantage is that any plugin that wishes to display the XSL model in a viewer somewhere can use the standard content and label providers and without knowing anything about the internals of the XSL plugin.tv.setContentProvider(newBaseWorkbenchContentProvider());tv.setLabelProvider(newWorkbenchLabelProvider());
Give it a try.
Doug, it looks like these changes have broken the XPath Validation
tests. From my initial look, the model no longer includes the
<xsl:value-of> and <xsl:for-each> elements in the model. I think we
need in general some unit tests just for the model. Especially as it is
going to be used more as we get into some more advanced content
assistance and refactoring capabilities.
A couple of things that could be done.
1. Get the current failing test to pass by adding the missing
functionality to the model.
2. Back out this set of changes until all tests are passing, and then
check the code back in with additional tests for the model.
I also think that the model for now should remain internal code, instead
of being moved to a non-internal package. Just because it is still
under going some change.
I really do think that it is important to get into the habit of running
all the tests before checking code back into the system. And if you do
find bugs during development, try and create the necessary unit tests.
Again, if you need help getting started with creating the unit tests, or
need examples, ask. There are a wide variety of examples provided
through many eclipse projects.
Having the tests pass, makes it easier on others that are working on the
code to know that everything is working as expected after a change.
I'm all for making and adding features, but it really slows me down on
my end to have to reinvestigate why tests are after synchronizing with
CVS. I try to make sure that all tests are passing before I check code
in so that I don't cause any potential issues with sections of code that
you are working on.
I feel like I'm complaining, but to me from practicing agile
development, I've come to treat broken tests as a major problem, and
they get highest priority to be fixed over any other bug or feature
request. We've had a pretty good record on XSL Tools about keeping the
build clean, I'd like to continue that record as we continue to add
functionality.
Dave
