#115947 - 2004-03-11 05:31 PM
Re: XML Support
|
Kdyer
KiX Supporter
Registered: 2001-01-03
Posts: 6241
Loc: Tigard, OR
|
Isn't XML just text? Or, am I missing your point?
Kent
|
Top
|
|
|
|
#115954 - 2004-04-05 05:53 PM
Re: XML Support
|
Chris S.
MM club member
Registered: 2002-03-18
Posts: 2368
Loc: Earth
|
Quote:
How else is KiX supposed to seperate itself from the pack and modernize itself without growing in size and functionality?
...as far as XML support goes? I'd say by utilizing the COM functions that other scripting/programming languages use. I can't think of any languages that natively support XML now.
Here is an example of using the XMLDOM...
Code:
Break On $xml = ' <remoteDir> <dir>1394</dir> <dir>backoffice</dir> <dir>Clients</dir> <dir>distapps</dir> <dir>exchange</dir> <dir>GEN_INFO</dir> <dir>IIS</dir> <dir>lanman</dir> <dir>mail</dir> <dir>mcis</dir> <dir>mspress</dir> <file> <name>readme.txt</name> <size>1715</size> <lastModTime m="5" d="20" y="1996" hh="0" mm="0" ss="0" /> </file> <file> <name>ReadMe1.txt</name> <size>2107</size> <lastModTime m="7" d="2" y="2002" hh="0" mm="0" ss="0" /> </file> <dir>sitesrv</dir> <dir>sql</dir> <dir>Sysmgrsrv</dir> <dir>utilities</dir> <dir>viper</dir> <dir>winnt</dir> <dir>WinSock</dir> </remoteDir>' $xmlDoc=CreateObject("Microsoft.XMLDOM") $xmlDoc.async="false" If $xmlDoc.loadXML($xml) For Each $x in $xmlDoc.getElementsByTagName("dir") $x.nodename + ": " + $x.text ? Next For Each $x in $xmlDoc.getElementsByTagName("file") $x.nodename + ": " + $x.childNodes(0).text + " | " + $x.childNodes(1).text + " | " + $x.childNodes(2).getAttribute("y")+"/"+$x.childNodes(2).getAttribute("m")+"/"+ $x.childNodes(2).getAttribute("d") ? Next EndIf
By the way, a very good online tutorial of XMLDOM can be found at W3Schools.
|
Top
|
|
|
|
#115958 - 2004-04-06 10:31 AM
Re: XML Support
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
More importantly on this and similar issues is where it makes sense for the support of things like XML to be.
As you quite rightly pointed out, KiXtart can interface with COM automation quite successfully with a couple of notable exceptions.
This has two major benefits. Firstly, there only needs to be one implementation for the support of a feature.
If you take XML as an example, would you expect the coders of Word, Excel, Internet Explorer and so-on to write their own XML parsers and handlers? Of course not, it would be mad. Instead a library is developed, the API is published and any application which needs XML parsing uses the library.
The second major benefit of doing this ways is about who maintains the code. Is it really a good idea for Ruud to have to add massive complexity to KiXtart for something which is at present of limited need just to make the interface simpler? Something that he may well not have expert knowledge in.
No. It is much better for the XML experts to maintain, bug-fix and enhance the XML support libraries.
Ruuds time is better spent developing the core of KiXtart and adding features which enhance the scripting language, rather than adding functionality which is already available.
As a guide, I usually review enhancement requests and fit them into loose categories:
- Very Good This is something which would benefit most people, but more importantly is it something which can only be achieved by a change in the scripting language. Some examples are static variables, pass by reference, input/output redirection and support for binary data.
- Good Again, most people would benefit. These are requests which would provide support for facilities which can already be handled by UDFs and COM but should probably be part of the core language. Things like mathematical functions, date handling, pattern matching, associative (hash) arrays.
- Not so good This category is for those things which don't really belong in KiXtart. It may be because they are so esoteric that very few people will use the feature. More often it is because the feature is available by another method such as via the COM automation and it is appropriate for it to remain that way. Examples of this are network (socket) programming, HTTP, Email, database and LDAP.
Not everyone will agree with me, but I think that XML support sits quite firmly in the last category.
|
Top
|
|
|
|
#115959 - 2004-04-06 04:45 PM
Re: XML Support
|
jtokach
Seasoned Scripter
Registered: 2001-11-15
Posts: 513
Loc: PA, USA
|
Richard, what you say makes great sense and couldn't agree with you more. Where we disagree is with the categorization of extended functionality such as XML. And quite honestly I think the community takes this Suggestions forum far too seriously, such as to assume that every suggestion should be included in the next release. XML is growing in popularity at an immense rate. By making the suggestion that this should be included, I’m suggestion it would be nice to see it in the future; preferably within a year.
Given the way you designated XML support to be non-value added would be stating that Ruud’s decision to include support for .INI parsing was also non-value added and more of a nicety. Personally, I can remember times where not having such functionality would have made my life a whole lot more difficult and I’m certain that I’m not alone here.
If KiXtart is a tool designed for administrators, (read: not programmers) and its development path remains focused on that philosophy, and XML will replace the current methods in which applications operate, would it not make better sense to have native support for this built into the language so the administrator can quickly accomplish his task? We’re talking about minutes of referencing the manual as opposed to a few hours deciphering the COM interface.
And finally, regarding Ruud’s time, I agree with you. I’d much rather have a completely working COM interface than support for .XML right now. I merely came to offer a suggestion.
_________________________
-Jim
...the sort of general malaise that only the genius possess and the insane lament.
|
Top
|
|
|
|
#115960 - 2004-04-06 05:40 PM
Re: XML Support
|
Richard H.
Administrator
Registered: 2000-01-24
Posts: 4946
Loc: Leatherhead, Surrey, UK
|
Without delving into ancient history INI support is an early feature when KiXtart was a simple login scripting language.
COM automation has developed in later version of KiXtart as it has progressed - it wasn't available in early versions.
It is not that XML support has no value per se, it is simply that building XML support into KiXtart has little added value at the expense of making KiXtart bigger, slower and more difficult to maintain. IMO simply adding API wrappers to KiXtart is just not a very good reason.
Suggestions here get debated by the community and distilled to something which is in a form that can be put forward to Ruud. This peer review process is vital to ensure that the request is beneficial to the community as a whole and is at it's clearest and most concise - the more noise there is around a suggestion the more likely it is to be heard
|
Top
|
|
|
|
#115964 - 2004-09-28 03:39 AM
Re: XML Support
|
cj
MM club member
Registered: 2000-04-06
Posts: 1102
Loc: Brisbane, Australia
|
hehe, now here's a can of worms we should re-open
cj
p.s. ooh, only 9 more posts to the ton!
|
Top
|
|
|
|
Moderator: Lonkero, ShaneEP, Jochen, Radimus, Glenn Barnas, Allen, Ruud van Velsen, Mart
|
0 registered
and 465 anonymous users online.
|
|
|