[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Microsoft extensions to XSL (was RE: how to call Javasc
> By the way tyler, the Javalobby stuff is quite impressive and well done. > However, most of us has to do more complex sites, like for instance provide > e-commerce and link to mainframes (yes, these prehistoric beast are still > alive), link to relational database, etc. XSL is great in a way that it > provides a good transformation language, javascript is not so efficient for > that task. But XSL is not able to link to database and build a document from > data stored in these beast. And if a standard can help us to do that, we > won't get locked into any religion either called Microsoft or Java. I hoped > that people from W3 beyond all religions heard this request from people > having to _deliver_ stuff. First, it seems to me that if you have to link with legacy mainframes, DCOM certainly isn't the way to do it. What do you think is more likely to exist on mainframes and minicomputers -- a CORBA implementation or a DCOM implementation? I'd expect CORBA from IBM, not DCOM. COM has its uses as a component model, much like JavaBeans, but when all you want is distributed interfaces, I'd say that on legacy systems, CORBA is alot more mature and available. Secondly, I think doing database queries inside the XSL processor is just WRONG. It totally breaks the architectural design IMHO. XSL should not be in the business of querying a database and building a document. To me, in the model-view pattern, XML is the data model, and CSS/XSL are the "view" Any RDBMS/OODBMS/LDAP/IMAP/SearchEngine/whatever queries should be done and already inserted into the XML before XSL even sees it. If XSL has to perform any dbms queries, it should only be used to change the look-and-feel (personalization), not the data. An example architecture is +------+ |OODBMS|------\ optional query +------+ \ to personalize view \ | +-----+ \ +-----------+ +-------+ |RDBMS| -----------|XML results|---------->|CSS/XSL|---> HTML/PDF/Whatever +-----+ /+-----------+ +-------+ / +------+ / |Custom|-------- +------+ People who want to use XSL to build documents from databases directly are too hooked into the ASP/ColdFusion template mindset where one defines an an incomplete HTML document and fills in the holes via a DB query in VBScript or ColdFusion tags. The problem with using XSL for this approach is that at no time is there ever a complete valid XML document. If you simply invent your own static tags in XML and have all dynamic data "filled in" at the XSL level, than a user can never get his hands on an XML document containing the untarnished data. What's the point? If you use XSL like this, what does it buy you that PHP, JSP, ASP, LiveWire, ColdFusion don't? You aren't putting any data in the XML, just using XML tags like neat little macros that expand into HTML chunks. My own preference is for a simple RDBMS-to-XML mapping language that takes queries and spits out fragments of XML which can be Xlink-ed into another document. You author your XML documents normally, but when you need to include dynamic data, you XLink it in. Performance may suffer, but caching solves the problem. This approach works very well for the 90% of common website functions like providing news bulletins (ala miniportals/aggregrators), doing a catalog, or a portal-tree, or even providing web chat forums. The advantage is, the XML documents can be retrieved by the client, indexed, transformed, etc. All IMHO, -Ray XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|