Re: [wtp-incubator-dev] Experimental Stylesheet view

[DOUG SATCHWELL <doug.satchwell@xxxxxxxxxxxxxx>]

Actually, I did run the test before committing but ran the wrong one (the launching test is set up as favourite and I pressed that one by mistake, which works fine). Anyway, the bug is fixed so the validation test that was failing now passes - it was a very minor thing. 
But one of the tests is failing for me when I run it locally - its one of your Xpath tests and has nothing to do with the changes I made to the model. Don't worry, I won't lecture you about it :-)
The model should probably be internal.provisional, but its not the only thing that needs moving so we should move the other stuff at the same time.
Cheers,
Doug



----- Original Message ----
> From: David Carver <d_a_carver@xxxxxxxxx>
> To: WTP Incubator Dev list <wtp-incubator-dev@xxxxxxxxxxx>
> Sent: Wednesday, 3 September, 2008 5:38:19 AM
> Subject: 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 
> and 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
> 
> 
> _______________________________________________
> wtp-incubator-dev mailing list
> wtp-incubator-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev