> tonyl/pillarsoftware wrote: > > 1) If the reason for the Metadata change is the introduction of a new > > business rule that will require code changes. > > > > 2) If the reason for the Metadata change is simply to capture more data > > that is non-essential to any transaction processing.
Can you elaborate and give examples of these two kind of changes? From: "Jonathan Peterson" <[EMAIL PROTECTED]> > > I thought about that for like 1 nanosecond and agreed. Because that > > I recommend thinking about it for longer :-) > > There are many practical difficulties with putting everything in the > database - I know, I have to deal with them. Really, can you give a few? I might be able to share some of my experience. Overall the "Store in database, cache and use in filesystem" strategy has worked very well for me. tonyl/pillarsoftware wrote: > > way...a version stamp could be applied that "pinned" the XML, the XSD, > > the XSL and the actual processing code (ASP, JAVA, PHP, whatever) Well, in my system I've succesfully eliminated almost all ASP pages and rely on XML and XSLT entirely for presentation with different modules kept in components. I do keep versioning for XML documents and XSLT templates which is very useful but I don't think mixing in version control for the components would be such a good idea as Jonathan said that probably is best kept separately. XML and XML is managed by the administrators of a site but code is only managed by developers and therefore should be managed aside. I don't mind keeping the actual binaries in the database though :) but thats just because as I said I use my SQL a central dataserver which is then used to synchronise all servers. <signature> <email>[EMAIL PROTECTED]</email> <mobile country="+46" area="709" number="284262"/> <company>Existic</company> </signature> -- http://cms-list.org/ more signal, less noise.
