I posted something a few days ago but got no response. I need to compose,
submit and parse the resulting XML document.
Delphi does support this right? If so can someone please offer a clue
here..
Thanks
--
Reid Roman
Future Generation Software
http://www.fgsoft.com
re...@fgsoft.com
yes. rtfm
Grahame
Gurb
--
Reid Roman
Future Generation Software
http://www.fgsoft.com
re...@fgsoft.com
"Reid Roman" <re...@fgsoft.com> wrote in message
news:3dfe...@newsgroups.borland.com...
>I have D5 .. Crap
So do I. If you have a recent version of IE installed, you have the
MSXML library installed on your box. In the D5 IDE select
Components|Import ActiveX Control. From the dialog's pick list select
the MSXML control and follow the directions. The controls will be
found on the ActiveX page.
There is no need or advantage for me to use the components. Using
MSXML_TLB.pas allows me to dynamically create interfaces for
everything I need.
var
doc: IXMLDomDocument;
begin
doc := CoDomDocument.Create;
try
...
finally
doc := nil;
end;
end;
regards
A.G.
Thanks for the reply.
I have imported the Type Library for MSXML 3.0 and have the newly created
unit in the application's folder and included it in the main form's uses
clause.
I have been able to compile calling the LoadXML() method so I assume it is
fine at this point.
procedure TForm1.FormCreate(Sender: TObject);
begin
doc := CoDomDocument.Create;
try
doc.loadXML('rate estimate resp example.htm');
finally
doc := nil;
end;
end;
I am a bit confused as to how to tap into the necessary methods when the
parser is working. I am new to XML but the book I am reading (Beginning XML
2nd Edition by WROX ISBN: 1-861005-59-8) shows examples in VB and Java where
they tap into the StartElement(), EndElement() , Warning(), Error(),
FatalError() methods.
How do I incorporate these handlers into my project using the Type Library?
Or do I do it differently the Delphi way?
Can you please offer some more assistance here?
Thanks
--
Reid Roman
Future Generation Software
http://www.fgsoft.com
re...@fgsoft.com
"Registered User" <n4...@subdevo.com> wrote in message
news:80muvugq0tc12ia2r...@4ax.com...
regards
A.G.
On Tue, 17 Dec 2002 11:17:12 -0800, "Reid Roman" <re...@fgsoft.com>
wrote:
>Hello,
or else you can use OpenXML. see http://www.philo.de/openxml
or you other choices. See http://xml.defined.net
Grahame
Something Mark Edington wrote about volumes in the "XSD.exe for Delphi"
thread is worth noting
"For applications which manipulate large amounts of data or are performance
sensitive I wouldn't recommend using a
data binding [a Delphi 6 and above feature](or even a DOM). SAX is a good
option for those situations but
it's not as convenient from a coding perspective."
If you don't need random access to the data in the XML then SAX is the way
forward, it appears the book you have is referring to Microsoft's SAX
parser.
You can continue down that route by either importing the COM components into
Delphi or using Keith Wood's MSXML SAX interfaces which can be found (bottom
of the page) on Jeff Rafter's site at http://xml.defined.net/SAX/
Alternatively you could use the DOM, which through the use of XPath allows
random access, (especially using Microsoft's extension method selectNodes
and selectSingleNode) and an object like oriented API.
To learn how to use the MSXMLs DOM in Delphi read the short tutorial by Bin
Ly here http://www.techvanguards.com/stepbystep/msxml/hellomsxml.asp.
That should be enough to get you going,
Gurb
See Keith Wood's MSXML SAX interfaces (bottom of the page) at
http://xml.defined.net/SAX/
Gurb
I did D/L and install Keith Wood's Delphi components for this, installed
them and the SAX compiler available on that site. There just seems to be a
lack of documentation (or I cannot find it) so I did no get very far. I
did drop a TSaxReader component on the form, Content Handler, etc and link
them up, and chose the MSXML as the parser, but when I ran it, it threw an
"Unknown Parser" exception.
I do have Microsoft's MSXML Parser v3.0 on my machine and am unclear how to
get that going.
But if I could I would just use these components because I see they have the
handlers in place that I need.
For me I do not need a large or complicated implementation of the API or
parser. In this project the client needs to interface with their shipping
vendor's Web Service with XML to get real time shipping rates. The document
or request that gets submitted is very small and will generally contain only
a few variations in the value for the elements. The response document will
be modeled the same and I just need to parse it for the resulting shipping
rate or any error codes.
So at this point I am just trying to find the shortest distance to
completion and not trying to reinvent the wheel or create a well rounded
component wrapped around XMLParsing etc.. I just want to be able to create,
submit and parse the responding XML document.
I would like to have a component that just contains the
StartDocument(),
EndDocument(),
StartElement(),
EndElement() ,
and Error Handlers.
I can then write the code in these handlers to act on the elements that I
need to get the shipping rates.
Thank again for your kind insights.
so why not use soap?
Grahame
IndySoap
http://www.nevrona.com/indy/soap
I did take a look at IndySoap and found two things:
1) There is no documentation other than a Yahoo mailing list.
2) The demos that come with it do not seem to display anything simple to
build on.
3) It seems sort of proprietary.
I do appreciate the help on this that you are and others are providing but
at this point the only thing that I have gotten to work somewhat is the
components at :http://xml.defined.net
I have managed to at least get it to parse the contents of an XML file. I
just need to now try and figure out how to send one and wait for the
response.
In the book I am reading it almost seems like just a small implementation of
the DOM would work in my case. I could manually write a Delphi routine to
build the XML file. The example shows how to do it from a JavaScript
handler in a web page.
I would really rather find a commercial suite that had great help, support
and go from there. Time is off the essence right now so I need something
real user friendly.
Again, at this point if I could just manually create the XML file and do
some generic HTTP post to a certain URL, and then read back the HTTP
response I could write my own parsing routine.
Thanks
--
Reid Roman
Future Generation Software
http://www.fgsoft.com
re...@fgsoft.com
"Grahame Grieve" <gra...@kestral.com.au> wrote in message
news:6e15d-...@melblink.kestral.com.au...
well, I know a little about it, and yes, what you are trying
to do is actually SOAP
> I did take a look at IndySoap and found two things:
>
> 1) There is no documentation other than a Yahoo mailing list.
well, there is doco in the download package. I spent lot's of
time writing it
> 2) The demos that come with it do not seem to display anything simple to
> build on.
yes, and SOAP is not easy to get into either
but the tutorials should set you going....
> 3) It seems sort of proprietary.
well, it is proper open source.
> I would really rather find a commercial suite that had great help, support
> and go from there.
I don't think you'll have any luck. http://www.remobjects.com
is commercial, and they are keen to offer support on
borland.public.delphi.webservices.soap, but I can't speak for
how easy it is to use
Grahame
agree
> SOAP may be a solution for your project, but in my personal opinion it is
> still a very immature technology. If you get the time read about it then do
> and ask yourself some simple questions such as what happens when the web
> service's interface change, how do you inform your clients, what about
> security, again how do you inform your clients which model you're using
> How do you get a client to pay for using your webservice?
those comments are all true, but the outcome is the same
whether you are using XML+http or a SOAP toolkit. In fact,
IMHO, using a SOAP toolkit is preferable since you can look
to the toolkit for standard answers to these questions.
(err, that is, if it is updated and standard...)
> If it's a
> standard then why isn't there a standard way to achieve any of the
> aforementioned?
There all proposed standards for all of these questions,
it's a matter of waiting to see whether any of them
get adopted. most are from ebXML which has taken a little
timeto re-orient to web services but is going there big
time now
Grahame
Here instead you would use "Load". Load( ) takes a file name and LoadXML( )
takes an XML string.
doc.loadXML('<root><child></child></root>');
or
doc.loadXML('myfile.xml');
Note-- HTML is not necessarily the same as XML. The only time that it is the
same is if you are dealing with XHTML-- I am guessing this is not the case.
> I am a bit confused as to how to tap into the necessary methods when the
> parser is working. I am new to XML but the book I am reading (Beginning
XML
> 2nd Edition by WROX ISBN: 1-861005-59-8) shows examples in VB and Java
where
> they tap into the StartElement(), EndElement() , Warning(), Error(),
> FatalError() methods.
This is why I thought I should get invloved <G/> I would stick with MSXML if
you have the type library in. DOM is definitely easier to start with. To
post and get, I would just use HTTP to start with if possible. Save
Webservices and SOAP for another day or another toolkit.
var HTTP : IXMLHTTPRequest;
begin
HTTP:= CoXMLHTTP.Create;
XMLDoc:= CoXMLDomDocument.Create;
try
HTTP.Open('GET', 'http://somewhere.com/something.asp', false, '', '');
HTTP.Send(''); // here you can actually send a whole document if you are
posting
// Check the process
if (HTTP.status <> 200) then
raise Exception.Create('There was an error processing : ' +
HTTP.statusText);
// Load the document response if it is XML
XMLDoc.LoadXML(HTTP.responseText);
// Check for errors
if (XMLDoc.parseError <> nil) and (XMLDoc.parseError.errorCode <> 0)
then
raise Exception.Create('Loading XML File - ' +
XMLDoc.parseError.reason + ' Line ' + IntToStr(XMLDoc.parseError.line) + '
Column ' + IntToStr(XMLDoc.parseError.linepos));
finally
HTTP:= nil;
XMLDoc:= nil;
end;
end;
Don't mix up SAX and DOM as you work. Focus only on the DOM chapter for
now-- that way you do not need to worry about StartElement etc. You need to
use the DOM functions such as documentElement, createElement,
createTextNode, appendChild and the like.
HTH,
--
Jeff Rafter
Defined Systems
http://www.defined.net
XML Development and Developer Web Hosting
Thank you both for these latest posts.
With these opinions and examples I will indeed go the DOM route and save the
more complicated SAX and SOAP models for another day.
Thanks Jeff for taking the time to code an example of posting and retrieving
the XML document.
Thanks for the reply. I did not find the "doco" docs on the link provided.
(http://www.nevrona.com/indy/soap) I am for the time being going to go the
DOM way for the sake of simplicity and as time prevails build or implement a
more powerful solution.
One notable absence from the ebXML group of supporters is Microsoft. My bet
is that none of what ebXML propose will be adopted by Microsoft. If ebXML
do provide something worthwhile, Microsoft will produce their own
incompatible version.
Most groups, such as ebXML and especially the W3C these days need
Microsoft's support if any of their specifications are to become more than
just pie in the sky ideas thrashed out by a bunch of academics.
Gurb
That's not the same picture I get from the Microsoft
standards people when I meet with them. ebXML does
not have their focus (they don't provide solutions,
after all) but I wouldn't have considered them as
non-supporters.
Grahame