Jump to content

wahlers

Members
 View Profile  See their activity

  • Posts

    13

  • Joined

  • Last visited

 Content Type 

Everything posted by wahlers

  1. wahlers
    Yeah...well done! You noticed By the way...I am Dutch...but the word game above was no mistake, I know what 'bs' stands for.Regards, Wim.
  2. wahlers
    Boen_robot,Thanks again for your information. I was not familiar with the term "data islands"in this context.I have a different background (mainframe; core application programmer).Anyway, my knowledge of (X)HTML/XML is rudimentary and my knowledge of microsoft-anything is, basically, non-existent!I will ponder over, explore and exploit your information. Thanks for your time.Regards, Wim Ahlers.
  3. wahlers
    boen_robot,Thanks for your reaction.So, if I understand correctly, text is possible, but for atributes like links and images it isn't.By the way, when I said "the web page does display the data of the XML file correctly in the various web browsers", I merely meant the latest releases of the most commonly used web browers used by my target audiance (a specific organization!).I did not mean all relaeses of all web browsers used by everybody.My apologies for the for the misunderstanding created by me.If I understand correctly, the only solution to create and control, as you call it, these "data islands" is to use a scripting language on either the client or the server side (your suggestion is javaScript on the client side...or [i guess!?!] php on the server side).In that case I opt for a server side solution in an attempt to be as transparant as possible for the client side (no dependencies - just using the browser as a 'dumb' terminal for displaying static web pages).However, if there is somebody who has an other solution for these kind of "data islands" than I am sure interested in the solution...Regards, Wim Ahlers.
  4. wahlers
    Description:While creating XHTML web pages I try to separate the data likely to change (such as for instances addresses) from the more stable contents (such as logo's, general descriptions and the like).The idea is to separate the data that is likely to change on a regular basis from the main pages.And separate this data for ease of maintenance and and ease of updates using (coded) interfaces.This can be accomplished in several ways, of course, like storing this data in a database and use some kind of script language to built the page on the server side.But for various reasons I decided to exploit some other solution as explained in the following. Create static XHTML source. Read XML file with specific user data into this static XHTML source. Create update facilities for the user with controlled access and authorisation through the internet on these XML files (and only these files). phase 1 is creating the static XHTML and XML files ( a + b ) .phase 2 is designing, defining and coding the access update authorisation for these specific user data (later!).I have some problems and questions about phase 1...as illustrated by the example following.Example code:The web page (simplified!), displaying an address: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>example : loading (semi-)variable data using "src=", "datasrc=" and "datafld="</title></head><body><div> <xml src="./exampleContactAddress.xml" id="contactAddress" ></xml> <strong> Our department: </strong> <span datasrc="#contactAddress" datafld="department"></span> <p><strong> Our address: </strong><br /> <span datasrc="#contactAddress" datafld="name"></span><br /> <span datasrc="#contactAddress" datafld="street"></span><br /> <span datasrc="#contactAddress" datafld="postalcode_place"></span> </p> <p> <strong> Email: </strong> <span datasrc="#contactAddress" datafld="mailURL"></span> </p> <p> <strong> Phone: </strong> <span datasrc="#contactAddress" datafld="phone"></span> </p></div></body></html> The XML file read into the web page:(name of XML file must be as coded in the XHTML file, that is, the name must be: "exampleContactAddress.xml") <?xml version="1.0" encoding="ISO-8859-1"?><contactAddress xmlns:xlink="http://www.w3.org/1999/xlink"> <department>ACME inc. - department A</department> <name>John Doe</name> <street>Capitol hill 44</street> <postalcode_place>54321 Washington BS</postalcode_place> <mailURL>john.doe@acme.inc.com</mailURL> <phone>215-555-9876</phone></contactAddress> Result (more or less!): Our department: ACME inc. - department AOur address: John DoeCapitol hill 4454321 Washington BSEmail: john.doe@acme.inc.comPhone: 215-555-9876 Problem:The XHTML page does not validate! Why not?N.b. the web page does display the data of the XML file correctly in the various web browsers.What am I doing wrong?question:How do I include a mailto link in the email address?In other words, how do I make my email address, being: 'john.doe@acme.inc.com', clickable?N.b. The mailto link must be defined in the XML file and not on the web page itself.The <mailURL> tag in the XML file currently is an element containing plain text and no 'href=mailto' link. I know how to do it within the XHTML code, but the whole point is to leave all variable data, like mailto links, out of the static XHTML code. N.b. Within the XML file I have tried xlink (see following additional remarks discussing this trial).What I have done sofar:The example I gave above is a variation of my (limited!) understanding of the the W3C examples as illustrated in the following W3C link:http://www.w3schools.com/xml/tryit.asp?filename=cd_firstn.b. It infuriates me that I cannot retrieve the code example of the 'Belgian waffles' anymore of the W3C site on which I truly based my solution (see my previously mentioned code).As for the mailto link...I tried and experimented with the XLINK examples.In all cases this resulted in a blank web page, meaning - to my understanding! - that the XML syntax is incorrect.For xlink I consulted, among others, the W3C information like:http://www.w3schools.com/xlink/xlink_syntax.aspsummarised:Is there anybody who can give a code example parsing the contents of a linked XML file (see example above) including a mailto/xlink links?Secondary question, how do you pass (other) special characters such as &+euml; (ë)?This does not seem to work either from a XML file, that is, I cannot pass this kind of data within my example!Regards, Wim Ahlers.
  5. wahlers
    COBOL contains programmatic constructs that are superior than C++ and, I assume, C#I say "I assume C#" because I am not familiar with C# but I assume it is similar to Java....and of course I can give examples...but that is asking for COBOL details!Are you prepared!?!On an other note...I don't want to start a code war of "my-language-is-better-than-yours".I often use the example that a truck is good for moving loads and a Ferrari is good for speed.This makes a truck a bad 'fast driving' car and the Ferrari a bad 'transportation' car.But neither the truck nor the Ferrari is 'bad'...they just have their own niches in which they are good.The niche of COBOL is "business applications".And for that niche COBOL is very good!It is very good because it is built for it!As a Ferrari is built for speed, and truck is built for transportation!So, when I say 'superior constructs' than I mean superior for the business application.This does not mean that the other program language, language 'xxx', is a 'bad' language.Where 'xxx' is whatever you want it to be!Regards, Wim Ahlers.
  6. wahlers
    Aha...you have the wrong impression!I do not sneer about XML at all. On the contrary.I am thrilled about XML and dying to use it!I already asked the forum a question about a specific detail about using XHTML.Regretfully this information was lost due to the hacker activities last week.And about limited tasks...XML has a limited task. It is for defining structure only.You prefer the all-in-one solution, which I have personally never seen.I prefer delegating responsibilities of cooperating systems,Such as RDBMS, transaction systems, queing systems, processing systems (n.b. this is the core programming), format defining systems (such as XML) and presentation systems (such as browsers).But my background is from large scale, multi-user, multi-tasking, hybrid batch/online systems.And in this environment I have never seen an all-in-one system.The closest I can think of is java, but my roots are from the following reality:http://www.cobolportal.com/developer/future.asp?bhcp=1...anyway...'nuf said about COBOL! I had no intention to dominate this thread.I have the feeling that the focus is shifting from the orginal intend of noting your favorite (programming) language to a programming language war. And that was and is not my intention.Just one last remark...You said: This is not quite true.The code you came up with is a complete, compileable and working program for opening, reading, processing and closing a real life variable length sequential file, including some rudimentary error processing/messages!It is therefore a complete program!And it is a bit unfair to compare one php instruction against a complete program!That is why I rebutted with the instruction only! Which is (and I quote myself): To justsomeguy,The evolution theory is antiquated.The relativity theory is antiquated.Both evolved during their origins and both are usable.COBOL evolved too! And COBOL still is very usable!And yes, my argument against comments is more of an argument against bad programmers or bad maintainers. It's not the language's fault if people don't maintain the comments as well as the code.But this is reality!Do you control who is coming after you to maintain the system!?!Have you ever fixed a bug at three 'o clock at night for a critical banking or public control system that must startup again at seven 'o clock in the morning!?! I did!Did you feel obligated to concentrate on comments and other non-impacting details!?!Also, people tend to concentrate on a detail when adding, changing or (partly) deleting a system.In reality nobody has the time or takes the effort to study every detail and more often than not programmers code workaround solutions instead of being 'neat', and at the same time it often is safer to leave the comments alone.That is my reality in a multi-user, multi-tasking, border crossing, high volume financial system.Also realize that there are already an awful lot of java legacy systems out there!I remember around 1996 that the then 27 year olds declared: As if somebody programming COBOL is not aware of these other tools and paradigms!There is also confusion!For instance by 'ThePsion5'. He said: Not realizing that XML has its roots in the larger SGML and that HTML is an application of SGML and the fact that the vendors deviated from the orginal SGML standards to fit specific web solutions.XML is nothing less than going back to the 'antiquated' GML roots of the early seventies (with a world standard around 1985: SGML).I cannot comment on you PHP example for the simple reason I do not know PHP.But you did make a remark about abstraction.But with abstraction comes delegating responsibilities.And as you found out, the hard way(!), delegation is a must to write maintainable code.And it is fairly irrelevant what you use for the various responsibilities, for instance javascript versus PHP!...except for the fact that either one or the other is more standardised, more flexible, easier to maintain, more appropiate...and so on, and so on...I would not be surprised at all, you being familiar with PHP, thinking:"how could he compare PHP with javascript!?!""You cannot do 'X' with javascript!" (...whatever 'X' is!)But, to my understanding, both PHP and javascript are used for comparable situations!So, here we are again, one prefers what one knows best!And I know COBOL fairly well.But I know COBOL (still) is the dominant programming language for business applications.It is the dominant programming language for business apllications because of the proved track record.Is this going to change!?!No doubt! But so is PHP, javascript, java, eiffel, delhi/pascal...and so on, and so on...You also said: Practice is, so far, that people are happy when their software is working.It is not so much that you have to 'dumb down' but it is utopia if you assume you can rely on whoever is coming after you!People tend to grow into complex systems.But it is very difficult, even for experienced programmers, to understand complete complex systems developed by others...developed, more often than not, years ago!That is my experience!More often than not a complex system tends to get infuriating complex when time and programmers passes by!You may have experienced this yourself!Ever had the experience that someone changed your 'baby' and you thought: "Why on earth has (s)he done it this way???"It happens!You ended by saying: If you really mean that than why do you dismiss COBOL merely on the fact that you feel it is 'antiquated'?Regards, Wim.
  7. wahlers
    boen_robot,What is XSLT without XML?I approached your example for the fact that XSLT is the presentation definer for XML!XSLT by itself has no meaning nor function.I could be grossly mistaken of course!....my knowledge of XML is rudimentary!Regards, Wim.
  8. wahlers
    boen_robot,XML is descriptive! That is the whole idea behind XML (or SGML for that matter).It describes structure. But XML is not intended to be a program language.It would be unwise to simulate extensive database queries, even though, due to the defining nature of XML, this is (some what) possible.Therefore to 'criticize' XML for the fact that it is not an all inclusive language or database (n.b. XML is not a program language nor a database!) is unjust and ignores the domain for which XML was intended, namely: (definable, strict and parseable) structures.The sneers at COBOL are equally unjustified...and more often than not based on ignorance.At least, that is my personal observation.Regards, Wim.p.s. About criticizing COBOL: I never feel personally insulted and I actually read these (sometimes) funny sneers with the same laughter as anybody else does.So, if somebody does know a funny story or anecdote, don't hesitate to amuse me and others.
  9. wahlers
    ATTENTION! OFF TOPIC!Just for the record...referring to the example given previously...The instruction to separate a comma delimited record into its fields (field1 to fieldX)and count the length (into field1Counter to fieldXCounter) is done by the single instruction: UNSTRING theCommaDelimitedRecord DELIMITED BY "," INTO field1 COUNT IN field1Counter field2 COUNT IN field2Counter field3 COUNT IN fleld3Counter field4 COUNT IN field4Counter fieldX COUNT IN fieldXCounterEND-UNSTRING Ask yourself the questions: Does this need any further comments? Is it too verbose? Or is it self documenting? Can everybody, including those who have never seen or used COBOL, understand this? Is this code (single instruction) easy to maintain? So, what is there actually to criticize?n.b. The 'unstring' instruction is more powerful than the example given above...but that is an other story.Regards, Wim.
  10. wahlers
    You can always find an instruction in any language that is better than any other language.Thus, it is a bit pointless to compare instruction sets and find exactly that instruction that is better than the solution in any other program.I can easily find instructions in COBOL that are hard to code in, for instance, java.But, as said before, a futile and pointless discussion.About comments (/* bla, bla, bla .... */):Comments are both a blessing and a curse!The curse comes when years pass by and no maintainer or programmer feels responsible for modifying the comments after making a change (or addition, or removal) of some program code.Usually the comments are not to be trusted and often more hinder than help the poor programmer.But that is just my experience...About programming itself:Regardless the language used (you name it: Eiffel, java, whatever...) you can mess up using any logical/programming structure...independent of the programming language used.That is why I never use this as an argument.About the one size fits all solution:I am all for it!...except for the fact that I have never found a solution satisfying all requirements and, at the same time, being easy to use!Don't get me wrong...I do realize that some complex systems do require complex solutions.But many systems I know don't need to be as complex as they are.Not withstanding that some people prefer complex systems because they make a career out of it to deliberately keep a system complex to secure their livelihood!...but that is just my observation...It is not good enough that the aces and gurus understand the system!The system must be understand by the mediocre majority. Because, sofar, reality has proved that most if not all systems are maintained by the mediocre majority.And yes, it does happen that a fantastic superb blitz system is maintained by some half God.But even half Gods can have fatal traffic accidents.It is very unwise to let your critical system depend on half Gods! In this respect mediocre is a good thing!Also...It is my experience that a good commercial system is divided into domains of separate responsibilities (both technically as well as seperation of businnes responsibilities).Technically: Presentation, data storage and data manipulation all have there own domains.Which is a good thing!And we already have a separate system for data access (a relational database system in 99.9% of the cases).With COBOL I merely concentrate on the contents of the data and not on how this data is displayed.Which is a good thing! It is good because in a multinational system crossing borders and time zones presentation is different anyway. Not to mention that in many commercial transactions presentation is not even needed (or a minor issue), merely because large volumes of money is shifted backward and forward from one account to the other by means of high volume transactions of which (eventually) a simple summary list is produced.Boring indeed! But this is what the world runs on...boring commercial transactions instead of a true color, high fidelity flash presentations.Not to say that there are, of course, a lot of people who make lots of money creating true color, high fidelity flash presentations, games and the like...but this is a totally different domain!But that is not the point. The point is:What, for instance, if you want to switch from a relational database to an object database?It would not be wise to have an SQL statement in either your presentation or data manipulation logic!As every programmer/analyst knows such a system is highly unstable and susceptible to the famous ripple effect.Having said all this, there is no such thing as 'the perfect' system...at least, I have never seen one.Anyway...I digress...I knew up front that me mentioning COBOL as a favorite language would provoke some reaction...as it always does whenever COBOL is mentioned!By the way...'old' is not synonymous for bad! If this were true than Bach, Beethoven en Mozart would also be 'bad'!Regards, Wim.
  11. wahlers
    Stability! readability! transportability!Try to read, run and/or modify a system written in C++ of 15 years ago!How easy is it?...in reality!Actually...it is reverse! C and C++ can do more than COBOL! Thus COBOL can do less!That is because COBOL is good in just one thing: Core financial applications!There hardly is any screen logic (read:presentation logic) in COBOL!And if there is, it usually is vendor dependent (read: non-standard).Displaying any result from a COBOL program is the responsibility of a program good at displaying information.COBOL was never intended to control the spaceship, games, video, sound and the like...It does not pretend to be anything else than it is: a stable, reliable, maintainable business oriented software solution.N.b. COBOL stands for: = Common Business Oriented Language.See, among others: http://looselycoupled.com/glossary/COBOLn.b. since the latest standard COBOL is, like many other languages, a hybrid language.Thus a combination of procedural and object-oriented code constructs.And, like any hybrid language, it can either be procedural only, object-oriented only or a mixture. (not discussing here which paradigm or combinations of paradigms is wise to use in specific situations).Throughout the years I noticed the strange phenomenon of COBOL being criticized by people who have actually never coded in COBOL or even never coded for large commercial multinationals in any programming language.Regards, Wim Ahlers.
  12. wahlers
    I like COBOL...but that is a bit off topic on this forum.I am a professional COBOL application programmer.Most people do not know what COBOL is, or the fact that COBOL is the backbone of the financial world.I like the power, flexibility, speed, expandability and stability of COBOL...given its target...which is commercial automation!Since recently I am involved in presenting the information c.q. web pages (XHTML/XML, CSS/XSLT)...for which I am a total novice.Regards, Wim Ahlers.
  13. wahlers
    Let's get one thing straight!This was not a hacker but a cracker!A hacker finds faults and then reports and informs so that any security leak can be fixed.This infantile idiot is like the teenager who thinks it is 'cool' to leave his name in graffiti on a subway for other infantile idiots to see who do the same.I have no respect whatsoever for crackers!Regards, Wim Ahlers.
×
×
  • Create New...