This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
It would be nice if the user could right click on an XML document and transform it with an XSL document. The XSL document chosen and destination location should be based on either of the following: 1 - Properties in the property sheet for the XML document if they are set, otherwise: 2 - The reference to an XSL file in the content of the XML document, if the reference exists, otherwise: 3 - The user is prompted for information not filled in from the above sources.
Copy-paste from nbusers mailing list. -------- Original Message -------- Subject: [nbusers] XSLT development From: Daryl Stultz I find that the development of XSLT projects works best when the stylesheet is not declared in the XML. I model web pages with XML and apply XSLT to get the HTML. The XSL file to use is not specified in the XML - that way I can switch the XSL any time to get different views of the page. A proper XSLT dev environment involves editing an XML doc in one view, XSLT in another and then transforming to HTML or whatever. (The transform action should remember the last stylesheet and run from a shortcut since it will happen a lot.) CookTop is a very good environment for this - but it's all text based. Merlot is a good Java XML editor but lacks support for XSLT doc editing. Apparently the DTD is challenging since you can mix in non-namespaced tags of your choice. Daryl Stultz
The above is fair enough. I think it would probably suit most development styles to assign an XSL file in the property sheet/when prompted, however, I would postulate that there are some that use the definition in the XML file (as we have at times). I would see it as a lower priority than the ability to assign an XSL file in the property sheet or when prompted, but useful nonetheless. Ideas anyone?
*** Issue 20799 has been marked as a duplicate of this issue. ***
I agree with Daryl Stultz : Having a XSLT developpement environnement would be great. I use NetBeans for XML only (I put out all the other modules.) and DocBook.
First draft of User View is done.
Must have feature.
Please, could you review User View document? http://xml.netbeans.org/tools/user/xslt_execution.html Thanks.
Some comments on the user view document: When a user performs a transformation, I would see three outcomes that they could want: 1 View the result; 2 Save the result to a file; or 3 Both of the above. I think the user interface should reflect this fundamental choice. Also, if the user is viewing, they may want to view in the browser, or in the source editor/default action. So I think the interface should present a choice between the above main options, followed by an option to provide extra information based on the first choice. So if saving was desired, an output filename choice is available, if viewing is chosen the viewing action choice is available. The only problem with this that I can see is how to represent that initial choice. you could have two checkboxes with the artificial constraint that at least one must be selected, or you could have a drop-down with three choices, 'save', 'view', or 'save and view'. I think both of these aren't particularly desirable, the first because it's not how the user expects that control to work, the second because the choices in the drop-down aren't mutually exclusive. I suppose without any other options, the second is the more desirable of the two. So the interface could look like this: --------------------------------------------- | | | XML Source: ############\/ |Browse...| | | XSL Script: ############\/ |Browse...| | | | | Action(s): ############\/ | | | | Output To: ############\/ |Browse...| | | View In: ############\/ | | | | | OK | |Cancel | | | | --------------------------------------------- OR: --------------------------------------------- | | | XML Source: ############\/ |Browse...| | | XSL Script: ############\/ |Browse...| | | | | [] Save to File | | | | Save To: ############\/ |Browse...| | | | | [] View Output | | | | View In: ############\/ | | | | | OK | |Cancel | | | | --------------------------------------------- With the appropriate controls disabled. For the issues: Transformation of mulitple XML documents being shown in the one window would create multiple outputs (meaning the user would have to specify multiple targets), so I think it would complicate the user interface too much to support multiple transformations in that way. The other option is you could open a window for each file selected so that the user could enter the details for each to be transformed. Optionally the same sort of mechanism as the exception window could be used (all windows in the same frame, next to go to the next window shown, with the addition of OK closing the current but not the others). In terms of suporting DocBook, It would probably be good to have some default XSLs in a particular folder, and this could include DocBook ones (assuming I've understood what is meant by 'support'). How to access them through the UI, I'm not sure. Maybe they could be the initial populators of the most recently used drop down. I think it would be annoying to have that directory the default for the initial browse location, so that's probably not good. In terms of supporting FOP: it would probably be useful, but I'm not sure how high priority for the first inclusion of transformations. If it is included, I guess it should be done in a general way so that other processors could be easily added later. Since FOP would be a different kind of interaction than a normal transform, if included it should be a different window and menu item (possibly a sub-menu which lists all attached processors). I know almost nothing about FOP, so I'm not sure what (if anything) would be required from the window.
I think that NetBean should provide : - a simple and intuitive way of processing XSLT. (One XML, one XSLT, one Output.) - a way to execute an external script (windows or unix), eventually shows the processing output in a NetBean windows (like a compilator), and let the user refresh his browser or anything he uses to view the resulting files (wich can be numberous and various.) This way : it stays simple and extensible. (Conserning Docbook, I use many XML files keep together with an entity file, SAXON and FOP to process the data and there are many html PDF ans PS files as output.)
Bruno: I'm not sure I understand the second point, do you mean: All transformations and viewing should be performed by an external script, with the output viewed in text form in the output window in the same fashion as the compiler? And any external viewing of the file is accomplished by the user pointing his/her browser to the appropriate output file?
I mean that we can't avoid an external script for complex processing of XML files. > with the output viewed in text form in the output window in > the same fashion as the compiler? YES, the ouptut of the processing information, like "Error in XSLT line 5468 ..." > And any external viewing of the > file is accomplished by the user pointing his/her browser to the > appropriate output file? Yes and refresh when a new transformation is made.
I would like to have the option of retrieving the input XML from a URL. This would make it easier to test XSLT on dynamically generated XML.
User View document as sub-task (issue #21851) of this feature.
First of all, thank you for your time you spent you wrote suggestions. -- Robert, I do not see big difference between your suggested UI changes and mime proposed one. You just add check boxes (Save to File|View Output) and same actions I provide by combo boxes. Reason why I have introduced such UI is following. Typically, you have (1) XML source, (2) XSLT script and (3) want to create output or just preview -- first three rows of components. Bonus: if you create output file, you can do some special action with it - view, edit, ... -- 'Process Output'. The only problem I see is that you can find 'Preview' or 'View' in two places but I think both are logical. It looks Multiple transformations would be useful, so I will propose posible solutions at users@xml. Bruno have inspired me to think about XSLExecutor API (similar to Java Executor) and FOP could be supported by another XSLExecutor implementation in later phase. Each XLSExecutor would provide its own UI. K.C., it make sense to support URL for XML source and also for XSLT script. Thanks. -- I would like to ask, could we move discussion to users@xml.netbeans.org, it begin to be so long. We could use this report to trace final decision. Thanks.
I probably should have made it more clear what angle I was making my comments from. I was giving suggestions from a tweaking point of view, not from the point of view of making functional changes. The same functions are available (probably equally conveniently) from both, and, as such, I don't see the current design as a real problem. What I was thinking was that since the main things a user is interested in are as I stated, these should be the things that the user initially chooses. So if the user wants to view, that is the control that is available to him/her - the save control is not available (and vice-versa if the user wants to save and not view), trying to make the flow of the user interface be the flow of the required decisions (of the user) so that it is easier to use. I don't know if I can explain what I mean properly...
Simple action implemented. Enhanced support will be addressed by next release.
UI should be reviewed by UI experts (issue #22841) and also documented (issue #22931).
ok, done