1. I'd like to ask you about a simple addition,
a line numbering. When one deals with an external XSL processor it may show error line number and so on. It would be essential to have it in Stylus.
2. Also it would be nice to have the result window to show the produced HTML/XML more nicely than it does now showing couple of very long lines which are very difficult to deal with.
3. This would be a great feature. Imagine, you could introduce something similar to MSFT Design-Time Controls or the JSP analog of it but for XSLT. Let's call these things
XSLT beans. So entire user interaction/GUI could be written in XSLT producing HTML for GUI/user interaction. The result of XSLT bean would be of course XSLT or XML or HTML portion that would be 1) either included directly in place of it, or 2) it'll produce XSLT that would be included as import/include template.
Subject:Re: New feature request: Line numbers Author:Minollo I. Date:13 Sep 2001 03:47 PM
>1. I'd like to ask you about a simple addition,
>a line numbering. When one deals with an external XSL processor it may
>show error line number and so on. It would be essential to have it in Stylus.
What build are you running? Line numbers are displayed in the bottom-right
part of the window. Or are you saying you would like to see line numbering
on the left column of the editor?
We have a PCR open for a "goto line" functionality; that will be available
soon.
>2. Also it would be nice to have the result window to show the produced
>HTML/XML more nicely than it does now showing couple of very long lines
>which are very difficult to deal with.
Actually the result window allows you to display the result of an XSLT
transformation in a quite flexible way. You have three (two pre-3.1)
preview modes:
- raw text (which is probably the one you are mentioning)
- IE5 view (which is using IE5 as a viewer, which allows you to see
rendered HTML or XML)
- XML tree view (which displays an XML output as an XML tree)
>3. This would be a great feature. Imagine, you could introduce something
>similar to MSFT Design-Time Controls or the JSP analog of it but for XSLT.
>Let's call these things XSLT beans. So entire user interaction/GUI could
>be written in XSLT producing HTML for GUI/user interaction. The result of
>XSLT bean would be of course XSLT or XML or HTML portion that would be 1)
>either included directly in place of it, or 2) it'll produce XSLT that
>would be included as import/include template.
Interesting; we are actually thinking about something similar in the
context of the XML-HTML wysiwyg work we are doing.