Random outpourings of a software developer
XLST was hailed at the end of the 90’s as being the uttimate tool to transform XML.
Theoretically you can use it to transform any XML into any other other format.
It can be very powerful (look at Code Generation).
However it needs to be treated especially carefully and be properly supported by unit tests of the transforms. Just because some clever code can be written does not mean that it should. Don’t take too many shortcuts.
Here is a useful python script that will make life a little easier:
import os
def XPathToXML(XPath):
s = XPath.split(“/”)
for x in s:
print (“<“+x+”>”
s.reverse()
for x in s:
print (“</”+x+”>”
if __name__ == “__main__”:
XPathToXML(os.argv[1])
This little beauty will take an XPath fragment such as
a/b/c and return:
<a>
<b>
<c>
</c>
</b>
</a>
Which is just what the doctor ordered when creating XSLT test data.
The guy who wrote them seems to be a control freak manager.
However they do seem like a decent set of guidelines.
Pro
Individual sp’s easy to replace this provides many places for system expansion/correction.
There are great security benefits. An app that exlusively accesses a db via
sp’s can have much tighter control over it’s data access.
Con
Not portable.
Sometimes limited error handling.
No use of constants.
A three tier application splits it work up into distinct tiers (Here is an example):
1. Presentation Layer
2. Business Layer
3. Database layer
While this is harder initially to set up it does provides a range of deployment, security, development and maintenance benefits.
Just because the database layer uses stored procedures does not in any way invalidate this model.
For deployment, with a corrrect design it is possible to only require detailed configuration once on the server as opposed to every client.
For security there are more oppertunities for security in depth (you only need grant database access to the Business Layer or Database Layer not every user).
For development there are more incentives to reuse code since the layers provide a some decoupling. In a two tier application there is far more room for code duplication. The layers also provide a point for performance tuning.
For maintenance having distinct layers means that a patch can be better isolated.
If you don’t change the interface only a single changed component needs to be deployed.
At an appropriate point in your code you add:
if ( !System.Diagnostics.Debugger.IsAttached )
{
System.Diagnostics.Debugger.Launch();
System.Diagnostics.Debugger.Break();
}
It will search for a suitable debugger which would include the IDE that you have open on your code.
It appears that in order to inherit a class it must be defined in a library.
Delphi does not have a class / executable affinity.
This seems like a major design flaw.
Chris Sells did admit that MS did not invent MDD, just now they are tring to bring them to the fore.
MDD really is the practice of using meta-data where appropriate.
Delphi has had this for years in the seperation of a form into it’s dfm and pas components.
It has been possible to change a delphi dfm to add static components without touching the code.
Developer Rants 