Hi Steven, If I remember correctly the undo buffer was reset if the file was reloaded from disk at some point in the past but the undo support was improved and now it should work also after reloading the file from disk. Git support in oXygen is not on our short term plans now, but this is recorded on our issue tracking system and its priority may change in the future. One issue with these external XSLT transformations is that they do not preserve DOCTYPE information and XSLT also does not see entities, they will be replaced with their expansion text. We had also at the oXygen users meetup last Sunday requests to provide support for custom actions, like we have for the Author editing mode, also in the Text editing mode. Such custom actions can use the XSLTOperation which is configured with an XSLT script but you can also control what is the input and what happens with the result, so you can process only a part of the document and avoid some of the issues, like loosing the DOCTYPE for example. There is also an idea of allowing XSLT processing over the current document but done only on the root element and after entities are translated to text by replacing for example &entity; with &entity; - oXygen then will just replace the root element in the document and will convert & back to & to put entities back. Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 11/22/13, 7:03 PM, Steven Anderson wrote:
I can verify that works. I did it once accidentally lost a bit of work. I don't think undo worked for me. Ever since I've been using git a lot more, even on working sets.
Speaking of which, any chance to add git support. I'm sure I can do pretty much everything I want using custom external tools, but I haven't really tried it.
On Fri, Nov 22, 2013 at 8:03 AM, George Cristian Bina <george@oxygenxml.com <mailto:george@oxygenxml.com>> wrote:
Hi Wendell,
You cannot read and write in XSLT the same file.
However, if your XSLT takes the document as input and outputs the transformed document then there is nothing that stops you from configuring the output of the transformation scenario to be the current file, use ${cf} in the "Save As" field of the Output tab when you setup the transformation scenario.
Then, you can apply your processing by double clicking on the scenario in the Transformation Scenarios dialog - the nice effect of this is that the content in the editor will be automatically refreshed with the change, as we check this and load automatically the file from disk if it is changed - just make sure the file is saved before invoking the transformation, otherwise you will be asked if you want to reload the content from disk. The added bonus is that you also have undo support after you perform the change you can easily go back to the previous state if you are unhappy with the new document content.
I just tested a clear stylesheet like
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:template match="node() | @*"> <xsl:copy> <xsl:apply-templates select="node() | @*"/> </xsl:copy> </xsl:template>
<xsl:template match="text()"> <xsl:if test="normalize-space(.)=''"><xsl:copy-of select="."/></xsl:if> </xsl:template>
</xsl:stylesheet>
that will preserve the indenting but will clear all text content from the current document.
Best Regards, George -- George Cristian Bina <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com
On 11/21/13, 6:06 PM, Wendell Piez wrote: > Gerrit, you leave a misimpression that I suggested the OP use d-o-e, > when in fact I was holding my nose when I copied that bit of his code. > (I copied the code with one hand while I held my nose with the other.) > I even offered that he should perhaps consider using a character map > instead. I guess you missed that part. :-P > > I actually don't think d-o-e is always evil. Just usually. Maybe > always in XSLT 2.0. But it is sometimes useful to commandeer the XSLT > serializer to produce non-XML outputs even with method="xml", and in > 1.0 ... maybe a case of one evil begetting another? > > Plus, didn't you like my innovative and elegant use of > for-each-group[@group-by='true()'] to avoid a redundant tree traversal > into the descendants he wanted to collect? > > Back to oXygen -- let's see what George has to say about my impossible > feature request (some way to "modify" an original file with XSLT). I > am not above using the debugger, as a stopgap, to accomplish the same > end (running a transformation and replacing an original with its > transformation result). > > Cheers, Wendell > > Wendell Piez | http://www.wendellpiez.com > XML | XSLT | electronic publishing > Eat Your Vegetables > _____oo_________o_o___ooooo____ooooooo_^ > > > On Wed, Nov 20, 2013 at 11:00 AM, Imsieke, Gerrit, le-tex > <gerrit.imsieke@le-tex.de <mailto:gerrit.imsieke@le-tex.de>> wrote: >> +1 >> >> And this suggestion kind of compensates your recent d-o-e proposal on >> xsl-list ;) >> >> (I didn’t even read the post in full because “d-o-e” is a kind of >> stopword for me, similar to “XSLT 1.0”, “CDATA”, or “named entity”.) >> >> Sorry fellow oXygenists for taking this off-topic. And Wendell, I hope >> you don’t mind a little teasing. >> >> Gerrit >> >> On 20.11.2013 16:49, Wendell Piez wrote: >>> Eliot and oXygenists, >>> >>> Since oXygen won't save over the XML source, I'd have the >>> transformation scenario display output in the the XML results, then >>> save from there. Two steps, not one. >>> >>> Adding to Eliot's request -- I know the usefulness of a generalized >>> "run XSLT and update the document with the result" has been discussed, >>> but I can't remember what the impediments are. >>> >>> Something like an option in a transformation scenario to "replace >>> source document"? >>> >>> Along similar lines, if transformation scenarios could reference >>> editor windows as well as files, one could write an XSLT, apply it to >>> an XML, inspect the output in the results view, and save it (even over >>> the original) if one liked it, or revise the XSLT and run it again if >>> necessary. This can be done now with more overhead (we have to save >>> the XSLT out first, then create a transformation scenario). Perhaps a >>> particular buffer could be designated as a "sandbox" for such purposes >>> (and contain XSLT or XQuery). >>> >>> Of course it would be dangerous, but so are lots of power tools. >>> >>> Cheers, Wendell >>> >>> Wendell Piez | http://www.wendellpiez.com >>> XML | XSLT | electronic publishing >>> Eat Your Vegetables >>> _____oo_________o_o___ooooo____ooooooo_^ >>> >>> >>> On Wed, Nov 20, 2013 at 12:05 AM, Eliot Kimber <ekimber@rsicms.com <mailto:ekimber@rsicms.com>> wrote: >>>> For the DITA RelaxNG support that will be in DITA 1.3 I want to implement >>>> an action that can be applied to RNG document type shell grammars that >>>> looks at each referenced module, gets its domains attribute contribution >>>> (which will be in a specific subelement within the referenced module, and >>>> add it to the right place in the shell (a pattern named “domains-att”). >>>> >>>> This is of course easy to do with XSLT. >>>> >>>> My question: what’s the best way to set this up in Oxygen so that I can >>>> just do an “update domains attribute” action when editing a document type >>>> shell schema? >>>> >>>> Thanks, >>>> >>>> Eliot >>>> >>>> -- >>>> Eliot Kimber >>>> Senior Solutions Architect >>>> "Bringing Strategy, Content, and Technology Together" >>>> Main: 512.554.9368 <tel:512.554.9368> >>>> www.reallysi.com <http://www.reallysi.com> >>>> www.rsuitecms.com <http://www.rsuitecms.com> >>>> >>>> >>>> _______________________________________________ >>>> oXygen-user mailing list >>>> oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> >>>> http://www.oxygenxml.com/mailman/listinfo/oxygen-user >>> _______________________________________________ >>> oXygen-user mailing list >>> oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> >>> http://www.oxygenxml.com/mailman/listinfo/oxygen-user >>> >> >> -- >> Gerrit Imsieke >> Geschäftsführer / Managing Director >> le-tex publishing services GmbH >> Weissenfelser Str. 84, 04229 Leipzig, Germany >> Phone +49 341 355356 110 <tel:%2B49%20341%20355356%20110>, Fax +49 341 355356 510 <tel:%2B49%20341%20355356%20510> >> gerrit.imsieke@le-tex.de <mailto:gerrit.imsieke@le-tex.de>, http://www.le-tex.de >> >> Registergericht / Commercial Register: Amtsgericht Leipzig >> Registernummer / Registration Number: HRB 24930 >> >> Geschäftsführer: Gerrit Imsieke, Svea Jelonek, >> Thomas Schmidt, Dr. Reinhard Vöckler >> _______________________________________________ >> oXygen-user mailing list >> oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> >> http://www.oxygenxml.com/mailman/listinfo/oxygen-user > _______________________________________________ > oXygen-user mailing list > oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> > http://www.oxygenxml.com/mailman/listinfo/oxygen-user > _______________________________________________ oXygen-user mailing list oXygen-user@oxygenxml.com <mailto:oXygen-user@oxygenxml.com> http://www.oxygenxml.com/mailman/listinfo/oxygen-user
--
Steve