xsltforms-support Mailing List for XSLTForms (Page 93)
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: Stephen C. <Ste...@ut...> - 2010-03-12 13:48:47
|
Looking at the js code I see that there is a regex pattern used to check formatting which is usually valid so the user input is not "wrong" and (visually flagged as such) then a parsing and a formatting step. I imagine the parsing is breaking the date string down and then building a Date value and this is where the behaviour might be wrong in that a new date is built and formatted but which may be different to what the user entered without him/her realising that this has occurred. They just see that it apparently valid and move on without checking the final result. I think that a different strategy where the individual parts of the date string are validated and then if all (years, months, days, hrs, minutes, seconds) are OK the whole date string can be checked as a valid javascript Date and then formatted. I'll look into this further but would appreciate if someone with more XSLTForms insight could take a look. -- Regards Stephen Cameron Data Programmer Integrated Marine Observing System (IMOS) eMarine Information Infrastructure Project University of Tasmania, Private Bag 21, Hobart, TAS 7001, Australia Tel: +61 3 6226 8507 Fax: +61 3 6226 2997 Email: ste...@ut... URL: http://www.imos.org.au/eMII.html |
|
From: Stephen C. <Ste...@ut...> - 2010-03-12 12:32:23
|
I am having problems with date validation in XSLTForms. Basically validation is non-functional for me in that it is too smart and changes the user entered date to be rubbish sometimes. I like the "AnyTime" calendar widget at http://www.ama3.com/anytime/#AnyTime.widget.placement but it is dependant on jquery which does not seem to be compatible with XSLTforms. Has anyone else looked into this general problem or tried other widgets with XSLTforms. Perhaps just to change the validation routine as a first step. Thanks -- Regards Stephen Cameron Data Programmer Integrated Marine Observing System (IMOS) eMarine Information Infrastructure Project University of Tasmania, Private Bag 21, Hobart, TAS 7001, Australia Tel: +61 3 6226 8507 Fax: +61 3 6226 2997 Email: ste...@ut... URL: http://www.imos.org.au/eMII.html |
|
From: Claudius T. <cla...@ya...> - 2010-03-11 19:06:35
|
Leigh, be sure that I will analyze those implementations. I really don't want to reinvent the wheel, so that my work counts less than the usability of its result. I am open to any suggestions and opinions and I want that this integration to be well done. So, I shall remove those buttons (my first approach, non-standard :) ), and add some XForms extension actions for saving / updating the editor's content. How is this sound? Claudius Teodorescu http://kuberam.ro |
|
From: Klotz, L. <Lei...@xe...> - 2010-03-11 18:28:25
|
Claudius, I realize you're doing a lot of work and it's certainly valuable. I'd like so suggest you take a look at some of the "benchmark" implementations. These feature are already present in products such as Chiba and Orbeon. The HTML editor is just another presentation of the underlying instance data through the textarea form control. Adding it shouldn't change the underlying semantics of form controls (focus behavior, @incremental, xforms-value-changed, etc.) Leigh. ________________________________ From: Claudius Teodorescu [mailto:cla...@ya...] Sent: Thursday, March 11, 2010 10:24 AM To: Klotz, Leigh Cc: support xsltforms Subject: Re: [Xsltforms-support] Integration of CKEditor into XSLTForms I repeatedly asked the community for opinions regarding the event that would trigger saving/updating the editor's content. Receiving no answer, I considered that treating the editor like an "island" within the form and allowing user to save/update the content (by using those two buttons) would be a simple and clear approach. I didn't want to update on each mouse gesture. Also, I considered adding some XForms extension actions to be used by the developer for saving/updating the editor's content as it is necessary, for instance upon xforms-submit-done, etc. Claudius Teodorescu http://kuberam.ro |
|
From: Claudius T. <cla...@ya...> - 2010-03-11 18:24:00
|
I repeatedly asked the community for opinions regarding the event that would trigger saving/updating the editor's content. Receiving no answer, I considered that treating the editor like an "island" within the form and allowing user to save/update the content (by using those two buttons) would be a simple and clear approach. I didn't want to update on each mouse gesture. Also, I considered adding some XForms extension actions to be used by the developer for saving/updating the editor's content as it is necessary, for instance upon xforms-submit-done, etc. Claudius Teodorescu http://kuberam.ro |
|
From: Klotz, L. <Lei...@xe...> - 2010-03-11 17:33:46
|
What's the reason for the save button? Can't you do what other forms do, and update the data when the user tabs off or on other actions, unless @incremental="true" in which case you update it as frequently as possible? That's what we did in the Chiba integration with TinyMCE. Leigh. ________________________________ From: Claudius Teodorescu [mailto:cla...@ya...] Sent: Thursday, March 11, 2010 12:17 AM To: support xsltforms Subject: [Xsltforms-support] Integration of CKEditor into XSLTForms Hi, I have few questions to the community: 1. I have the intention to make two extension actions, one for updating and one for saving the content of CKEditor from/to the respective @ref node. This is to allow developers another way of dealing with editor's content than just to rely on user's actions. Which is your opinion? 2. I really don't like very much the images I used for the "Save Content" and "Update Content" buttons. Is someone more inspired to contribute with more beautiful buttons? 3. What do think about integration of TinyMCE editor into XSLTForms using the same model as for CKEditor? Claudius Teodorescu http://kuberam.ro |
|
From: Grégoire C. <gco...@gm...> - 2010-03-11 17:09:42
|
Hi,
In function assert(condition, message), there's the following try/catch (rev
361) :
try {
var x; x.y;
} catch (exception) {
this.callstack = exception.stack.split("\n");
}
With Opera 10.10, the "x.y" instruction throws the following exception :
TypeError
Statement on line 851: Cannot convert undefined or null to Object
I don't understand the purpose of this line, and why it doesn't lead to an
exception in Firefox.
Cordialement,
Grégoire
|
|
From: Claudius T. <cla...@ya...> - 2010-03-11 08:16:39
|
Hi, I have few questions to the community: 1. I have the intention to make two extension actions, one for updating and one for saving the content of CKEditor from/to the respective @ref node. This is to allow developers another way of dealing with editor's content than just to rely on user's actions. Which is your opinion? 2. I really don't like very much the images I used for the "Save Content" and "Update Content" buttons. Is someone more inspired to contribute with more beautiful buttons? 3. What do think about integration of TinyMCE editor into XSLTForms using the same model as for CKEditor? Claudius Teodorescu http://kuberam.ro |
|
From: COUTHURES A. <ala...@ag...> - 2010-03-10 21:01:00
|
Javier, > We have modified all the for's acceding to the length property of an > array as described in the following page: > > http://www.erichynds.com/javascript/javascript-loop-performance-caching-the-length-property-of-an-array/ > > Attached I send you all the changes we have done (although the line > numbers may vary from official version, we have change some lines). Thank you very much for theses changes. I have checked them and some of them (few) appeared dangerous so I haven't integrated and committed all of them. I have tested with various tests and it was OK but regressions seem possible. If so, Javascript debugging shouldn't be difficult, anyway. It's always a good news to reduce IE execution time! -Alain |
|
From: Christian M. <chr...@mu...> - 2010-03-10 10:01:19
|
Thanks! I am a happy XML geek now! On Tue, Mar 9, 2010 at 11:01 PM, COUTHURES Alain < ala...@ag...> wrote: > Christian, > > I think I have located the problem why xalan gets a stack overflow error >> when transforming a xform with a lot of xpath expressions. As fas as I >> understand the xps template gets a long string which contains all >> concatenated xpath expressions to transform to javascript. the xps template >> gets recursively called with the remaining rest of the string. The parameter >> containing the string has to be created each recursion on the stack. and >> eventually it gets to small or something else happens such that the >> recursion doesn't finish correctly. >> >> I have tested that the occurrence of this problem depends only on the >> number of xpath expressions not on the kind. There is a point on which the >> transform fails if I add any attribute to the form. >> >> If I remove the recursion the transform finishes (giving an unusable >> result). I do not understand the code enough yet to replace it with >> something that would work for me. But I expect that this recursion could be >> transformed into a for-each loop by using something like tokenize(). or >> store the xpaths into a result tree fragment and using the node-set() >> function. >> >> I really want this to work on existdb and xalan because then I do not have >> to care about the performance any more as I would be able to serve a >> precompiled html-javascript page instead of doing the very slow >> xslttransform. If it takes a minute to redo the transform when I change the >> xforms -- I think I can live with that. Saxon9 is unfortunately not saving >> me because it fails too (and faster). Only saxon6.5 comes back with the >> result but Saxon6.5 is not supported by existdb (as far as I know). >> Thanks for all the help so far, and keep up the great work. >> > node-set() function can be used to avoid deep recursion. This function was > not supported by FireFox 2.0 but it doesn't sound important anymore. > > This is committed now. > > Thank you for your feedbacks! > > -Alain > |
|
From: Grégoire C. <gco...@gm...> - 2010-03-10 08:29:51
|
Hi, I noticed the following message on "What's happening?" screen at SF : *Hello, I'm trying an incremental search like the one you show in http://en.wikibooks.org/wiki/XForms/Incremental_Find. When the user write the first char in the xf:input , the event is fired and the request sent and during that time we loose one or more typed chars. Is there any mean to introduce a small delay before sending the request ? Cordialement. Benoit VINCENT.* I have exactly the same issue. Is there a solution? Grégoire |
|
From: COUTHURES A. <ala...@ag...> - 2010-03-09 22:06:05
|
Christian, > I think I have located the problem why xalan gets a stack overflow > error when transforming a xform with a lot of xpath expressions. As > fas as I understand the xps template gets a long string which contains > all concatenated xpath expressions to transform to javascript. the xps > template gets recursively called with the remaining rest of the > string. The parameter containing the string has to be created each > recursion on the stack. and eventually it gets to small or something > else happens such that the recursion doesn't finish correctly. > > I have tested that the occurrence of this problem depends only on the > number of xpath expressions not on the kind. There is a point on which > the transform fails if I add any attribute to the form. > > If I remove the recursion the transform finishes (giving an unusable > result). I do not understand the code enough yet to replace it with > something that would work for me. But I expect that this recursion > could be transformed into a for-each loop by using something like > tokenize(). or store the xpaths into a result tree fragment and using > the node-set() function. > > I really want this to work on existdb and xalan because then I do not > have to care about the performance any more as I would be able to > serve a precompiled html-javascript page instead of doing the very > slow xslttransform. If it takes a minute to redo the transform when I > change the xforms -- I think I can live with that. Saxon9 is > unfortunately not saving me because it fails too (and faster). Only > saxon6.5 comes back with the result but Saxon6.5 is not supported by > existdb (as far as I know). > > Thanks for all the help so far, and keep up the great work. node-set() function can be used to avoid deep recursion. This function was not supported by FireFox 2.0 but it doesn't sound important anymore. This is committed now. Thank you for your feedbacks! -Alain |
|
From: Christian M. <ch...@gm...> - 2010-03-09 17:26:42
|
I think I have located the problem why xalan gets a stack overflow error
when transforming a xform with a lot of xpath expressions. As fas as I
understand the xps template gets a long string which contains all
concatenated xpath expressions to transform to javascript. the xps template
gets recursively called with the remaining rest of the string. The parameter
containing the string has to be created each recursion on the stack.
and eventually it gets to small or something else happens such that the
recursion doesn't finish correctly.
I have tested that the occurrence of this problem depends only on the number
of xpath expressions not on the kind. There is a point on which the
transform fails if I add any attribute to the form.
If I remove the recursion the transform finishes (giving an unusable
result). I do not understand the code enough yet to replace it with
something that would work for me. But I expect that this recursion could be
transformed into a for-each loop by using something like tokenize(). or
store the xpaths into a result tree fragment and using the node-set()
function.
I really want this to work on existdb and xalan because then I do not have
to care about the performance any more as I would be able to serve a
precompiled html-javascript page instead of doing the very slow
xslttransform. If it takes a minute to redo the transform when I change the
xforms -- I think I can live with that. Saxon9 is unfortunately not saving
me because it fails too (and faster). Only saxon6.5 comes back with the
result but Saxon6.5 is not supported by existdb (as far as I know).
Thanks for all the help so far, and keep up the great work.
<xsl:template name="xps">
<xsl:param name="ps"/>
<xsl:param name="prep"/>
<xsl:variable name="xplen" select="substring-before($ps,'.')"/>
<xsl:variable name="xp"
select="substring(substring-after($ps,'.'),1,number($xplen))"/>
<xsl:if test="$xp != $prep">
<xsl:variable name="r">
<xsl:call-template name="xpath">
<xsl:with-param name="xp" select="$xp"/>
</xsl:call-template>
</xsl:variable>
<xsl:value-of select="$r"/>
</xsl:if>
<xsl:variable name="ps2"
select="substring($ps,string-length($xplen)+2+number($xplen))"/>
<xsl:if test="$ps2 != ''">
<xsl:call-template name="xps">
<xsl:with-param name="ps" select="$ps2"/>
<xsl:with-param name="prep" select="$xp"/>
</xsl:call-template>
</xsl:if>
</xsl:template>
|
|
From: Christian M. <chr...@mu...> - 2010-03-08 20:33:37
|
well, no. It must be in the "src" attribute data
On Mon, Mar 8, 2010 at 9:27 PM, Dan McCreary <dan...@gm...> wrote:
> Hello Christian,
>
> You might try putting CDATA tags around all your "LATEX" data elements:
>
> <![CDATA[
> tags with {} here...
> ]]>
>
> See: http://en.wikipedia.org/wiki/CDATA
>
> On Mon, Mar 8, 2010 at 11:58 AM, Christian Meisenbichler <
> chr...@mu...> wrote:
>
>> I Have a strange issue with images and xslforms. I want to use google
>> graph api to display latex. In latex curly brackets group terms. xsltforms
>> obviously tries to transform the content in {} into xpath which gives a
>> javascript error. I did not find a way to escape the curly brackets.
>> Schouldn't be image tags ignored by xsltforms?
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Xsltforms-support mailing list
>> Xsl...@li...
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>
>>
>
>
> --
> Dan McCreary
> Semantic Solutions Architect
> syntactica.com
> 952-460-1674
> VOIP: 111@69.199.167.229
>
|
|
From: Dan M. <dan...@gm...> - 2010-03-08 20:27:59
|
Hello Christian,
You might try putting CDATA tags around all your "LATEX" data elements:
<![CDATA[
tags with {} here...
]]>
See: http://en.wikipedia.org/wiki/CDATA
On Mon, Mar 8, 2010 at 11:58 AM, Christian Meisenbichler <
chr...@mu...> wrote:
> I Have a strange issue with images and xslforms. I want to use google graph
> api to display latex. In latex curly brackets group terms. xsltforms
> obviously tries to transform the content in {} into xpath which gives a
> javascript error. I did not find a way to escape the curly brackets.
> Schouldn't be image tags ignored by xsltforms?
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Xsltforms-support mailing list
> Xsl...@li...
> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>
--
Dan McCreary
Semantic Solutions Architect
syntactica.com
952-460-1674
VOIP: 111@69.199.167.229
|
|
From: Klotz, L. <Lei...@xe...> - 2010-03-08 19:52:05
|
My test was for significantly fewer than 200 checkboxes, which is probably why I didn't see the difference in clock time. ________________________________ From: Javier Díaz [mailto:jd...@ge...] Sent: Monday, March 08, 2010 7:48 AM To: Tambet Matiisen Cc: Klotz, Leigh; xsl...@li... Subject: Re: [Xsltforms-support] xsltforms Performance Hello, We have modified all the for's acceding to the length property of an array as described in the following page: http://www.erichynds.com/javascript/javascript-loop-performance-caching-the-length-property-of-an-array/ Attached I send you all the changes we have done (although the line numbers may vary from official version, we have change some lines). With these changes, xsltforms works better when having lots of instance data. In our worst case, we had a page that in explorer didn't managed to load (a dialog to abort the script appeared because it lasted too long), while with the modification now it loads ok (unfortunately in continues to be a bit slow). I hope it may be useful for anybody. Best Regards, Javier Tambet Matiisen escribió: I just did a few tests with my case. function selectAll(form, regexp, checked) { var elements = form.elements; var elements_length = elements.length; for(var i = 0; i < elements_length; i++) { var element = elements[i]; if (element.type == 'checkbox' && element.name.search(regexp) != -1) { element.checked = checked; } } } I had a form with 200 checkboxes. for(var i = 0; i < elements_length; i++) - took ~1s to check all for(var i = 0; i < elements.length; i++) - took ~2s to check all for(var i = 0; i < form.elements.length; i++) - took ~3s to check all It seems that accessing properties (maybe only form.elements?) is slow in IE(8). All cases worked almost instantaneously in FF(3.5). Tambet Klotz, Leigh wrote: I tried this just now; it was tedious but doable. I didn't bother for strings. Some loops affect the list length and need to be left alone. I didn't get it 100% right and get the occasional JS error; care must be taken! I tried a sample application and didn't see a measureable clock-time performance improvement in IE8. There are some areas where performance is poor compared to other FF3.6 (four seconds vs instantaneous) but this didn't fix it I'm willing to believe that this fixes problems I just didn't happen encounter, but it doesn't fix one I did encounter. Leigh. ________________________________ From: Tambet Matiisen [mailto:tam...@gm...] Sent: Wednesday, January 27, 2010 12:30 AM To: xsl...@li... Subject: Re: [Xsltforms-support] xsltforms Performance Christopher Dedels wrote: Profiling tools report at least 13 seconds in IE 8 (2.5 seconds in FF/Chrome) to "tab" from one field to the next, regardless of whether the data in the field was changed. As you can expect, this is not acceptable for my users. I've noticed, that IE calculates .length property of arrays by counting all array elements. This makes such cycles especially slow: for (var i = 0; i < frm.elements.length; i++) This can be easily fixed by assigning length to a variable: var elements_length = frm.elements.length; for (var i = 0; i < elements_length; i++) You could search XSLTForms javascript code for ".length" and try if this fix makes it better. Tambet ________________________________ ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ________________________________ _______________________________________________ Xsltforms-support mailing list Xsl...@li... https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
|
From: Christian M. <chr...@mu...> - 2010-03-08 17:58:15
|
I Have a strange issue with images and xslforms. I want to use google graph
api to display latex. In latex curly brackets group terms. xsltforms
obviously tries to transform the content in {} into xpath which gives a
javascript error. I did not find a way to escape the curly brackets.
Schouldn't be image tags ignored by xsltforms?
|
|
From: Javier D. <jd...@ge...> - 2010-03-08 15:47:57
|
125c125
< for (var i = 0 , len = scripts.length; i < len; i++) {
---
> for (var i = 0; i < scripts.length; i++) {
415,416c415,416
< for (var i = 0 , len = this.depth; i < len; i++) {
< for (var j = 0 , len1 = this.selectstack[i].length; j < len1 ; j++) {
---
> for (var i = 0; i < this.depth; i++) {
> for (var j = 0; j < this.selectstack[i].length; j++) {
435c435
< for (var i = 0 , len = selects.length; i < len; i++) {
---
> for (var i = 0; i < selects.length; i++) {
451c451
< for (var j = 0, len1 = dis.length; j < len1; j++) {
---
> for (var j = 0; j < dis.length; j++) {
815c815
< for (var i = 0 , len = arguments.length - 2; i < len; i++) {
---
> for (var i = 0; i < arguments.length - 2; i++) {
821c821
< for (var j = 0 , len1 = object.length; j < len1; j++) {
---
> for (var j = 0; j < object.length; j++) {
872c872
< for (var i = 0 , len = array.length; i < len; i++) {
---
> for (var i = 0; i < array.length; i++) {
978c978
< for (var i = 0, len = source.length; i < len; i++) {
---
> for (var i = 0; i < source.length; i++) {
1101c1101
< for (var i = 0, len = changes.length; i < len; i++) {
---
> for (var i = 0; i < changes.length; i++) {
1157c1157
< for (var i = 0, len = this.models.length; i < len; i++) {
---
> for (var i = 0; i < this.models.length; i++) {
1202c1202
< for (var i = 0, len = childs.length; i < len && this.building; i++) {
---
> for (var i = 0; i < childs.length && this.building; i++) {
1246c1246
< for (var i = 0, len = childs.length; i < len; i++) {
---
> for (var i = 0; i < childs.length; i++) {
1328c1328
< for (var i = 0, len = ids.length; i < len; i++) {
---
> for (var i = 0; i < ids.length; i++) {
1429c1429
< for (var i = 0, len = schemas.length; i < len; i++) {
---
> for (var i = 0; i < schemas.length; i++) {
1693c1693
< for (var i = 0, len = atts.length; i < len; i++) {
---
> for (var i = 0; i < atts.length; i++) {
1698c1698
< for (var j = 0, len1 = node.childNodes.length; j < len1; j++) {
---
> for (var j = 0; j < node.childNodes.length; j++) {
1715c1715
< for (len = nodes.length; i < len; i++) {
---
> for (; i < nodes.length; i++) {
1756c1756
< for (var i = 0, len = json.length; i < len ; i++) {
---
> for (var i = 0; i < json.length; i++) {
1826c1826
< for (var i = 0, len = this.nodes.length; i < len; i++) {
---
> for (var i = 0; i < this.nodes.length; i++) {
1843c1843
< for (var j = 0, len1 = el.childNodes.length; j < len1; j++) {
---
> for (var j = 0; j < el.childNodes.length; j++) {
1856c1856
< for (var i = 0, len = this.nodes.length; i < len; i++) {
---
> for (var i = 0; i < this.nodes.length; i++) {
1867c1867
< for (var j = 0, len1 = el.childNodes.length; j < len1; j++) {
---
> for (var j = 0; j < el.childNodes.length; j++) {
1896c1896
< for (var i = 1, len = lines.length; i < len; i++) {
---
> for (var i = 1; i < lines.length; i++) {
2133c2133
< for(var i = 0, len = node.childNodes.length; i < len; i++) {
---
> for(var i = 0; i < node.childNodes.length; i++) {
2388c2388
< for(var i = 0, len = nodes.length; i < len; i++) {
---
> for(var i = 0; i < nodes.length; i++) {
2475c2475
< for(var i = 0, len = originNodes.length; i < len; i += 1) {
---
> for(var i = 0; i < originNodes.length; i += 1) {
2707c2705
< for (var i = ul != null? 1 : 0, len = childs.length; i < len; i++) {
---
> for (var i = ul != null? 1 : 0; i < childs.length; i++) {
2838c2836
< for (var i = 0, len = childs.length; i < len; i++) {
---
> for (var i = 0; i < childs.length; i++) {
2851c2849
< for (var j = ul.childNodes.length, len1 = childs.length; j > len1; j--) {
---
> for (var j = ul.childNodes.length; j > childs.length; j--) {
2869c2867
< for (var i = 0, len = attrs.length; i < len; i++) {
---
> for (var i = 0; i < attrs.length; i++) {
2957c2955
< for (var i = 0, len = deps.length; !build && i < len; i++) {
---
> for (var i = 0; !build && i < deps.length; i++) {
2960c2958
< for (var j = 0, len1 = changes.length; !build && j < len1; j++) {
---
> for (var j = 0; !build && j < changes.length; j++) {
2966c2964
< for (var k = 0, len2 = depsN.length; !build && k < len2; k++) {
---
> for (var k = 0; !build && k < depsN.length; k++) {
2971c2969
< for (var n = 0, len3 = depsR.length; n < len3; n++) {
---
> for (var n = 0; n < depsR.length; n++) {
3270c3268
< for (var i = 1, len = childs.length; i < len; i++) {
---
> for (var i = 1; i < childs.length; i++) {
3537c3535
< for (var i = 0, len = value.length; i < len; i++) {
---
> for (var i = 0; i < value.length; i++) {
3727c3725
< for (var j = 0, len = this.nodes.length; j < len || j == 0; j++) {
---
> for (var j = 0; j < this.nodes.length || j == 0; j++) {
3812c3810
< for (var i=0, len = this.valueElement.childNodes.length; i<len; i++) {
---
> for (var i=0; i<this.valueElement.childNodes.length; i++) {
3932c3930
< for (var i = 0, len = nodes.length; i < len; i++) {
---
> for (var i = 0; i < nodes.length; i++) {
3952c3950
< for (var i = 0, len = nodes.length; i < len; i++) {
---
> for (var i = 0; i < nodes.length; i++) {
3985c3983
< for (var j = n, len = r.childNodes.length; j < l && len > 1; j++) {
---
> for (var j = n; j < l && r.childNodes.length > 1; j++) {
4012c4010
< for (var i = 0, len = childs.length; i < len; i++) {
---
> for (var i = 0; i < childs.length; i++) {
4046c4044
< for (var i = 0, len = listeners.length; i < len; i++) {
---
> for (var i = 0; i < listeners.length; i++) {
4077c4075
< for (var i = 0, len = childs.length; i < len; i++) {
---
> for (var i = 0; i < childs.length; i++) {
4146c4144
< for (var i = 0, len = vals.length; well && i < len; i++) {
---
> for (var i = 0; well && i < vals.length; i++) {
4150c4148
< for (var j = 0, len1 = list.length; !finded && j < len1; j++) {
---
> for (var j = 0; !finded && j < list.length; j++) {
4173c4171
< for (var n = 0, len2 = list.length; n < len2; n++) {
---
> for (var n = 0; n < list.length; n++) {
4179c4177
< for (var k = 0, len3 = list.length; k < len3; k++) {
---
> for (var k = 0; k < list.length; k++) {
4198c4196
< for (var i = 0, len = list.length; i < len; i++) {
---
> for (var i = 0; i < list.length; i++) {
4218c4216
< for (var i = 0, len = inputs.length; i < len; i++) {
---
> for (var i = 0; i < inputs.length; i++) {
4237c4235
< for (var j = 0, len1 = inputs.length; j < len1; j++) {
---
> for (var j = 0; j < inputs.length; j++) {
4283c4281
< for (var i = 0, len = old.length; i < len; i++) {
---
> for (var i = 0; i < old.length; i++) {
4291c4289
< for (var j = 0, len1 = opts.length; j < len1; j++) {
---
> for (var j = 0; j < opts.length; j++) {
4330c4328
< for (var i = 0, len = opts.length; i < len; i++) {
---
> for (var i = 0; i < opts.length; i++) {
4871c4869
< for (var i = 0, len = this.patterns.length; i < len; i++) {
---
> for (var i = 0; i < this.patterns.length; i++) {
4880c4878
< for (var j = 0, len1 = this.enumeration.length; j < len1; j++) {
---
> for (var j = 0; j < this.enumeration.length; j++) {
4987c4985
< for (var i = 0, len = items.length; i < len; i++) {
---
> for (var i = 0; i < items.length; i++) {
5013c5011
< for (var i = 0, len = items.length; i < len; i++) {
---
> for (var i = 0; i < items.length; i++) {
5043c5041
< for (var i = 0, len = this.baseTypes.length; i < len; ++i) {
---
> for (var i = 0; i < this.baseTypes.length; ++i) {
6290c6288
< for (var i = 0, len = this.childNodes.length; i < len; ++i) {
---
> for (var i = 0; i < this.childNodes.length; ++i) {
6329c6327
< for (var i = 0, len = this.childNodes.length; i < len; ++i) {
---
> for (var i = 0; i < this.childNodes.length; ++i) {
6377c6375
< for (var i = 0, len = this.childNodes.length; i < len; ++i) {
---
> for (var i = 0; i < this.childNodes.length; ++i) {
6409c6407
< for (var i = 0, len = this.childNodes.length; i < len; ++i) {
---
> for (var i = 0; i < this.childNodes.length; ++i) {
6442c6440
< for (var i = 0, len = this.attributes.length; !founded && i < len; i++) {
---
> for (var i = 0; !founded && i < this.attributes.length; i++) {
6471c6469
< for (var i = 0, len = this.attributes.length; i < len; ++i) {
---
> for (var i = 0; i < this.attributes.length; ++i) {
6488c6486
< for (var i = 0, len = this.attributes.length; i < len; i++) {
---
> for (var i = 0; i < this.attributes.length; i++) {
6514c6512
< for (var i = 0, len = this.childNodes.length; i < len; i++) {
---
> for (var i = 0; i < this.childNodes.length; i++) {
6518c6516
< for (var j = 0, len1 = this.attributes.length ; j < len1; j++) {
---
> for (var j = 0; j < this.attributes.length; j++) {
6571c6569
< for (var a = 0, len = node.attributes.length; a < len; ++a) {
---
> for (var a = 0; a < node.attributes.length; ++a) {
6575c6573
< for (var c = 0, len1 = node.childNodes.length; c < len1; ++c) {
---
> for (var c = 0; c < node.childNodes.length; ++c) {
6713c6711
< for (var i = 1, len = x.length; i < len; i++) {
---
> for (var i = 1; i < x.length; i++) {
6767c6765
< for (var j = 0, len1 = atts.length; j < len1; j++) {
---
> for (var j = 0; j < atts.length; j++) {
6873c6871
< for (var j = 0, len = atts.length; j < len; j++) {
---
> for (var j = 0; j < atts.length; j++) {
6881c6879
< for (var k = 0, len1 = childs.length; k < len1; k++) {
---
> for (var k = 0; k < childs.length; k++) {
6914c6912
< for (var i = 0, len = atts.length; i < len; i++) {
---
> for (var i = 0; i < atts.length; i++) {
6918c6916
< for (var j = 0, len1 = childs.length; j < len1; j++) {
---
> for (var j = 0; j < childs.length; j++) {
6943c6941
< for (var i = 0, len = value.length; i < len; i++) {
---
> for (var i = 0; i < value.length; i++) {
6987c6985
< for (var i = 0, len = node.childNodes.length; i < len ; ++i) {
---
> for (var i = 0; i < node.childNodes.length; ++i) {
7017c7015
< for (var i = 0, len = this.exprs.length; i < len; i++) {
---
> for (var i = 0; i < this.exprs.length; i++) {
7043c7041
< for (var i = 0, len = v1.length; i < len; i++) {
---
> for (var i = 0; i < v1.length; i++) {
7048c7046
< for (var j = 0, len1 = v2.length; j < len1; j++) {
---
> for (var j = 0; j <v2.length; j++) {
7103c7101
< for(position = 1, len = node.repeat.nodes.length; position <= len; position++) {
---
> for(position = 1; position <= node.repeat.nodes.length; position++) {
7224c7222
< for (var i = 0, len = this.predicate.length; i < len; ++i) {
---
> for (var i = 0; i < this.predicate.length; ++i) {
7228c7226
< for (var j = 0, len1 = nodes0.length; j < len1; ++j) {
---
> for (var j = 0; j < nodes0.length; ++j) {
7254c7252
< for (var i = 1, len = arguments.length; i < len; i++) {
---
> for (var i = 1; i < arguments.length; i++) {
7265c7263
< for (var i = 0, len = this.args.length; i < len; i++) {
---
> for (var i = 0; i < this.args.length; i++) {
7280c7278
< for (var i = 1, len = arguments.length; i < len; i++) {
---
> for (var i = 1; i < arguments.length; i++) {
7301c7299
< for (var i = 0, len = nodelist.length; i < len; ++i) {
---
> for (var i = 0; i < nodelist.length; ++i) {
7449c7447
< for (var i = 0, len = nodes.length; i < len; i++) {
---
> for (var i = 0; i < nodes.length; i++) {
7453c7451
< for (var j = 0, len1 = nodes0.length; j < len1; j++) {
---
> for (var j = 0; j < nodes0.length; j++) {
7486c7484
< for (var i = 2, len = arguments.length; i < len; i++) {
---
> for (var i = 2; i < arguments.length; i++) {
7560c7558
< for (var i = 0, len = this.predicates.length; i < len; i++) {
---
> for (var i = 0; i < this.predicates.length; i++) {
7564c7562
< for (var j = 0, len1 = list.length; j < len1; j++) {
---
> for (var j = 0; j < list.length; j++) {
7586c7584
< for (var i = 0, len = l.length; i < len; i++) {
---
> for (var i = 0; i < l.length; i++) {
7623c7621
< for (var i2 = 0, len = nodes2.length; i2 < len; ++i2) {
---
> for (var i2 = 0; i2 < nodes2.length; ++i2) {
7694c7692
< for (var i = 0, len = node.childNodes.length; i < len; ++i) {
---
> for (var i = 0; i < node.childNodes.length; ++i) {
7714c7712
< for (var i = 1, len = parts.length; i < len; ++i) {
---
> for (var i = 1; i < parts.length; ++i) {
7789c7787
< for (var i = 0, len = ns.length; i < len; i += 2) {
---
> for (var i = 0; i < ns.length; i += 2) {
7840c7838
< for (var i = 2, len = arguments.length; i < len; i += 2) {
---
> for (var i = 2; i < arguments.length; i += 2) {
7971c7969
< for (var i = 0, len = object.length; i < len; ++i) {
---
> for (var i = 0; i < object.length; ++i) {
7974c7972
< for (i = 0, len1 = res.length; i < len1; i++) {
---
> for (i = 0; i < res.length; i++) {
8050c8048
< for (var i = 0, len2 = arguments.length; i < len2; ++i) {
---
> for (var i = 0; i < arguments.length; ++i) {
8165c8163
< for (var i = 0, len3 = string.length; i < len3; ++i) {
---
> for (var i = 0; i < string.length; ++i) {
8263c8261
< for (var i = 0, len4 = nodeSet.length; i < len4; ++i) {
---
> for (var i = 0; i < nodeSet.length; ++i) {
8387c8385
< for (var i = 1, len5 = nodeSet.length; i < len5; ++i) {
---
> for (var i = 1; i < nodeSet.length; ++i) {
8445c8443
< for (var i = 0, len6 = nodeSet.length; i < len6; ++i) {
---
> for (var i = 0; i < nodeSet.length; ++i) {
8641c8639
< for (var i = 0, len7 = nodeSet.length; valid && i < len7; i++) {
---
> for (var i = 0; valid && i < nodeSet.length; i++) {
9054c9052
< for (var i = 0, len = node.attributes.length; i < len; i++) {
---
> for (var i = 0; i < node.attributes.length; i++) {
9060c9058
< for (var i = 0, len1 = node.childNodes.length; i < len1; i++) {
---
> for (var i = 0; i < node.childNodes.length; i++) {
9127c9125
< for (var i = 0, len = node.childNodes.length; i < len; ++i) {
---
> for (var i = 0; i < node.childNodes.length; ++i) {
9147c9145
< for (var i = 1, len = parts.length; i < len; ++i) {
---
> for (var i = 1; i < parts.length; ++i) {
|
|
From: Claudius T. <cla...@ya...> - 2010-03-08 10:24:25
|
This version provides a new feature, namely the integration of CKEditor (a well-known rich text editor for web) into XSLTForms. CKEditor SHOULD be used with the configuration file (config.js) having the content of CKEditor.config.js file found in eXSLTForms archive. The reason is that the implementation needs two buttons, namely "Save Content" (arrow up), for updating the @ref node of textarea element with editor's content, and "Update Content" (arrow down), for updating the editor's content with the content of the @ref node of textarea element. These buttons are included into the definitions of CKEditor's "Full" and "Basic" toolbars and into a sample toolbar, named "MyToolbar" (as example). The user could define any toolbar he needs, but it is mandatory the include in such toolbars the reference to above-mentioned buttons, in order to properly use CKEditor into XSLTForms. Also, the page XForms designated to host a CKEditor should include a script element having @src pointing to ckeditor.js file. Last, but not the least, in order to be valid XML, this extension should have its own namespace, but this imply certain modifications of XSLTForms. I release this version as is, for users to enjoy, and, with kind help of Alain Couthures, I hope that next version will have its own namespace. Claudius Teodorescu http://kuberam.ro |
|
From: Claudius T. <cla...@ya...> - 2010-03-05 23:32:36
|
I think that an elegant and logical way to update the node referred by xf:textarea/@ref is to press the button "Save" (the diskette). But this is now used for submit the form, so we have to find a workaround. Claudius Teodorescu http://kuberam.ro |
|
From: Claudius T. <cla...@ya...> - 2010-03-05 23:11:50
|
Sorry, this is the link for testing http://kuberam.ro/webApps/apps/sitKubera/workingTests/ckeditor.xml?_xsl=no Claudius Teodorescu http://kuberam.ro |
|
From: Claudius T. <cla...@ya...> - 2010-03-05 22:19:23
|
I managed to integrate it almost entirely. I still need opinions about the observer and action that should trigger the updating of the node referred by xf:textarea/@ref with the data contained by the CKEditor. The example could be checked out at http://localhost:8080/webApps/apps/sitKubera/workingTests/ckeditor.xml?_xsl=no One should modify the content of editor and press twice the button "Update instance" (I don't know why twice, but it is not important). This button pressing emulates the behaviour we need, as it implies an ev:observer (trigger) and an ev:event (DOMActivate). By default, CKEditor updates the value of initial textarea element upon submitting the respective form, but we may be interested in more subtle behaviour. Claudius Teodorescu http://kuberam.ro ________________________________ From: "Klotz, Leigh" <Lei...@xe...> To: Claudius Teodorescu <cla...@ya...> Sent: Fri, March 5, 2010 8:25:55 PM Subject: RE: [Xsltforms-support] No response on the CKEditor forums toquestion on encoding Sounds good. Since you're writing the extension you get to choose the namespace. How about http://kuberam.ro/2010/02/ckeditor ? Or whatever you'd like there. <html ... xmlns:ex="http://kuberam.ro/2010/02/ckeditor" ... > <xf:textarea ref="instance('i0')/CKEditorDescription" appearance="ex:CKEditor"> <xf:label>CKEditor textarea:</xf:label> <xf:extension> <ex:CKEditorOptions toolbar="Full" language="ro" skin="v2"/> </xf:extension> </xf:textarea> Likely Alain will want to use his own if it's an agenceXML extension he publishes, but for your own purposes or if you want to provide it yourself as an exsltforms addon you would just use your own. It just can't be the http://www.w3.org/2002/xforms namespace because the spec doesn't allow it. Leigh. ________________________________ From: Claudius Teodorescu [mailto:cla...@ya...] Sent: Friday, March 05, 2010 10:20 AM To: Klotz, Leigh Subject: Re: [Xsltforms-support] No response on the CKEditor forums toquestion on encoding Ok, I agreed with other namespace for "CKEditorOptions" element and appearance attribute value, but which one should be? I know that you are working with XForms WG, don't you have any idea of a namespace? I've chosen to express the config specifications for CKEditor by using the attributes of "CKEditorOptions" as it is scalable, so that no matter how many are they or which ones, the XSL stylesheet is aggregating them in a string for initializing the CKEditor. Claudius Teodorescu http://kuberam.ro |
|
From: Claudius T. <cla...@ya...> - 2010-03-05 15:55:32
|
At this very moment, as agreed with Alain, I am implementing CKEditor in XSLTForms. I used the nice syntax pointed out by Leigh Klotz, with small modifications. An example is here http://kuberam.ro/webApps/apps/sitKubera/workingTests/ckeditor.xml?_indent=no I have only to solve the binding of data from CKEditor to the initial xf:textarea. As the base control for CKEditor is xf:textarea, which has a Single Node Binding, I am afraid that it would be not possible to sent the data entered through CKEditor as XML fragment (if needed), other than using an extra step for parsing data, as Alain said last night. I guess this can be done by creating a sort of "unserialize" XPath extension function. I take the opportunity of this message to ask for some advice from the community: 1. Leigh used a syntax like this appearance="ext:ckedit". Is this prefix "ext" necessary? If yes, which would be its namespace? 2. Which is the specific event to transfer the data from CKEditor to the initial xf:textarea. By default, CKEditor transfer it on submitting the respective form. Should we use this model, or refine it, namely by making that transfer before submit, so that the respective data node to be constantly updated? Claudius Teodorescu http://kuberam.ro |
|
From: Rob K. <ro...@ko...> - 2010-03-05 15:43:52
|
You probably have to bind to the submit event (you can use jquery for this type of thing or stick an onsubmit='return mySubmitHandler()' on the form). Then, before you send to the server, use the built in javascript unescape(& lt;p>hello world</p>) best, -Rob On Fri, Mar 5, 2010 at 7:32 AM, Dan McCreary <dan...@gm...> wrote: > Hi Rob, > > Thanks for your note. I agree that the world "encode" has many meanings. > Sorry if I was not clear. > > I am trying to get CKEditor to not encode the HTML/XML it sends using the > < and > notation when it does a post to the eXist server after the > user does a save. > > For example: > > <p>hello world</p> > > Is being submitted to the server as: > > <p>hello world</p> > > >From what I can tell, CKEditor does this by default and I can not seem to > be able to turn it off on the client reguardless of the config file settings > I use. Since it is easy to unencode the post data on the server side with > the XQuery util:parse() function it is really just a small issue. It just > that every single < and > takes four characters when only one is needed. > > Has anyone else got this to work? > > - Dan > > On Fri, Mar 5, 2010 at 9:12 AM, Rob Koberg <ro...@ko...> wrote: > >> Are you talking about character encoding or escaping XML/XHTML so it can >> go into a textarea? >> >> If encoding, put a content type meta in your head. >> >> If escaping, you can GET from the server and use javascript to escape the >> XML, and then place in a textarea. Then on save, get the value of the >> textarea and unescape it to PUT or POST. >> >> best, >> -Rob >> >> >> >> On Fri, Mar 5, 2010 at 6:51 AM, Dan McCreary <dan...@gm...>wrote: >> >>> I posted the question about how to NOT encode XML on post on the CKEditor >>> forum yesterday: >>> >>> http://cksource.com/forums/viewtopic.php?f=11&t=17900 >>> >>> But I have not got any feedback. >>> >>> Since we can always just do a server-side parse using util:parse() this >>> is not a problem for eXist. But I wanted to see who was watching the >>> forums. >>> >>> I have tried to classify all the major configuration options of a >>> CKEditor into around a dozen classes: >>> >>> Category Description Coding These options control how editor encodes >>> various items. Configuration These options control how editor is >>> configured and the locations that this configuration information is loaded. >>> Initialization These options control how editor is first presented to >>> the user. Import Text These options control initial text is imported. >>> Keyboard These options control how characters typed on the keyboard are >>> managed. Language These options control the language used or >>> language-related options. Output These options control how data is >>> output when the text is saved. Dialog These options control the >>> behavior within specific dialog panels. Runtime These options control >>> the non-style related user experience while the editor is running. >>> Style These options control the presentation aspects of this extension. >>> Options are traditionally done through a CSS file. Text Coding These >>> options control how internal elements in the text are represented or coded >>> as the user interacts with the editor. >>> It might be nice to create a multi-tab XForms application to edit the >>> most common configuration options. >>> >>> Note that most of the configuration options are style-related. My next >>> step is to find out what options are the most important for our users. >>> >>> - Dan >>> >>> -- >>> Dan McCreary >>> Semantic Solutions Architect >>> syntactica.com >>> 952-460-1674 >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Xsltforms-support mailing list >>> Xsl...@li... >>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support >>> >>> >> > > > -- > Dan McCreary > Semantic Solutions Architect > syntactica.com > 952-460-1674 > VOIP: 111@69.199.167.229 > |
|
From: Dan M. <dan...@gm...> - 2010-03-05 15:32:56
|
Hi Rob, Thanks for your note. I agree that the world "encode" has many meanings. Sorry if I was not clear. I am trying to get CKEditor to not encode the HTML/XML it sends using the < and > notation when it does a post to the eXist server after the user does a save. For example: <p>hello world</p> Is being submitted to the server as: <p>hello world</p> >From what I can tell, CKEditor does this by default and I can not seem to be able to turn it off on the client reguardless of the config file settings I use. Since it is easy to unencode the post data on the server side with the XQuery util:parse() function it is really just a small issue. It just that every single < and > takes four characters when only one is needed. Has anyone else got this to work? - Dan On Fri, Mar 5, 2010 at 9:12 AM, Rob Koberg <ro...@ko...> wrote: > Are you talking about character encoding or escaping XML/XHTML so it can go > into a textarea? > > If encoding, put a content type meta in your head. > > If escaping, you can GET from the server and use javascript to escape the > XML, and then place in a textarea. Then on save, get the value of the > textarea and unescape it to PUT or POST. > > best, > -Rob > > > > On Fri, Mar 5, 2010 at 6:51 AM, Dan McCreary <dan...@gm...>wrote: > >> I posted the question about how to NOT encode XML on post on the CKEditor >> forum yesterday: >> >> http://cksource.com/forums/viewtopic.php?f=11&t=17900 >> >> But I have not got any feedback. >> >> Since we can always just do a server-side parse using util:parse() this is >> not a problem for eXist. But I wanted to see who was watching the forums. >> >> I have tried to classify all the major configuration options of a CKEditor >> into around a dozen classes: >> >> Category Description Coding These options control how editor encodes >> various items. Configuration These options control how editor is >> configured and the locations that this configuration information is loaded. >> Initialization These options control how editor is first presented to the >> user. Import Text These options control initial text is imported. >> Keyboard These options control how characters typed on the keyboard are >> managed. Language These options control the language used or >> language-related options. Output These options control how data is >> output when the text is saved. Dialog These options control the behavior >> within specific dialog panels. Runtime These options control the >> non-style related user experience while the editor is running. Style These >> options control the presentation aspects of this extension. Options are >> traditionally done through a CSS file. Text Coding These options control >> how internal elements in the text are represented or coded as the user >> interacts with the editor. >> It might be nice to create a multi-tab XForms application to edit the most >> common configuration options. >> >> Note that most of the configuration options are style-related. My next >> step is to find out what options are the most important for our users. >> >> - Dan >> >> -- >> Dan McCreary >> Semantic Solutions Architect >> syntactica.com >> 952-460-1674 >> >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Xsltforms-support mailing list >> Xsl...@li... >> https://lists.sourceforge.net/lists/listinfo/xsltforms-support >> >> > -- Dan McCreary Semantic Solutions Architect syntactica.com 952-460-1674 VOIP: 111@69.199.167.229 |
97 messages has been excluded from this view by a project administrator.
