I have a webpage that posts multiple form tags. It's an inline edit page, where I can either post one row at a time or multiple rows. Last night, without making any changes to the code or data, I started getting The URL-encoded form data is not valid error on multiple posts, although single row posts work fine.
The MS KB issue in question is: http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx
In a nutshell there is now an upper bound on the number of simultaneous HTTP form elements that may be posted. The default is now 1000 without explicitly changing it with this key in the <appSettings> portion of the web.config:
<add key="aspnet:MaxHttpCollectionKeys" value="some number greater than 1000" />
There was a microsoft update and it may have caused your issue see link.
http://knowledgebase.solarwinds.com/kb/questions/3476/Website+Error%3A+The+URL-encoded+form+data+is+not+valid
Related
Yesterday I have run extensive DNS tests with namebench, since my current DNS server is giving me lots of problems. The problem is that all resulting Google Charts are failing to load. This never happened to me, though. I looked at the source for the HTML page returned by namebench, and opened the links for the graphs, and they return the HTTP error 400.
One sample URL:
http://chart.apis.google.com/chart?chxt=y%2Cx%2Cx&chd=e%3AEmE8FXFeFfFqFwFxFxFzF9GEGGGKGLGOGQGRGSGSGTGWGYGcGdGdGdGeGhGiGjGlGqGqGqGqGvGwGxGxG0G0G0G1G2G4G5G7G9G-G-HAHAHEHGHKHLHMHMHNHPHRHWHWHYHYHZHaHeHiHiHjHkHkHlHmHnHnHoHoHpHqHsHtHtHuHwHxHyHzHzH0H1H2H2H7H9H9H-H-H.H.IAIAIBIBICIDIEIGIHILINININIOIQIRIRISIWIWIZIaIdIdIhIiIiIlImInIoIqIqIsIsIwIyIyIzI0I0I4I4I8I9I.JBJBJBJCJCJCJCJGJGJHJJJKJMJPJRJSJUJUJXJXJYJYJZJaJbJdJdJeJfJgJgJnJoJpJpJpJqJsJsJtJuJvJvJxJzJ3J7J-J-J.KAKAKBKCKCKDKEKFKFKGKIKLKMKMKOKPKQKQKRKSKSKSKTKUKVKWKXKaKaKcKjKjKmKrKsKtKuKxKzKzK2K3K3K4K4K5K6K7LALALBLBLELFLGLHLILILMLOLPLRLVLVLaLaLdLeLjLpLpLrLsLvLxLzLzL1L4L4L6L6L8L-MBMBMBMCMGMHMIMJMJMLMUMWMaMcMcMcMgMiMiMmMoMqMvMyM2M2M5M7M8M8M-M.NANMNZNdNoNqNrN0N2OFOGOPOWOcOiOqO6O7PBPDPRPSPhPvPxQeQrQsRQRtSOSUSgTBTVTkUKU9VIWQYWY0ZRZsaNbPbYcEc8dkftmvpTtEuZ4d.7&chxp=0%7C2%2C1155&chxr=1%2C0%2C2570%7C2%2C-128.5%2C2698.5&chxtc=1%2C-720&chco=0000ff&chbh=a&chs=720x415&cht=bhg&chxl=0%3A%7CSuomi%204%20FI%7CDiveo%20MX%7CNetscalibur%20IT%7CTDA%20DZ%7CGlobecomm%20Systems%20A2%7C128.199.248.105%7C192.71.211.211%7CPokoeln%20DE%7C103.241.0.207%7CGaoland-2%20FR-2%7C41.185.78.25%7C103.25.56.238%7C84.200.83.161%7C163.47.20.30%7CFortressITX%20US%7C163.47.21.44%7C103.25.202.192%7CReynwood%20Comm%20US%7C151.236.20.236%7C295.ca-2%20CA-2%7C106.185.41.36%7CChristiania%20DK%7CGradwell-2%20GB%7C213.183.57.55%7Crdsar%20RO%7CIPLAN-2%20AR%7C192.71.218.218%7CTelefonica%20Centroamerica%20SV%7C192.71.247.247%7CAS520.net%20EU%7C178.17.170.67%7CFast%20GB%7CCETIC%20Algeria%20DZ%7COpole%20PL%7CGaoland-1%20FR%7CIsik%20Universitesi%20TR%7CBatelco-2%20JO%7CHamilton%20Hydro%20/%20FibreWired%20CA%7C88.82.109.9%7C31.220.5.106%7CMeganet%20US%7CnFrame-1%20US%7CRDSNet-2%20RO-2%7CGlobal%20Crossing%20snv%20US%7CDNS-Roots%20NYC%20US%7CUnifiedroot-2%20NL%7CCaucasus%20Online%20GE%7C217.78.6.191%7COceanic%20Cable%20US%7CFirmRadio%20UA%7CCodetel%20DO%7CUnifiedroot-1%20NL%7CRDS%20Pitesti%20RO%7CGlobalNet-2%20MT%7C8e6%20Technologies%20US%7CGibNet/Sapphire%20GI%7C151.236.29.92%7CUnifiedroot-6%20NL%7CGibnet/Sapphire-2%20GI%7CSunrise-3%20CH%7CCA-DNS/Verizon-2%20CA%7CVozTelecom%20ES%7CComput%20RU%7CInfoTelecom%20ES%7CSATCOM%20Systems%20A2%7Ceuroweb%20RO%7CInternap-2%20US%7C23.226.230.72%7CSloboda%20UA%7CPlant%20Telecom/InfoAve%204%20US%7CNeo%20ES%7C104.245.33.185%7CInFlow%20San%20Diego%20US%7CFrii-2%20US%7CDPN%20Duss%20DE%7CETB%20CO-3%7CMobtel%20Srbija%20SR%20RS%7C192.71.249.249%7C104.219.55.89%7C62.141.38.230%7CEUItalia%204%20IT%7CAmnet%20Honduras%20HN%7CEUItalia%203%20IT%7CStarnet%20MD%7CG-Tel%20Azteca%20MX%7CMkData%20SE%7CTtnet%2039%20TR%7CDiveo-2%20MX%7CRSSPNet%20RU%7CMiconet%20PL%7CNeterra%20BG%7CETB-2%20CO%7CMovistar-2%20ES%7Cbbsyd%20DK%7CTelusMobility%203%20CA%7CAll2Easy/Modesto%20US%7CHydro%20One%20CA%7C37.187.0.40%7CETB%20CO-2%7CTtnet%2040%20TR%7CADAM%20ES%7CUni-Ljubljana%20SI%7CPLD-2%20US%7C78.47.34.12%7CInfracom%20Network%20Application%20IT%7CCellNet%20BG%7CUltraVPN-2%20FR%7CMT-2%20MK%7CTelcel-1%20MX%7CAirbites%20Lviv-2%20UA%7CTelio-2%20NO%7CDTAG%20L%20DE%7CMaxcom%20MX%7C31.220.43.191%7CRadiant-2%20CA%7CIndigo%20IE%7CProfiber%20DK%7CETB%20CO%7CTelcel-2%20MX%7CBatelco-1%20JO%7C178.79.174.162%7CAPUA%20inet-2%20AG%7CBresnan-2%20US%7Clandsraad%20ES%7CaltoHiway-2%20GB%7CTNG-2%20DE%7CNavega-2%20GT%7CCable.net%20CO%7CUU%20EU%200702%20DE%7CZugernet%20CH%7CBHI-2%20US%7CCesnet%20CZ%7Cxtdnet%20NL%7CAmigo-2%20GT%7CDTAG%20H%20DE%7CBerlin%20CCC%20DE%7CEOL-2%20HU%7C108.61.210.58%7CUni%20Ulm%20DE%7CSWISP-2%20GB%7CWiBand%20CA%7CMindark%20SE%7CCyberus-3%20CA%7CAlharbitelecom%20GB%7CBright/Horizontel%20US%7CHurricane%20Electric%7CAvalonia%20DK%7C95.85.9.86%7CVTX%20Datacomm%20CH%7CUSB%20Skynet%20VE%7CByteCamp-2%20DE%7CMIPPS%20INC%20CA%7CKELCOM/Cybersurf-2%20CA%7CClearwire%20WAR%20US%7CKELCOM/Cybersurf%20CA%7CWIND-2%20IT%7CO2%20Ireland-2%20IE%7CNavega%20GT%7CSWISP%20GB%7CNTT%20EU%20GB%7C69.28.67.83%7CReflact%20DE%7CPLD%20US%7CNefarious%3F%20US%7CClara.net%20DE%7CBlueWin%20CH%7CDTAG-F%20DE%7CUU%20EU%200300%20FR%7CAvalonia-3%20DK%7CNumericable-2%20FR%7CGorgeNet-2%20US%7C104.245.39.112%7CWiTopia%20US%7CSprint%20PCS/brbnca-2%20US%7CTelefonica%20CentroAmerica%20GT%7CSATCOM%20Systems-2%20A2%7Cmtweb/transaria%20US%7CBT%20Alliance/INFONET%20US%7CBluewin%202%20CH%7CAEBC-4%20CA%7CInternap%20US%7CMonzoon%20ZRH-2%20CH%7CAvalonia-2%20DK%7CBluewin-4%20CH%7Calharbitelecom%20GB%7CBsoCom%20FR%7CSvenskaKyrkan%20SE%7COpalSolutions-3%20GB%7CCirque%20DK%7CUU%20EU%20206%7CIndigo%20IE-2%7CTital%20Internet%20GB%7CTime%20Warner%20TOSA-2%20US%7CPaeTec%20Ana-7%20US%7CSpeakeasy%20Seattle%20US%7CCSInet%20US%7CGreat%20Lakes%20Internet%20US%7CMultiband%20Corporation%20US%7CUU%20EU-3%20GB%7CColo4Dallas%20US%7CUU%20EU-201%20NL%7CHerakles%20Sacremento%20US%7CBestel-2%20MX%7CNetworkOnline%20US%7CUU%20EU%20400%7CUnited%20Online%20VGS%20US%7CSprint%20PCS%20Chi-2%20US%7CIntrinsec%20FR%7CEircom-2%20IE%7CTELUS%20Mobility-2%20CA%7CU.%20of%20British%20Columbia%20CA%7CUU%20EU%205a%20GB%7CCox-7%20US%7CRIO%20Networks%20US%7CAmigo%20GT%7CBHI%20US%7CFortalnet%20BR%7CSprint%20PCS%20brbncar12%20US%7CUUnet-EU4%20GB%7CUU%20EU%200703%20DE%7CAirband%20US%7CCityNet%203%20US%7CMonzoon%20CH%7CG-Tel%20Maya%20MX%7CGlobal%20Crossing%20Phoenix-2%20US%7CExceed%20Tech%20US%7CInternap%20Seattle-2%20US%7CInFlow%20ATL%20US%7CU%20of%20Houston-1%20US%7CTriad%20Telecom%20US%7CHorizon%20Cable%20Stinson-2%20US%7CPOBOX%20internet%20GB%7CCox-6%20US%7CO1%204%20US%7CVerizon%20Seattle%20US%7CDynGuide-2%7CPNAP-LON-2%20GB%7CSungard%20Inflow%20US%7CTELUS%20Mobility%20CA%7CACNUSA%7CEU%20BT%20AMS%20NL%7CGigaDNS%20BR%7CNeonova%20Network%20Services%20US%7CVerizon%20Dial-Up%20TX%20US%7CCA-DNS/Verizon%20CA%7CSYS-127.0.0.1%7CGEUS%7CExeculink%20CA%7C295.ca%20CA-2%7CInternap%20Seattle%20US%7CCyberNet%20Comm%20US%7CInterap%20LAX-2%20US%7CHydro%20One-2%20CA%7CUmich%20ITD-2%20US%7CVT%20ISB%20US%7CPrimary%20US%7CU.%20of%20Texas%20at%20San%20Antonio%20US%7CCox%20Oklahoma%20City-2%20US%7CInternap%20LAX%20US%7CMSU%20ATS%20US%7CSpeedNet%20Michigan%20US%7CSprintlink%7CSpirit%20Telecom%20US%7CSprint%20PCS/ekrg-2%20US%7CAPI%20Digital%20US%7CTelwest%20US%7CU%20of%20Houston-2%20US%7CPaeTec%20Chicago%20CA%7CInternap%20SJE%20US%7CVerizon%20NC%20Opt-Out%20US%7CSogetel-2%20CA%7CPathway%20CA%7CInternap%20Denver%20US%7CCybersurf%20CA%7CSprint%20PCS%20Ft.%20Worth%20US%7CEasytel%203%20US%7CSprint%20PCS/atlng%20US%7CDistributel-2%20CA%7CExeculink%20CA-2%7CUU%20Cache-6%20US%7CCable%20%26%20Wireless%20DE-3%7CISP%20Alliance%2C%20INC%20US%7CDnet-3%20US%7CDSL%20Extreme-2%20US%7CInternap%20ACS%20US%7CSBC/AT%26T%20Global-2%20US%7CPNAP%20London%20GB%7CUOL%20BR%7CVerizionBusiness%20US%7CInternap%20Houston%20US%7CCox%20Oklahoma%20City%20US%7CDSL%20Extreme-5%20US%7CSprint%20PCS%20Ft.%20Worth-2%20US%7CMCI-3%20US%7CFlow%20Jamaica-4%20JM%7CSecureDesigns-2%20US%7CDynGuide%7CUnited%20Online%20DCA%20US%7CU.%20of%20Michigan%20US-2%7CWvfiber%20US%7CVerizon%20NY%20Opt-Out%20US%7CAPI%20Digital-2%20US%7CiPrimus%20NJ%203%20US%7CInternap%20CHI%20US%7CBright.net%20US%7CCable%20%26%20Wireless%20DE%7CNetStar%20US%7CTerra-2%20BR%7CYMAX%20US%7CAlma%20Telco-2%20US%7CDnet-4%20US%7CAlma%20Telco%20US%7CUU%20Dial%2060%20US%7CSBC%20Clobal%20TX-2%20US%7CVerizon%20Dallas%20US%7CUltraDNS-2%7CLevel%203/GTEI-2%7CComodo%20Secure%20DNS%7CRadiant%20Alberta%20CA%7CSpeedNet-2%20Michigan%20US%7CEarthlink%20Opt-Out%20US-2%7CUU%20Cache%20US%7CMetConnect-1%20US%7CEarthlink%20Opt-Out%20US%7CUU%20Cache-2%20US%7CQwest-2%20US%7CAccess%20Northeast%20US%7CIntap%20US%7CComodo%20Secure%20DNS-2%7CVideotron%20Phone-4%20CA%7CUU%20Cache-7%20US%7CVerizon%20Boston%20US%7CInternap%20WDC%20US%7CTDS%208%20US%7C1scom%20US%7CVerizon%20NC%20US%7CEarthlink%20Ms%20US%7CNTT-2%7CInternap%20CHG%20US%7CQwest%20Redirect%20US%7CUU%20Cache-5%20US%7CSBC/AT%26T%20Global%20US%7CCIMCO-2%20US%7CLevel3-R2%7CUU%20Cache-4%20US%7CNorton%20DNS-2%20US%7CUU%20Cache-3%20US%7CBullEye%20Telecom%20US%7CCIMCO%20US%7CQwest%20US%7CWtechlink/Pacinfo/AT%26T-2%20US%7CInternap%20CHG-2%20US%7CUU%20Cache-2%20US-2%7CInternap%20Boston%20US%7CInternap%20Philadelphia%20US%7CWtechlink/AT%26T-2%20US%7CInternap%20NYC-2%20US%7CLevel3-R1%7CRCN%20ATW-2%20US%7CCogent%20WDC%20US%7CVerizon%20Philadelphia%20US%7CLevel%203/GTEI-4%7CAT%26T%20ASM%20US%7CSBC%20San%20Diego%20US%7CAT%26T%20New%20Orleans%20US%7CInternap%20NYC%20US%7COpenDNS%7COpenDNS-3%7CGenuity%20BAK%7CGoogle%20Public%20DNS-2%7CGoogle%20Public%20DNS%7C1%3A%7C0%7C320%7C640%7C960%7C1280%7C1600%7C1920%7C2240%7C2560%7C2570%7C2%3A%7CDuration%20in%20ms.
The whole HTML file I have uploaded here.
Created a fiddle with your code.
From the google developers image charts documentation
Specifying your chart as a URL in your browser or an tag is
called a GET request. Making a GET request is simple, but GET URLs are
limited to 2K characters. What if you have more data than that?
Luckily, the Chart API supports HTTP POST for chart requests up to 16K
long. The trade-off is the added complexity of using POST.
The first solution becomes using a POST . The link also contains examples of POST using either a form element, javascript or php.
The URL length limitation -
The maximum length of a URL is not determined by the Google Chart API,
but rather by web browser and web server considerations. The longest
URL that Google accepts in a chart GET request is 2048 characters in
length, after URL-encoding (e.g., | becomes %7C). For POST, this limit
is 16K.
The second solution: The same link provides the next type of solution, which is actually reducing the URL length :
If you are using a text encoding data format, remove leading zeros from numbers, remove trailing zeros after decimal points, and round or truncate the numbers after decimal points.
If that does not shorten the URL enough, use simple (1 character) or
extended (2 character) encoding.
Sample data less frequently; i.e., reduce granularity.
Remove accoutrements and decorations, such as colors, labels, and
styles, from your chart.
The first solution
This one applies for the first 2 charts , which have around 8000 characters which fit in a POST request (<16000):
<h2>Mean Response Duration</h2>
<h3>Fastest Individual Response Duration</h3>
i.e. you will have to write a POST through one of the methods described.
The second solution
This applies for the last 2 charts for which you get a 413 (Request Entity Too Large) status on get. These last 2 characters have around 20 000 characters, and the last 60 000 characters.
<h3>Response Distribution Chart (First 200ms)</h3>
<h3>Response Distribution Chart (Full)</h3>
Here you will indeed need to make the URL shorter through one of the methods advised. That is, shorter than 16000.
For testing purposes you could use a form such as this and change the parameters with what you need. Working fid
<form action='https://chart.googleapis.com/chart' method='POST' target="graph_target">
<input type="hidden" name="cht" value="lc" />
<input type="hidden" name="chtt" value="This is | my chart" />
<input type='hidden' name='chs' value='600x200' />
<input type="hidden" name="chxt" value="x,y" />
<input type='hidden' name='chd' value='t:40,20,50,20,100'/>
<input type="submit" />
</form>
<iframe name='graph_target' src='' style='width:600px;height:200px;'></iframe>
<script type="text/javascript">
document.forms["graphform"].submit();
</script>
I have a CMS written in ASP.NET using VB.NET and I am having problems saving Unicode characters to the database. Here's the situation:
The web page seems to send the characters fine via an AJAX request (using jQuery), at least according to Firebug it seems that the POST is sent fine I can see the characters in there as they should be (ie, not screwed up). When I look in the database instead of the non-english character I see a questionmark inside the little black diamond, you know the character. I know it's not the database since a) the field is set to NText and b) I can insert that same value directly into the DB via SQL Manager in a manual query. The database is MS SQL 2005.
So the problem must be in between, correct? I am specifically declaring the param on the insert query as NText:
Cmd.Parameters.Add("#FieldContent", SqlDbType.NText).Value = FieldContent
and in web.confing I have encoding set as:
<globalization requestEncoding="utf-8" responseEncoding="utf-8" />
I've googledhigh and low and cannot find any other solutions than the ones I've tried already. Any help is greatly apreciated.
try
cmd.Parameters.Add("#FieldContent", SqlDbType.NVarChar, 1024).Value = FieldContent;
I am looking at a bug in WebSVN where when I get into a file log and click on compare, it looses the repository name as part of the request. The details are unimportant.
However, I've tracked down the bug to a http form that looks like this:
<form method="get" action="comp.php?repname=Binaries&" id="compare">
....
<input type="hidden" name="KEY" value="VALUE">
Is this supposed to work? Will both the "repname" argument, specified as part of the URL, and the hidden value be sent? It seems Chrome 4.1 only sends the hidden argument, and removes the repname parameter altogether. Is this correct?
I fixed it temporarily, pending more information, by adding another hidden field for repname with the same value, and now everything works, I'm just wondering if Chrome or WebSVN is in fault here.
you should remove the & from the end of the action value, that will likely just cause you trouble. if you need to pass an ampersand through, you should url-encode it as %26
edit: you should definitely do it the way you fixed it - by passing repname as another hidden variable - since some browsers do have weird behaviour when dealing with explicit and implicit url vars in a get :)
I'm having a weird issue with an input type hidden and was wondering if anyone has ever seen something like this before. I'm saving about 2MB of data to a hidden field, in a comma separated format, then I'm posting that data to a jsp that simply sets some headers (so the output is recognized as an excel file) and then echoes the data.
I'm seeing that the variable that holds this data gets empty to the jsp side, even though I see that it's getting posted to the server (I'm seeing it with an HTTP sniffer) and all data seems to be contained correctly in the hidden field (I'm seeing that with firebug). However, if I change the object type to be a text area, the data is received correctly on the server's side.
Another weird thing I'm observing is that if I use URL encoding on the data, even using a text area, nothing gets to the server. If I don't use URL encoding but I have the hidden field, nothing gets saved to the field (it's empty when I check it with firebug). I don't understand that either...
I'm wondering if there is any special security setting that prevents the hidden fields to post big amounts of data to a Tomcat web server. Does anybody know anything about that?
If it makes any difference, I'm using the default enctype on the form (application/x-www-form-urlencoded)
I'm currently using a text are and setting the style to visibility "hidden" but it bothers me not to understand what's going on *sigh... Any suggestion is appreciated
I think having 2MB of data in a hidden field is a mistake regardless. You should store that kind of thing on the server as part of the session state, not send it back and forth between the server and the user, as you are doing. Instead, use a hidden field or cookie for the session variable*, which will be used to look up the 2MB of data.
*Don't do this by hand. JSP already has support for session state, among other things.
The server can't tell the difference between a textarea and textbox. All form elements are simply posted as name/value pairs.
Most likely, you have a double-quote somewhere in your data that's terminating the value attribute of the hidden input element. For example:
<input type="hidden" value="Double " quote" />
You need to escape the double-quotes by replacing them with "
<input type="hidden" value="Double " quote" />
I'm building a listing/grid control in a Flex application and using it in a .NET web application. To make a really long story short I am getting XML from a webservice of serialized objects. I have a page limit of how many things can be on a page. I've taken a data grid and made it page, sort across pages, and handle some basic filtering.
In regards to paging I'm using a Dictionary keyed on the page and storing the XML for that page. This way whenever a user comes back to a page that I've saved into this dictionary I can grab the XML from local memory instead of hitting the webservice. Basically, I'm caching the data retrieved from each call to the webservice for a page of data.
There are several things that can expire my cache. Filtering and sorting are the main reason. However, a user may edit a row of data in the grid by opening an editor. The data they edit could cause the data displayed in the row to be stale. I could easily go to the webservice and get the whole page of data, but since the page size is set at runtime I could be looking at a large amount of records to retrieve.
So let me now get to the heart of the issue that I am experiencing. In order to prevent getting the whole page of data back I make a call to the webservice asking for the completely updated record (the editor handles saving its data).
Since I'm using custom objects I need to serialize them on the server to XML (this is handled already for other portions of our software). All data is handled through XML in e4x. The cache in the Dictionary is stored as an XMLList.
Now let me show you my code...
var idOfReplacee:String = this._WebService.GetSingleModelXml.lastResult.*[0].*[0].#Id;
var xmlToReplace:XMLList = this._DataPages[this._Options.PageIndex].Data.(#Id == idOfReplacee);
if(xmlToReplace.length() > 0)
{
delete (this._DataPages[this._Options.PageIndex].Data.(#Id == idOfReplacee)[0]);
this._DataPages[this._Options.PageIndex].Data += this._WebService.GetSingleModelXml.lastResult.*[0].*[0];
}
Basically, I get the id of the node I want to replace. Then I find it in the cache's Data property (XMLList). I make sure it exists since the filter on the second line returns the XMLList.
The problem I have is with the delete line. I cannot make that line delete that node from the list. The line following the delete line works. I've added the node to the list.
How do I replace or delete that node (meaning the node that I find from the filter statement out of the .Data property of the cache)???
Hopefully the underscores for all of my variables do not stay escaped when this is posted! otherwise this._ == this._
Thanks for the answers guys.
#Theo:
I tried the replace several different ways. For some reason it would never error, but never update the list.
#Matt:
I figured out a solution. The issue wasn't coming from what you suggested, but from how the delete works with Lists (at least how I have it in this instance).
The Data property of the _DataPages dictionary object is list of the definition nodes (was arrived at by a previous filtering of another XML document).
<Models>
<Definition Id='1' />
<Definition Id='2' />
</Models>
I ended up doing this little deal:
//gets the index of the node to replace from the same filter
var childIndex:int = (this._DataPages[this._Options.PageIndex].Data.(#Id == idOfReplacee)[0]).childIndex();
//deletes the node from the list
delete this._DataPages[this._Options.PageIndex].Data[childIndex];
//appends the new node from the webservice to the list
this._DataPages[this._Options.PageIndex].Data += this._WebService.GetSingleModelXml.lastResult.*[0].*[0];
So basically I had to get the index of the node in the XMLList that is the Data property. From there I could use the delete keyword to remove it from the list. The += adds my new node to the list.
I'm so used to using the ActiveX or Mozilla XmlDocument stuff where you call "SelectSingleNode" and then use "replaceChild" to do this kind of stuff. Oh well, at least this is in some forum where someone else can find it. I do not know the procedure for what happens when I answer my own question. Perhaps this insight will help someone else come along and help answer the question better!
Perhaps you could use replace instead?
var oldNode : XML = this._DataPages[this._Options.PageIndex].Data.(#Id == idOfReplacee)[0];
var newNode : XML = this._WebService.GetSingleModelXml.lastResult.*[0].*[0];
oldNode.parent.replace(oldNode, newNode);
I know this is an incredibly old question, but I don't see (what I think is) the simplest solution to this problem.
Theo had the right direction here, but there's a number of errors with the way replace was being used (and the fact that pretty much everything in E4X is a function).
I believe this will do the trick:
oldNode.parent().replace(oldNode.childIndex(), newNode);
replace() can take a number of different types in the first parameter, but AFAIK, XML objects are not one of them.
I don't immediately see the problem, so I can only venture a guess. The delete line that you've got is looking for the first item at the top level of the list which has an attribute "Id" with a value equal to idOfReplacee. Ensure that you don't need to dig deeper into the XML structure to find that matching id.
Try this instead:
delete (this._DataPages[this._Options.PageIndex].Data..(#Id == idOfReplacee)[0]);
(Notice the extra '.' after Data). You could more easily debug this by setting a breakpoint on the second line of the code you posted, and ensure that the XMLList looks like you expect.