I'd also agree with using text reader, but if you did go the regex route,
I've heard compiled regex's are quite a bit faster. Not sure if that is what
you were testing...
Cheers,
Robin
- Original Message -
From: "Larry O'Brien" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, Fe
I see a problem here, in that most of the time in the regex example is spent
compiling the regex itself.
If you change the regex to be a cached static, like this:
private static IDictionary regexes = new Hashtable();
static ParsingTechnique() {
regexes[ "firstName" ] = new Regex(String.Format("
Hi All,
Does VS.NET support the concept of a CustomTool or CodeGenerator that
generates multiple *.cs files (and possibly other files too) from a single
input file?
If not, what feature of VS.NET can I use to allow me to:
1) execute a commandline app to create multiple files a build or run is
req
Public bool AssemblyInGac(string AssemName, out string AssPath)
{
bool bRV=false;
System.Reflection.Assembly assem =
System.Reflection.Assembly.LoadWithPartialName(%your_assembly_name%);
If(System.RunTime.InterpoServices.RuntimeInviroment.FromGlobalAccessCa
che(assem)
{
Kamen Lilov [mailto:[EMAIL PROTECTED]] wrote:
> If we only had a decent implementation of SAX, things would
> be so much = more different. XML structures like this tend
> to perform lightning-fast with streaming parsers and not so
> well with DOM implementations...
You do, it's a pull model inst
Hi Larry,
Like most other who responded before me, I'd go the XML route. With one
twist, however: if you are dealing with large data sets, this will be a
memory hog.
If we only had a decent implementation of SAX, things would be so much more
different. XML structures like this tend to perform l
Hi,
I've been using a ConfigFileReader class to suppport per dll .config files.
As long as my assembly was not in the gac I could retrieve the file
successfully using this call:
Assembly.GetExecutingAssembly().CodeBase + ".config"
e.g. c:\myAssembly.dll.config
After putting myAssembly in the gac,
XmlTextReader looks like the clear winner in terms of performance:
Reg Ex: 00:00:00.3805472
XMLTextReader: 00:00:00.1702448
XPathNavigator: 00:00:00.3104464
Thanks for the thoughts!
Larry
using System;
using NUnit.Framework;
using System.Xml;
using System.Xml.XPath;
using System.Text.Re
here is a possibly legit scenario ...
CF .NET does not support XPath,
and DataSets are slow on small devices.
One possibility might be to do a regex 1st,
for the lack of XPath,
and then do an XmlReader on the result set.
_
casey
http://www.brains-N-brawn.com
-Orig
You could use an XSLT transform to get to a more consistent version of
the xml and load your customer data from that. An XSLT transform would
be better suited to matching XML than RegEx.
e.g.
http://www.w3.org/1999/XSL/Transform";>
Would yield:
I have to agree. Between the sheer speed of xpath queries and the XPathNavigator
class, I would stick to xpath. I've queried some big documents using the
XPathNavigator and the results come back instantaneously.
Not to mention, in a couple of years it will be easier for future programmers work
Eric Gunnerson [mailto:[EMAIL PROTECTED]] wrote:
> My vote would be "Yes".
+1.
> My experience with using Regex on XML is that it's a pain to
> get things parsed apart. I think it's much much easier to use
> XmlDocument and then traverse the nodes to get what you want.
I don't even think he nee
My vote would be "Yes".
My experience with using Regex on XML is that it's a pain to get things
parsed apart. I think it's much much easier to use XmlDocument and then
traverse the nodes to get what you want.
As for performance, I'm not sure. Regex may be faster, but the XML
parser is pretty quic
I am working with well-formed but non-validated (no DTD, no schema)
computer-generated XML. My task is to make consistent objects from a
large number of these mainframe-generated strings; for instance, one
call might generate the XML
"AaronBobAmundsenBickerson" and another call might generate
"Aaro
Ok. I found the problem. I forgot to mention 2 things. One is that I
also have the ISerializable interface - not to big a deal. The other is
that I am running Everett Final Beta, v1.1.4322. There is a config file
setting under called . Adding
this fixed my problems. The settings for it are
If you want to return more than one validation error, then instead of boolean flag you
need to create a collection and add each
validation error as they occur. A more robust implementation than the one I'm showing
below would be to create your own Exception
type that has a string array of Validat
>>>Perhaps somebody can contradict me but most parsers fail on the first error
because<<<
How 'bout a clarification instead of a contradiction?
If you have not hooked the ValidationEventHandler, the XmlValidatingReader will fail
on the first error (and throw an exception) as
you surmise. However
17 matches
Mail list logo
