XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
Peter JaffeSubject: Usability feedback on 3.1 Beta build 057d
Author: Peter Jaffe
Date: 23 Aug 2001 11:10 AM
Here are a few issues that I would be happy to see addressed in future builds. I ranked them with highest priority first (in my mind). I apologize if this would have been more useful broken out into separate posts.

Debugger
--------
1. It would be great if one could evaluate Xpath expressions in the debugger relative to the current context. My partial "work around" has been to open the XML source (the "open XML from scenario" is unfortunately disabled during debugging) and type into the XML Query window the contents of the [Context] "variable" (this can't be copied to the clipboard) and then append the appropriate string from the XSL source.

2. The XSLT editing view and the XSLT Preview text view both "line home" on each step in the debugger. Due to indenting in XSLTs and HTML output being white space insensitive, I find many files have long line widths. This behavior forces me to repeatedly adjust the window scrolls to see the relevant text after each step in the debugger. Linewrap in the XSLT text preview would probably be sufficient for that panel. It seems further cursor position control would be needed in the XSLT source panel.


Scenarios
---------
3. The "Custom Processor" and "Custom Post-Process" attributes for a scenario are lost once you switch to one of the internal engines. Could the entered values be preserved even when they aren't selected?

4. It would be great if there was a master template for scenarios: base URL, "store paths relative", Processor, and Post-Processor settings. Although, I realize this is probably a bit far fetched.


Productivity Impacting
----------------------
5. It would be great if you could introduce the common Windows key bindings for the file browser. Tab to get focus on the directory contents, typing a letter jumps to the matching directory, return enters the directory, backspace steps up a directory... Just one of those things that impacts my productivity, so I realize it may not be a high priority.

6. File revert. Although, there is always the work around of closing the file, choosing not to save, and re-opening.


As an aside, I have been evaluating many XML/XSL development tools, and I have to say that 3.1 Beta build 57d is GREAT! I had to drop 3.0 because it made team development difficult because of storing scenario meta data in the XSLs, but I now think this tool is ready to be adopted by my team!

Any chance you guys are working on an editor that leverages the back trace functionality so the XSL is automatically changed through modifications to the output HTML? I think this would be an EXTREMELY powerful addition (if a deterministic mapping is possible), and particularly if it included some HTML WYSIWYG editing capabilities. I am continually looking for a tool that bridges graphic designers and XSL developers, and this is the closest I have seen so far.

Thanks for all your hard work that makes the rest of us more productive (and happy!).

Pete Jaffe
Nevo Technologies

Postnext
Minollo I.Subject: Re: Usability feedback on 3.1 Beta build 057d
Author: Minollo I.
Date: 23 Aug 2001 11:49 AM

>...
>1. It would be great if one could evaluate Xpath expressions in the
>debugger relative to the current context. My partial "work around" has
>been to open the XML source (the "open XML from scenario" is unfortunately
>disabled during debugging) and type into the XML Query window the contents
>of the [Context] "variable" (this can't be copied to the clipboard) and
>then append the appropriate string from the XSL source.

This is high in our todo list; we hope to get it done by 3.1 GA.

>2. The XSLT editing view and the XSLT Preview text view both "line home"
>on each step in the debugger. Due to indenting in XSLTs and HTML output
>being white space insensitive, I find many files have long line
>widths. This behavior forces me to repeatedly adjust the window scrolls
>to see the relevant text after each step in the debugger. Linewrap in the
>XSLT text preview would probably be sufficient for that panel. It seems
>further cursor position control would be needed in the XSLT source panel.

I understand the problem; we will investigate. I don't think that linewrap
will be the solution.

>3. The "Custom Processor" and "Custom Post-Process" attributes for a
>scenario are lost once you switch to one of the internal engines. Could
>the entered values be preserved even when they aren't selected?

I'm filing a PCR about this.

>4. It would be great if there was a master template for scenarios: base
>URL, "store paths relative", Processor, and Post-Processor
>settings. Although, I realize this is probably a bit far fetched.

An easier way to go would probably be to have the possibility to inherit
those attributes from another scenario; we have been thinking about this
for a while; we'll work on some solution. I'm not positive such solution
will make 3.1.

>5. It would be great if you could introduce the common Windows key
>bindings for the file browser. Tab to get focus on the directory
>contents, typing a letter jumps to the matching directory, return enters
>the directory, backspace steps up a directory... Just one of those things
>that impacts my productivity, so I realize it may not be a high priority.

It's in our todo list. We'll get there.

>6. File revert. Although, there is always the work around of closing the
>file, choosing not to save, and re-opening.

I'm adding a PCR for this.

>As an aside, I have been evaluating many XML/XSL development tools, and I
>have to say that 3.1 Beta build 57d is GREAT! I had to drop 3.0 because
>it made team development difficult because of storing scenario meta data
>in the XSLs, but I now think this tool is ready to be adopted by my team!

We are of course very glad to hear this. And we do appreciate your feedback
and help to improve the product.

>Any chance you guys are working on an editor that leverages the back trace
>functionality so the XSL is automatically changed through modifications to
>the output HTML? I think this would be an EXTREMELY powerful addition (if
>a deterministic mapping is possible), and particularly if it included some
>HTML WYSIWYG editing capabilities. I am continually looking for a tool
>that bridges graphic designers and XSL developers, and this is the closest
>I have seen so far.

Yes, we have been working on that for a while now. Actually we had
something that we called wysiwyg editing in Stylus 2.0; but we decided not
to port that functionality to 3.0 because it wasn't flexible and reliable
enough.
We have re-designed and we are now re-writing html wysiwyg. We will include
it in the product as soon as we can; hopefully that will happen before the
end of the year.

Thanks,
Minollo

Postnext
Darren HaydukSubject: Usability feedback on 3.1 Beta build 057d
Author: Darren Hayduk
Date: 23 Aug 2001 01:44 PM
My annoyance here is that (when stepping through code with F11), always scrolls the code so that the current line is at the bottom of the window (you can't see any of the code following the current line).

If I manually scroll the text, the next F11 moves the active line back to bottom of window.

I appreciate the editor making sure the currently executing line is visible, but how about scrolling only if the current line is not visible, rather than every step?? (And then scroll like 3/4 of a screenful.)

Darren

On 8/23/01 11:10:04 AM, Peter Jaffe wrote:
>Debugger
>--------
>2. The XSLT editing view and
>the XSLT Preview text view
>both "line home" on each step
>in the debugger.

Posttop
Minollo I.Subject: Re: Usability feedback on 3.1 Beta build 057d
Author: Minollo I.
Date: 23 Aug 2001 01:54 PM

>My annoyance here is that (when stepping through code with F11), always
>scrolls the code so that the current line is at the bottom of the window
>(you can't see any of the code following the current line).
>
>If I manually scroll the text, the next F11 moves the active line back to
>bottom of window.

I can see what you are saying.

>I appreciate the editor making sure the currently executing line is
>visible, but how about scrolling only if the current line is not visible,
>rather than every step?? (And then scroll like 3/4 of a screenful.)

This is definitely a bug; we will work on that.
Thanks,
Minollo

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.