xsltforms-support Mailing List for XSLTForms (Page 42)
Brought to you by:
alain-couthures
Menu
▾
▴
xsltforms-support — XSLTForms support list
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(9) |
Jul
(16) |
Aug
(5) |
Sep
(43) |
Oct
(36) |
Nov
(58) |
Dec
(43) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2010 |
Jan
(79) |
Feb
(81) |
Mar
(107) |
Apr
(93) |
May
(85) |
Jun
(54) |
Jul
(64) |
Aug
(54) |
Sep
(45) |
Oct
(53) |
Nov
(34) |
Dec
(77) |
| 2011 |
Jan
(56) |
Feb
(53) |
Mar
(52) |
Apr
(66) |
May
(44) |
Jun
(16) |
Jul
(28) |
Aug
(5) |
Sep
(15) |
Oct
(21) |
Nov
(51) |
Dec
(46) |
| 2012 |
Jan
(16) |
Feb
(38) |
Mar
(47) |
Apr
(45) |
May
(41) |
Jun
(41) |
Jul
(72) |
Aug
(17) |
Sep
(10) |
Oct
(16) |
Nov
(29) |
Dec
(30) |
| 2013 |
Jan
(25) |
Feb
(13) |
Mar
(20) |
Apr
(25) |
May
(34) |
Jun
(8) |
Jul
(12) |
Aug
(9) |
Sep
(21) |
Oct
(19) |
Nov
(6) |
Dec
(2) |
| 2014 |
Jan
(14) |
Feb
(8) |
Mar
(7) |
Apr
(13) |
May
(33) |
Jun
(13) |
Jul
(6) |
Aug
(5) |
Sep
(5) |
Oct
(34) |
Nov
(7) |
Dec
|
| 2015 |
Jan
(1) |
Feb
(6) |
Mar
(17) |
Apr
(12) |
May
(10) |
Jun
(18) |
Jul
(31) |
Aug
(9) |
Sep
(3) |
Oct
(6) |
Nov
(19) |
Dec
(1) |
| 2016 |
Jan
(18) |
Feb
(4) |
Mar
(13) |
Apr
(19) |
May
|
Jun
(17) |
Jul
(7) |
Aug
|
Sep
(3) |
Oct
(6) |
Nov
(3) |
Dec
|
| 2017 |
Jan
(5) |
Feb
(17) |
Mar
(4) |
Apr
(8) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(2) |
Sep
|
Oct
(5) |
Nov
(6) |
Dec
(4) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
(1) |
| 2019 |
Jan
|
Feb
|
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
|
Jul
|
Aug
(2) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
(13) |
Feb
(17) |
Mar
(8) |
Apr
(11) |
May
(15) |
Jun
(11) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2021 |
Jan
(9) |
Feb
(26) |
Mar
(17) |
Apr
|
May
(7) |
Jun
(18) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(10) |
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
| 2023 |
Jan
(10) |
Feb
|
Mar
(7) |
Apr
(8) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(11) |
Nov
(8) |
Dec
(5) |
| 2024 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(4) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Mark S. <m_s...@ma...> - 2012-07-15 07:57:51
|
Hi, Here is a simple form that I hope should set the text value of an XML node using a Javascript function. If this is happening it is not reflected in the ui. Am I doing something wrong? My scripting skills are not what they used to be, so I could easily have made a basic mistake in the js function. Best wishes Mark <?xml version="1.0" encoding="UTF-8"?> <?xml-stylesheet href="../xsltforms/xsltforms.xsl" type="text/xsl"?> <?xsltforms-options debug="no"?> <?css-conversion no?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:xf="http://www.w3.org/2002/xforms" xmlns:ev="http://www.w3.org/2001/xml-events"> <head> <title>Discover your Whithorn</title> <script type='text/javascript'> function onFeatureSelect(evt) { var modelElem = document.getElementById("theModel"); var instDoc = modelElem.getInstanceDocument("variables"); var xmlSite = instDoc.getElementsByTagName("currSite")[0]; xmlSite.childNodes[0].nodeValue = evt; alert(xmlSite.childNodes[0].nodeValue); modelElem.rebuild(); modelElem.recalculate(); modelElem.revalidate(); modelElem.refresh(); } </script> <xf:model id="theModel"> <xf:instance id="sites" xmlns=""> <sites> <featureMember> <site> <name>Cairn Buy</name> </site> </featureMember> <featureMember> <site> <name>'Hole Stone'</name> </site> </featureMember> </sites> </xf:instance> <xf:instance id="variables" xmlns=""> <doc> <currSite>Cairn Buy</currSite> </doc> </xf:instance> </xf:model> </head> <body> <h2>Sites</h2> <div> <p>Value of instance('variables')/currSite is: <strong><xf:output value="instance('variables')/currSite"/></strong></p> <xf:select1 ref="instance('variables')/currSite"> <xf:itemset nodeset="instance('sites')/featureMember/site"> <xf:label ref="name"/> <xf:value ref="name"/> </xf:itemset> </xf:select1> <p onclick="onFeatureSelect('Hole Stone')">Set value of instance('variables')/currSite to Hole Stone</p> <p onclick="onFeatureSelect('Cairn Buy')">Set value of instance('variables')/currSite to Cairn Buy</p> </div> </body> </html> |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-14 02:32:15
|
[Those not interested in interim or partial results relating to the problem
of running XSLT in a form can skip this message and wait for a
post mortem analysis later on, once the problem is finally resolved.]
On Jul 12, 2012, at 3:15 PM, C. M. Sperberg-McQueen wrote:
> In a form I'm working on, I'd like to apply a stylesheet located in a
> document instance (instance('filter') to an input document located in
> another instance (instance('userdoc')).
>
> It doesn't seem to be working, and I wonder if anyone here can see
> what I'm doing wrong.
>
> ...
>
> The form loads as expected and the function seems to be called
> without incident and without error messages (and alert messages
> confirm that the arguments look pretty much as I expect them to look).
> But the result is consistently not the output I expect from the stylesheet,
> but a document which reads in its entirety:
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml">
> <head><title></title></head>
> <body>
> <pre></pre>
> </body>
> </html>
Further data: This is what the output looks like in Safari and Chrome,
but in Firefox I get instead something like:
<?xml version="1.0" encoding="UTF-8"?>
<transformiix:result xmlns:transformiix="http://www.mozilla.org/TransforMiix"></transformiix:result>
More generally, all the browsers I've tested appear to force the output
of any XSLT transformation to XML (or HTML); if the stylesheet uses
xsl:output method="text", the output gets wrapped in something -- in the
case of Safari and Chrome, it gets wrapped in an HTML document with
a pre element, while in Firefox it gets wrapped in a transformiix:result
element. In Opera, the current version of my form doesn't work at all
yet, but a test case with some simple transforms shows that in Opera,
the output of a text-method XSLT stylesheet is wrapped in a 'result'
element (and preceded by an XML declaration).
So the result I was seeing with Safari (shown above) seems to indicate
that the transformation I was trying to run was producing no output.
>
> Anyone have a clue? Anyone have a better (or just different) way to go about
> this?
This continues to be a live question; if I get this working, I'll try to document
what I learned, in the hopes that it can help others.
Michael
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
|
|
From: Jeremy F. <jf...@te...> - 2012-07-13 21:50:49
|
The problem in IE9 was caused by having compatibility mode turned on. Unfortunately, this does not correct the problem in IE8. I'm not sure how to go about fixing the problem in the xsltforms.js as the issue appears to be with the appendChild method on a script element being generated in the XsltForms_load.prototype.run method for the show=embed.
var scriptelt = XsltForms_browser.isXhtml ? document.createElementNS("http://www.w3.org/1999/xhtml", "script") : document.createElement("script");
scriptelt.setAttribute("id", "xsltforms-subform-" + XsltForms_globals.nbsubforms + "-script");
scriptelt.setAttribute("type", "text/javascript");
var scripttxt = document.createTextNode(subjs);
scriptelt.appendChild(scripttxt);
I've updated locally xsltforms.js to now be what's shown below and IE8 is working, looking forward to using subforms now:
var scriptelt = XsltForms_browser.isXhtml ? document.createElementNS("http://www.w3.org/1999/xhtml", "script") : document.createElement("script");
scriptelt.setAttribute("id", "xsltforms-subform-" + XsltForms_globals.nbsubforms + "-script");
scriptelt.setAttribute("type", "text/javascript");
if (window.addEventListener) {
/* Firefox, Chrome, IE9 */
scriptelt.appendChild(document.createTextNode(subjs))
} else {
/* IE8 */
scriptelt.text = subjs;
}
If anybody sees an issue with this approach, please let me know as I'm really just trying to get to the point of testing performance to determine if we have to move in a new direction or whether subforms is our answer.
Thanks,
Jeremy
From: Alain Couthures [mailto:ala...@ag...]
Sent: Friday, July 13, 2012 1:12 PM
To: Jeremy Frier
Cc: xsl...@li...
Subject: Re: [Xsltforms-support] IE9 subforms access error
Hello Jeremy,
I am trying to upgrade our beta3 forms to 1.0 RC and implement subforms on one of our existing forms. In firefox, this is working without a problem. The sample writers.xml works fine in both firefox and IE9. The difference between our application and the writers sample is that we are bundling our forms through a tomcat server via a servlet that does some preprocessing of the xml. In the end, the xml that is passed to xsltforms is essentially the same. The big difference is in our xf:load which is:
<xf:load show="embed" targetid="generalSubForm" resource="FormLaunch?form=GeneralForm"/>
In debugging our webapp, the resource reference to the FormLaunch servlet works as expected. In IE9, the server never receives the request.
In IE9, the profiler reports the following trace:
19262 -> Load FormLaunch?form=GeneralForm
48 -> Unexpected call to method or property access.
4 -> Dispatching event xforms-link-exception on <DIV class=" xforms-group" id="generalSubForm"/>
309 -> insert bftr_expce in bftrs_expcs at 0 - Data
0 -> Dispatching event xforms-insert on <SPAN class="xforms-instance" id="main"/>
1 -> insert loc_origin in locations at 0 - Data
0 -> Dispatching event xforms-insert on <SPAN class="xforms-instance" id="main"/>
I went ahead and pulled in the writers.xml and replaced all of our form and subform with the writers.xml and the books.xml and experienced the same method or property access error using with the servlet resource reference.
I'm unclear as to where the unexpected call to method or property access is happening in the xsltforms.js, will continue to look, but wonder if somebody can point me in the right direction.
The IE9 debugger can help you to precisely locate this unexpected call (you should first set a breakpoint at line #4173).
Thank you for your feedbacks!
-Alain
|
|
From: Alain C. <ala...@ag...> - 2012-07-13 19:12:41
|
Hello Jeremy, > > I am trying to upgrade our beta3 forms to 1.0 RC and implement > subforms on one of our existing forms. In firefox, this is working > without a problem. The sample writers.xml works fine in both firefox > and IE9. The difference between our application and the writers > sample is that we are bundling our forms through a tomcat server via a > servlet that does some preprocessing of the xml. In the end, the xml > that is passed to xsltforms is essentially the same. The big > difference is in our xf:load which is: > > <xf:load show="embed" targetid="generalSubForm" > resource="FormLaunch?form=GeneralForm"/> > > In debugging our webapp, the resource reference to the FormLaunch > servlet works as expected. In IE9, the server never receives the request. > > In IE9, the profiler reports the following trace: > > 19262 -> Load FormLaunch?form=GeneralForm > > 48 -> Unexpected call to method or property access. > > 4 -> Dispatching event xforms-link-exception on <DIV class=" > xforms-group" id="generalSubForm"/> > > 309 -> insert bftr_expce in bftrs_expcs at 0 - Data > > 0 -> Dispatching event xforms-insert on <SPAN class="xforms-instance" > id="main"/> > > 1 -> insert loc_origin in locations at 0 - Data > > 0 -> Dispatching event xforms-insert on <SPAN class="xforms-instance" > id="main"/> > > I went ahead and pulled in the writers.xml and replaced all of our > form and subform with the writers.xml and the books.xml and > experienced the same method or property access error using with the > servlet resource reference. > > I'm unclear as to where the unexpected call to method or property > access is happening in the xsltforms.js, will continue to look, but > wonder if somebody can point me in the right direction. > The IE9 debugger can help you to precisely locate this unexpected call (you should first set a breakpoint at line #4173). Thank you for your feedbacks! -Alain |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-12 21:16:01
|
In a form I'm working on, I'd like to apply a stylesheet located in a
document instance (instance('filter') to an input document located in
another instance (instance('userdoc')).
It doesn't seem to be working, and I wonder if anyone here can see
what I'm doing wrong.
I've studied the code for the existing transform() function, which accepts
a node set and a URI and then calls XsltForms_browser.transformText
with that same node set, that same URI, and a flag to signal that the
second argument is a URI and not a literal string containing an angle-bracket
encoding of a stylesheet.
If I understand the code for the underlying transformText function
correctly (not guaranteed!), it can accept either a URI or a stylesheet
in string form in its second argument, and its third argument tells the
system which case applies.
- If the third argument is true, the second argument is passed to
a parser and a DOM object is returned.
- If the third argument is false, the second argument is used to
load an external document, and the resulting DOM is returned.
(At least, I assume the results are DOM objects.)
Other calls to transformText() seem to use strings successfully in
the second argument.
So I wrote an extension function that looks like this:
function bmt_applyxslt_ns_s(nsXML, sXSLT) {
if (arguments.length !== 2) {
throw XsltForms_xpathFunctionExceptions.transformInvalidArgumentsNumber;
}
return nsXML.length === 0? "" : XsltForms_browser.transformText(XsltForms_browser.saveXML(nsXML[0]), sXSLT, true);
}
This is almost verbatim the same as the source code for transform(),
except for the argument names and 'true' instead of 'false' in the
third argument. (I notice now that I ought to change the name of
the exception, perhaps, too.)
I register the function with XSLTforms in the usual way.
<xf:setvalue
ref="instance('userout')/self::data"
value="bmt:s_applyxslt_ns_s(instance('userdoc'), serialize(instance('filter')))"/>
The form loads as expected and the function seems to be called
without incident and without error messages (and alert messages
confirm that the arguments look pretty much as I expect them to look).
But the result is consistently not the output I expect from the stylesheet,
but a document which reads in its entirety:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml">
<head><title></title></head>
<body>
<pre></pre>
</body>
</html>
Anyone have a clue? Anyone have a better (or just different) way to go about
this?
Thanks!
Michael Sperberg-McQueen
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
|
|
From: Jens Ø. P. <oe...@gm...> - 2012-07-11 08:43:31
|
Hello Michael,
Thank you for laying out the law!
Both your rewritings work fine. I wonder which one is the fastest?
Regards,
Jens
On Jul 10, 2012, at 9:55 PM, C. M. Sperberg-McQueen wrote:
>
> On Jul 10, 2012, at 5:01 AM, Alain Couthures wrote:
>
>> Hello Jens,
>>> I have groups for hiding/displaying a set of buttons for inserting missing elements and attributes. They are at times monstrously long, such as,
>>>
>>> <xf:group class="show-hide" ref=".[not(@altRepGroup)] | .[not(@authority)] | .[not(@authorityURI)] | .[not(@displayLabel)] | .[not(@ID)] | .[not(@lang)] | .[not(@nameTitleGroup)] | .[not(mods:nonSort)] | .[not(mods:partName)] | .[not(mods:partNumber)] | .[not(@script)] | .[not(mods:subTitle)] | .[not(@supplied)] | .[not(mods:title)] | .[not(@transliteration)] | .[not(@type)] | .[not(@usage)] | .[not(@valueURI)] | .[not(@xml:lang)] | .[not(@xlink:href)]">
>> First, I would try to minimize such expressions like this, if there is
>> one char that should not appear in values:
>> .[not(contains(concat('~',@altRepGroup,'~',@authority,'~',@authorityURI,'~',@displayLabel,'~',@ID,'~',@lang,'~',@nameTitleGroup,'~',.....,'~'),'~~'))]
>
> For the case where we don't have any guarantees about the values
> (so concatenating with '~' or any other magic character is not safe), I
> wonder (just thinking out loud here) if applying DeMorgan's Law to
> produce a simpler expression would help:
>
> ref=".[not(@altRepGroup and @authority and @authorityURI and ...
> ... and @xlink:href)]"
>
<xf:group class="show-hide" ref=".[not(mods:partName and mods:partNumber and @script and mods:subTitle and @supplied and mods:title and @transliteration and @type and @usage and @valueURI and @xml:lang and @xlink:href)]">
> Or even (if your list is all the attributes that are possible, which is
> alas probably not the case)
>
> ref=".[count(@*) < 20]"
>
> Not tested.
<xf:group class="show-hide" ref=".[count(@*) < 8 or count(*) < 5]">
>
> Michael
>
> --
> ****************************************************************
> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC
> * http://www.blackmesatech.com
> * http://cmsmcq.com/mib
> * http://balisage.net
> ****************************************************************
>
>
>
>
|
|
From: Jens Ø. P. <oe...@gm...> - 2012-07-11 07:55:28
|
Hi,
Are there advantages of using ccs syntax like
xf|label {font-weight: bold;}
over
.xforms-label {font-weight: bold;}
?
What, in fact, makes it possible to use the former syntax, i.e. at which stage in the process from form to web page are such rules applied?
Best,
Jens
|
|
From: Stephen C. <ste...@gm...> - 2012-07-11 03:17:53
|
This is something I've used
<xf:submission id="generate_xforms"
ref="instance('built_schema')" replace="none"
method="post"> <xf:resource
value="concat('generate?schema=',instance('schema')/s2x:schema)"/>
<xf:load ev:event="xforms-submit-done" show="new">
<xf:resource value="concat('xform/',substring-before(instance('schema')/s2x:schema,'.'),'/index.html')"/>
</xf:load> </xf:submission>
On Wed, Jul 11, 2012 at 12:44 PM, C. M. Sperberg-McQueen <
cm...@bl...> wrote:
> From time to time I find myself wishing I could submit an
> instance to the server and have the result returned by
> the server opened in a new window. This appears to be
> a kind of cross between a submit and a load -- but the
> only way I can see to achieve this is to pass the instance
> data long as query parameters on a GET request, which
> doesn't work very well for non-trivial instances.
>
> Is there a way to achieve this behavior, or am I wishing
> for the impossible?
>
> --
> ****************************************************************
> * C. M. Sperberg-McQueen, Black Mesa Technologies LLC
> * http://www.blackmesatech.com
> * http://cmsmcq.com/mib
> * http://balisage.net
> ****************************************************************
>
>
>
>
>
>
|
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-11 00:54:30
|
On Oct 11, 2011, at 3:14 PM, Alain Couthures wrote: > Hello Morgan, > >> 1. My general question is: can you point me to any examples that make use of the XSLTForms transform function? >> >> The only one I have been able to find is the one provided by Alain at: >> >> http://www.agencexml.com/svgopen/graphs.xml > Sorry, I have no other example yet. I'm writing a form which enables to load an XSLT stylesheet from a local file into an instance, then to apply it to another instance and, finally, to save the result locally. Any news on this facility? It sounds like just what I had in mind for a form I'm working on this afternoon. > > The W3C Forms Working Group has not yet agreed on how the transform function should be in XForms 2.0. If that's still true, then here are some desiderata from a potential user (off the top of my head and not terribly well thought through): I think that in an ideal world the form author could: 1 load a stylesheet into an instance (good! we can do that now, so we're already part way home!) <xf:instance src="foo.xsl"/> 2 apply a specified stylesheet to specified input and direct the output to a given location; in practice some limitations may be unavoidable, but ideally I'd like 2a to specify the stylesheet either with a static URI, or with a dynamic URI, or by referring to an instance in the model 2b to specify the input to the stylesheet by URI or by pointing into the model 2c to load the result either into a string variable or into an instance (either augmenting or replacing the instance) It's not currently clear to me how much of this is already possible using the existing transform() function. I guess I can accomplish some of what I'm looking for by using submit to bounce the data to the server and have it perform the transformation, but I do not know a way to have the server evaluate a stylesheet in an instance without a wider security hole than I am comfortable with. Using Javascript to perform transforms in the browser (along the lines described for the Mozilla XForms plugin at http://en.wikibooks.org/wiki/XForms/Sorting_using_XSLT) would not be ideal, but it would be Better Than Nothing. Further information (on the existing transform() function, on ways to achieve what I want on the server, or on the current state of discussion of transformation in the XForms WG) would be welcome. Thank you very much! -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
From: Stephen C. <ste...@gm...> - 2012-07-10 23:53:04
|
*Originally the recommendation was to put the links to stylesheets into the config.xsl file inside the <extensions> tag. This was so that they would be inserted after the xsltforms.css. I had to go back to that system to use v549 as the <link> inside the Xform seemed to be dropped completely by xsltforms.xsl. * On Wed, Jul 11, 2012 at 7:32 AM, C. M. Sperberg-McQueen < cm...@bl...> wrote: > The other day I asked about possible changes in the way XSLTForms > deals with external CSS documents. > > Mindful of Alain's recent comment that it's always easier to deal with > questions if there are small test cases, I've generated a set of small > sample documents which differ in using different versions of XSLTForms > (beta3RC, beta3, 1.0RC, or rev549) and in embedding different external > stylesheets (test.css, which turns the background light green, or > test.css.xml, which is wrapped in an XML element and which turns the > background light blue). > > The test.css.xml stylesheet, that is, follows the convention described > in the XRX wikibook at [1]; the test.css is just a normal CSS file. > > XSLTForms versions beta3, beta3RC, and 1.0RC all behave the > same way the browser behaves if XSLTForms is not involved at all: > the test.css stylesheet is consulted and turns the background green, > and the test.css.xml stylesheet has no effect. (This surprises me, > because it contradicts what I thought I remembered; I thought that > at least one of the older releases worked with either convention.) > > Rev. 549, by contrast, successfully consults test.css.xml, but > does not successfully consult test.css. > > For now, I think I can get the effect I want. But I do wonder: is this > change of behavior intended, or a bug? > > The test files I have generated are visible at > > http://blackmesatech.com/2012/07/testcase/ > > I have checked the results with reasonably current versions of > Safari, Firefox, Opera, and Chrome running under Mac OS X. > > Michael Sperberg-McQueen > > [1] > http://en.wikibooks.org/wiki/XRX/XSLTForms_and_eXist#Modifying_your_CSS_to_work_with_XSLTForms > -- > **************************************************************** > * C. M. Sperberg-McQueen, Black Mesa Technologies LLC > * http://www.blackmesatech.com > * http://cmsmcq.com/mib > * http://balisage.net > **************************************************************** > > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > |
|
From: Stephen C. <ste...@gm...> - 2012-07-10 23:44:55
|
This was mainly an issue in Chrome, which confused us initially. On Tue, Jul 10, 2012 at 10:11 PM, Ihe Onwuka <ihe...@go...>wrote: > Thanks to some sterling persistent assistance from Steve Cameron, we > have isolated the cause of the terrible performance of my XFORM > (taking about 4 minutes to load). > > I was referencing wildcarded namespaces as in *:element in instance() > and Xpath commands because I wanted to process elements irrespective > of the namespace they were in (and I still would like to do that). > > Steve persuaded me to try the XForm by specifying the namespace (there > is only one but I want the code to be namespace independent) and the > load time came down to about 20 secs which is quite tolerable. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support > |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-10 21:32:28
|
The other day I asked about possible changes in the way XSLTForms deals with external CSS documents. Mindful of Alain's recent comment that it's always easier to deal with questions if there are small test cases, I've generated a set of small sample documents which differ in using different versions of XSLTForms (beta3RC, beta3, 1.0RC, or rev549) and in embedding different external stylesheets (test.css, which turns the background light green, or test.css.xml, which is wrapped in an XML element and which turns the background light blue). The test.css.xml stylesheet, that is, follows the convention described in the XRX wikibook at [1]; the test.css is just a normal CSS file. XSLTForms versions beta3, beta3RC, and 1.0RC all behave the same way the browser behaves if XSLTForms is not involved at all: the test.css stylesheet is consulted and turns the background green, and the test.css.xml stylesheet has no effect. (This surprises me, because it contradicts what I thought I remembered; I thought that at least one of the older releases worked with either convention.) Rev. 549, by contrast, successfully consults test.css.xml, but does not successfully consult test.css. For now, I think I can get the effect I want. But I do wonder: is this change of behavior intended, or a bug? The test files I have generated are visible at http://blackmesatech.com/2012/07/testcase/ I have checked the results with reasonably current versions of Safari, Firefox, Opera, and Chrome running under Mac OS X. Michael Sperberg-McQueen [1] http://en.wikibooks.org/wiki/XRX/XSLTForms_and_eXist#Modifying_your_CSS_to_work_with_XSLTForms -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-10 19:55:30
|
On Jul 10, 2012, at 5:01 AM, Alain Couthures wrote:
> Hello Jens,
>> I have groups for hiding/displaying a set of buttons for inserting missing elements and attributes. They are at times monstrously long, such as,
>>
>> <xf:group class="show-hide" ref=".[not(@altRepGroup)] | .[not(@authority)] | .[not(@authorityURI)] | .[not(@displayLabel)] | .[not(@ID)] | .[not(@lang)] | .[not(@nameTitleGroup)] | .[not(mods:nonSort)] | .[not(mods:partName)] | .[not(mods:partNumber)] | .[not(@script)] | .[not(mods:subTitle)] | .[not(@supplied)] | .[not(mods:title)] | .[not(@transliteration)] | .[not(@type)] | .[not(@usage)] | .[not(@valueURI)] | .[not(@xml:lang)] | .[not(@xlink:href)]">
> First, I would try to minimize such expressions like this, if there is
> one char that should not appear in values:
> .[not(contains(concat('~',@altRepGroup,'~',@authority,'~',@authorityURI,'~',@displayLabel,'~',@ID,'~',@lang,'~',@nameTitleGroup,'~',.....,'~'),'~~'))]
For the case where we don't have any guarantees about the values
(so concatenating with '~' or any other magic character is not safe), I
wonder (just thinking out loud here) if applying DeMorgan's Law to
produce a simpler expression would help:
ref=".[not(@altRepGroup and @authority and @authorityURI and ...
... and @xlink:href)]"
Or even (if your list is all the attributes that are possible, which is
alas probably not the case)
ref=".[count(@*) < 20]"
Not tested.
Michael
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
|
|
From: Alain C. <ala...@ag...> - 2012-07-10 19:12:22
|
Le 10/07/2012 15:32, Jens Østergaard Petersen a écrit :
> The change came with 547.
>
> I will see if I can extricate a tiny test case from my mass of xquery.
OK
>
> Trying to make one, I noticed that Firefox (up-to-date version on up-to-date OS X) treats the attached mods.2.xml file wrongly and Chrome treats it correctly, whereas mods1.xml is treated correctly by both. The way the namespaces are set makes the difference.
>
> This does not illustrate my original problem, however, and has nothing to do with 547.
It's the namespace:: axis support issue in Firefox. The known workaround
is to add, preferably at the document element, a dummy attribute such as
mods:dummy="dummy".
> The idea (which works before 547) is that if one of the named nodes is
> missing, a panel should show up; this contains a number of buttons for
> inserting missing nodes, each of which is displayed, by its own
> xf:group, if its node is not present in the instance. If I understand
> you correctly, you are checking the values of the elements and
> attributes listed. You will catch if there is an empty value (which
> will bring a '~~'). I am checking if the instance has nodes with the
> listed names as child elements or attributes of the context node. I
> will catch a missing node. I could condense my "or" expression if I
> could use not(name(.) = ('a','b','c')).
XSLTForms doesn't support XPath 2.0 yet ;-)
Checking empty values vs. missing nodes is, of course, not exactly the
same, depending on the context but missing nodes produce empty values in
XPath 1.0!
Thanks!
-Alain
|
|
From: Jens Ø. P. <oe...@gm...> - 2012-07-10 13:32:49
|
Thanks, Alain, The change came with 547. I will see if I can extricate a tiny test case from my mass of xquery. Trying to make one, I noticed that Firefox (up-to-date version on up-to-date OS X) treats the attached mods.2.xml file wrongly and Chrome treats it correctly, whereas mods1.xml is treated correctly by both. The way the namespaces are set makes the difference. This does not illustrate my original problem, however, and has nothing to do with 547. Cheers, Jens |
|
From: Ihe O. <ihe...@go...> - 2012-07-10 12:11:32
|
Thanks to some sterling persistent assistance from Steve Cameron, we have isolated the cause of the terrible performance of my XFORM (taking about 4 minutes to load). I was referencing wildcarded namespaces as in *:element in instance() and Xpath commands because I wanted to process elements irrespective of the namespace they were in (and I still would like to do that). Steve persuaded me to try the XForm by specifying the namespace (there is only one but I want the code to be namespace independent) and the load time came down to about 20 secs which is quite tolerable. |
|
From: Alain C. <ala...@ag...> - 2012-07-10 11:02:28
|
Hello Jens,
> I have groups for hiding/displaying a set of buttons for inserting missing elements and attributes. They are at times monstrously long, such as,
>
> <xf:group class="show-hide" ref=".[not(@altRepGroup)] | .[not(@authority)] | .[not(@authorityURI)] | .[not(@displayLabel)] | .[not(@ID)] | .[not(@lang)] | .[not(@nameTitleGroup)] | .[not(mods:nonSort)] | .[not(mods:partName)] | .[not(mods:partNumber)] | .[not(@script)] | .[not(mods:subTitle)] | .[not(@supplied)] | .[not(mods:title)] | .[not(@transliteration)] | .[not(@type)] | .[not(@usage)] | .[not(@valueURI)] | .[not(@xml:lang)] | .[not(@xlink:href)]">
First, I would try to minimize such expressions like this, if there is
one char that should not appear in values:
.[not(contains(concat('~',@altRepGroup,'~',@authority,'~',@authorityURI,'~',@displayLabel,'~',@ID,'~',@lang,'~',@nameTitleGroup,'~',.....,'~'),'~~'))]
>
> My problem is that this works with fine with xsltforms-1.0RC, but not with revisions 547-549 (the only revisions I have tested).
In fact, many features and optimizations have been added since
xsltforms-1.0RC and a new release candidate version should be published
soon.
>
> This has nothing to do with the namespaced attributes. It has nothing to do with elements versus attributes. Length also does not have anything to do with it.
Usually to fix bugs, the tiniest test case is the best way to locate the
issue. Can you please send me one?
>
> By the way: what would be the version number of xsltforms-1.0RC (so I can test when the behaviour changed)?
xsltforms.js, line 45: fileVersionNumber: 535,
Thanks!
-Alain
|
|
From: Jens Ø. P. <oe...@gm...> - 2012-07-10 10:11:49
|
Hello, I have groups for hiding/displaying a set of buttons for inserting missing elements and attributes. They are at times monstrously long, such as, <xf:group class="show-hide" ref=".[not(@altRepGroup)] | .[not(@authority)] | .[not(@authorityURI)] | .[not(@displayLabel)] | .[not(@ID)] | .[not(@lang)] | .[not(@nameTitleGroup)] | .[not(mods:nonSort)] | .[not(mods:partName)] | .[not(mods:partNumber)] | .[not(@script)] | .[not(mods:subTitle)] | .[not(@supplied)] | .[not(mods:title)] | .[not(@transliteration)] | .[not(@type)] | .[not(@usage)] | .[not(@valueURI)] | .[not(@xml:lang)] | .[not(@xlink:href)]"> My problem is that this works with fine with xsltforms-1.0RC, but not with revisions 547-549 (the only revisions I have tested). This has nothing to do with the namespaced attributes. It has nothing to do with elements versus attributes. Length also does not have anything to do with it. By the way: what would be the version number of xsltforms-1.0RC (so I can test when the behaviour changed)? Best, Jens On Jul 4, 2012, at 9:54 PM, Alain Couthures wrote: > Hello, > > I have just fixed a big performance issue due to XML namespace being > used in XPath expression (for example, in @xml:lang). > > It was strongly slowing the transformation step (more than twelve > seconds in a rather simple test form!). > > BTW, the namespace:: axis is not yet supported by Mozilla XSLT engine... > > Thank you for your feedbacks! > > -Alain > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-08 19:33:02
|
On Jul 8, 2012, at 12:11 PM, C. M. Sperberg-McQueen wrote: > ... > Is there anything needed to ensure the applet loads correctly > other than (1) making sure xsltforms.jar is in the same directory > on the server as xsltforms.xsl and xsltforms.js? and (2) making > sure the user has not configured the browser to refuse to load > Java applets? Further on this: it turns out that on OS X, it was harder than I expected to satisfy condition (2). The 'Enable java' checkbox in the Safari Preferences dialog did not suffice; I had to install the Java 6 plugin (which I was prompted to do by clicking on the words 'inactive plugin' displayed over the web page). A similar sequence of actions was needed for Chrome, Firefox, and Opera. Once I had installed the Java plugin in each of my browsers, and restarted them both Alain's test case (now on my server at http://blackmesatech.com/2012/07/dh/applet-test.xml) and Andre Cusson's StratML editor (at http://www.hyperbase.com/library/hyperform/stratml/asset/xml/4psc.xml) began to behave as expected. That is, the buttons that connect to file: URIs open a file dialog box. (It was mystifying when it didn't work, partly because -- as others have also reported -- the browsers' error messages are not very helpful in making clear to the user what is going on.) Sorry for the false alarm! -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-08 18:11:22
|
On Jul 7, 2012, at 8:06 PM, Andre Cusson wrote: > Hi C.M., > > I am not sure that this can help, but, thanks to Alain, for reading,since you get the file dialog anyway, you would not specify the file on submission, so I use: > > <xf:submission id="load"method="get"serialization="none"replace="instance"action="file:// <view-source:file:///>"> > <xf:message level="modeless"ev:event="xforms-submit-error">Submit error.</xf:message> > </xf:submission> > > > And the button is > > <xf:submit submission="load"> > <xf:label>Load</xf:label> > </xf:submit> Thank you; concrete examples are almost always helpful. When I try to use this code in a test form, however, I get messages saying "document.applets.xsltforms.readFile is not a function" (Firefox, Opera) or "Object #<HTMLAppletElement> has no method 'readFile'" (Chrome). Perhaps this means I need to do something on my server to ensure that the applet is loaded correctly? Or perhaps not: I get the same messages when I press the Load button in page http://www.hyperbase.com/library/hyperform/stratml/asset/xml/4psc.xml which I assume is correctly configured. Is there anything needed to ensure the applet loads correctly other than (1) making sure xsltforms.jar is in the same directory on the server as xsltforms.xsl and xsltforms.js? and (2) making sure the user has not configured the browser to refuse to load Java applets? -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
From: Andre C. <ac...@01...> - 2012-07-08 03:06:07
|
Hi C.M., I am not sure that this can help, but, thanks to Alain, for reading,since you get the file dialog anyway, you would not specify the file on submission, so I use: <xf:submission id="load"method="get"serialization="none"replace="instance"action="file:// <view-source:file:///>"> <xf:message level="modeless"ev:event="xforms-submit-error">Submit error.</xf:message> </xf:submission> And the button is <xf:submit submission="load"> <xf:label>Load</xf:label> </xf:submit> ac > On Jul 7, 2012, at 1:19 PM, Alain Couthures wrote: >>> >>> Is there any convenient way to get an XML document that >>> initially resides on the user's hard disk into an XForms >>> instance, so the form can look at it and customize itself >>> accordingly? Or is that impossible? >> Yes, you can use a submission at "file://" for reading and writing local >> files. For security reasons, you will always get a File dialog > This sounds excellent, but I'm having a little trouble understanding > how it works in detail. Are there any examples readily available? > (Is this in rev. 549?) > > Having written that, I paused and told myself I should try to work > it out for myself. When I write two submissions of the form > > <xforms:submission id="read" > method="get" > resource="file:///Users/cmsmcq/2012/misc/test.xml" > replace="instance" > instance="file"/> > > > > and > > <xforms:submission id="save" > method="put" > resource="file:///Users/cmsmcq/2012/misc/puttest.xml"/> > > and provide Read and Save buttons of the form > > <xforms:submit submission="read"> > <xforms:label>Read</xforms:label> > </xforms:submit> > <xforms:submit submission="save"> > <xforms:label>Save</xforms:label> > </xforms:submit> > > then should I get a File dialog for reading or saving, when I click > those buttons? I don't; the Loading ... message flashes very > quickly, and the trace log gets two lines saying > > 0 -> Dispatching event xforms-submit on <SPAN class="xforms-submission" id="read"/> > 1 -> Dispatching event xforms-submit-error on <SPAN class="xforms-submission" id="read"/> > > The document text.xml is not loaded into the 'file' instance. > > So I'm clearly doing something wrong here; I'll continue to play > with this, but if any reader of this list can see where I'm going wrong, > I'll be grateful for a hint. > > >> (I could >> allow a direct access to local files when no distant HTTP server is >> used, what do you think?). > "How can I use XForms on a local system without having to set > up an HTTP server or install eXist or something?" is definitely > a question I get often. So yes, if you have found a way to make > it work, I think it could be useful for many people who are first > starting with XForms. > >>> ... >>> If xf:upload were able to populate an instance (or an element >>> in an instance) with an uploaded document, that would (I >>> think) do what I think I need. But if I read the 1.1 spec correctly, >>> xf:upload data cannot be parsed XML data, only base64Binary >>> and so on. >> Yes, xf:upload is just for content. > One workaround I have found seems to work for loading user-supplied > XML documents into the instance. I record it here in case > anyone else finds it handy and hasn't already thought of it: > > I upload the base64 data to a script on the server which performs > a base64 decoding and sends the file back to the client as > text/xml. The submission specifies replace="instance", so the > XML document specified by the user is loaded into a specified > XForms instance, where the form can work with it. > > A simple example is at > > http://blackmesatech.com/2012/06/testcase/upload-into-instance.xhtml > > (The example works in Firefox, Chrome, and Opera. For reasons I > have not yet uncovered, xf:upload does not seem to work for me > in Safari 5.1.7 at all. The trace shows events xforms-submit, > xforms-submit-serialize, and xforms-submit-error, but I have not > yet figured out what is going wrong.) > > |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-07 23:26:47
|
On Jul 7, 2012, at 1:19 PM, Alain Couthures wrote:
>>
>>
>> Is there any convenient way to get an XML document that
>> initially resides on the user's hard disk into an XForms
>> instance, so the form can look at it and customize itself
>> accordingly? Or is that impossible?
> Yes, you can use a submission at "file://" for reading and writing local
> files. For security reasons, you will always get a File dialog
This sounds excellent, but I'm having a little trouble understanding
how it works in detail. Are there any examples readily available?
(Is this in rev. 549?)
Having written that, I paused and told myself I should try to work
it out for myself. When I write two submissions of the form
<xforms:submission id="read"
method="get"
resource="file:///Users/cmsmcq/2012/misc/test.xml"
replace="instance"
instance="file"/>
>
and
<xforms:submission id="save"
method="put"
resource="file:///Users/cmsmcq/2012/misc/puttest.xml"/>
and provide Read and Save buttons of the form
<xforms:submit submission="read">
<xforms:label>Read</xforms:label>
</xforms:submit>
<xforms:submit submission="save">
<xforms:label>Save</xforms:label>
</xforms:submit>
then should I get a File dialog for reading or saving, when I click
those buttons? I don't; the Loading ... message flashes very
quickly, and the trace log gets two lines saying
0 -> Dispatching event xforms-submit on <SPAN class="xforms-submission" id="read"/>
1 -> Dispatching event xforms-submit-error on <SPAN class="xforms-submission" id="read"/>
The document text.xml is not loaded into the 'file' instance.
So I'm clearly doing something wrong here; I'll continue to play
with this, but if any reader of this list can see where I'm going wrong,
I'll be grateful for a hint.
> (I could
> allow a direct access to local files when no distant HTTP server is
> used, what do you think?).
"How can I use XForms on a local system without having to set
up an HTTP server or install eXist or something?" is definitely
a question I get often. So yes, if you have found a way to make
it work, I think it could be useful for many people who are first
starting with XForms.
>> ...
>> If xf:upload were able to populate an instance (or an element
>> in an instance) with an uploaded document, that would (I
>> think) do what I think I need. But if I read the 1.1 spec correctly,
>> xf:upload data cannot be parsed XML data, only base64Binary
>> and so on.
> Yes, xf:upload is just for content.
One workaround I have found seems to work for loading user-supplied
XML documents into the instance. I record it here in case
anyone else finds it handy and hasn't already thought of it:
I upload the base64 data to a script on the server which performs
a base64 decoding and sends the file back to the client as
text/xml. The submission specifies replace="instance", so the
XML document specified by the user is loaded into a specified
XForms instance, where the form can work with it.
A simple example is at
http://blackmesatech.com/2012/06/testcase/upload-into-instance.xhtml
(The example works in Firefox, Chrome, and Opera. For reasons I
have not yet uncovered, xf:upload does not seem to work for me
in Safari 5.1.7 at all. The trace shows events xforms-submit,
xforms-submit-serialize, and xforms-submit-error, but I have not
yet figured out what is going wrong.)
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
|
|
From: Alain C. <ala...@ag...> - 2012-07-07 19:19:49
|
Hello Michael, > A rather general question has come up. A friend has asked > for a form that asks the user some questions based on the content > of an XML document to be supplied by the user. > > Is there any convenient way to get an XML document that > initially resides on the user's hard disk into an XForms > instance, so the form can look at it and customize itself > accordingly? Or is that impossible? Yes, you can use a submission at "file://" for reading and writing local files. For security reasons, you will always get a File dialog (I could allow a direct access to local files when no distant HTTP server is used, what do you think?). I have already designed some basic XML editor with this. > > If xf:upload were able to populate an instance (or an element > in an instance) with an uploaded document, that would (I > think) do what I think I need. But if I read the 1.1 spec correctly, > xf:upload data cannot be parsed XML data, only base64Binary > and so on. Yes, xf:upload is just for content. > > I'd be happy to provide a text widget and have the user copy > the file and paste it in, if there were a way to get the parsed XML > structure back out, but that has not worked for me in the past. > (On the other hand, I think that that is, more or less, how the > TinyMCE widget works, so it might be technically feasible.) A textarea control could be used and a schema type could activated this. It could then be possible to validate the content when it is well-formed. Validating it according to a schema would be more complex for XSLTForms... > > Does anyone here have relevant experience or advice? Another possibility would be to define and use some parse() function (the W3C Work Group has not yet decided what to specify)... The problem is to know if the resulting XML document would be effective as some automatically generated instance or if it would just exist during an action processing. Thank you for your comments and suggestions! -Alain |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-07 15:33:20
|
When I use XSLTforms 1.0RC, I get the behavior I'm used to with respect to the handling of external CSS stylesheets. (Specifically, I mean CSS stylesheets that are not wrapped in XML elements but are normal CSS.) That is, the style rules in them appear to affect the display of the document. When I use rev. 546, or (after updating) 549, such 'normal' CSS stylesheets no longer have an effect. If I point the stylesheet instead to a doctored form of the stylesheet wrapped in an XML element, it appears to work again. Is this a bug or has the policy of XSLTForms changed to say that all external stylesheets must be XML documents, not only those stylesheets that need pre-processing by XSLTForms? -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
|
From: C. M. Sperberg-M. <cm...@bl...> - 2012-07-06 23:03:02
|
A rather general question has come up. A friend has asked for a form that asks the user some questions based on the content of an XML document to be supplied by the user. Is there any convenient way to get an XML document that initially resides on the user's hard disk into an XForms instance, so the form can look at it and customize itself accordingly? Or is that impossible? If xf:upload were able to populate an instance (or an element in an instance) with an uploaded document, that would (I think) do what I think I need. But if I read the 1.1 spec correctly, xf:upload data cannot be parsed XML data, only base64Binary and so on. I'd be happy to provide a text widget and have the user copy the file and paste it in, if there were a way to get the parsed XML structure back out, but that has not worked for me in the past. (On the other hand, I think that that is, more or less, how the TinyMCE widget works, so it might be technically feasible.) Does anyone here have relevant experience or advice? Thanks! Michael -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net **************************************************************** |
97 messages has been excluded from this view by a project administrator.
