Subject: [xsl] case study: commercial xml/xsl site From: "cutlass" <cutlass@xxxxxxxxxxx> Date: Thu, 11 Oct 2001 11:21:53 +0100 |
hello folks, not tooting our own horn, but here's a commercial site, completely delivered using xml/xslt technologies ( yes even the search button... ). thought it might be interesting to give a mini case study of a completed commercial site, as a possible inspiration to those who are trying to migrate to new architecture commercially. the application in question is mobileprofile http://www.swisstxt.ch/mobileprofile/d/, which of course is in german, so the following may not interest people.... ( it is part of www.swisstxt.ch , the swiss teletext people, website ) essentially the application allows a user to register a profile and pick and choose messages to receive via sms, since swisstxt makes a lot of content, XML/XSLT was a perfect match for their current requirements ( eg. delivery by SMS ) and future requirements ie. delivery on all platforms ( with just a new template per client ) and easy content management. architecture ----------------- -linux redhat 6.2 -apache with mod_perl ( and axkit, XML::Sablotron, etc) -homegrown XML repository which is essentially expat with persistance using an XPATH api to query and has various realtime connections to external ODBC datasources. -o-iDeveloper, my internal xml/xslt framework based on cold fusion can use various XSLT processors - integrated telephony software for SMS delivery highlights ------------------- -all areas of the site are based on a complex set of XSLT templates that will deliver each page, based upon what client and language the user has ( though only german is delivered at the moment, due to translation being performed now ). - due to the applications template nature all assets, including text can be changed via html form, which makes content management a non-technical task. in addition, new clients ( PDA, website, text version ) can be dealt with by adding a single template per client. -all datasources ( SQL, XML, text files, etc ) get aggregated into a large XML repository which can then be queried by XPATH - the delivery of an SMS requires a billing and editing workflow, all of which was easily done using XSLT/XML - the new architecture successfully integrates a bunch of classic architectures, positioning the client to take advantage of all XML technologies quicker. lowlights ---------- - when designing a schema for the various components i would suggest a lot of prototyping with respect to speed, all to often the component and modular benefits of XSLT means that the templates are put together at 'the last moment' which may mean some performance problems are experienced and solved at the end of the project vs the beginning. - when designing multilingual sites, i suggest definately to preparse the different language versions, there is no amount of generic templates that will satisfy the requirements ( at least thats what we found ) of a multilingual application. - the architecture is complicated due to the lack of integrated toolkits - templates, assets and content management had to be managed by our inhouse tool ( o-icore aka o-iDeveloper ), though everything gets published 'honestly' ( that is xml and xslt files ), the idea of managing this by hand is not really feasible in light of common LAMP solutions; to get true interoperability one will have to framework 'hard' to get to a useful place. oh well, for you german speakers maybe this was interesting, otherwise, we have 5 more projects that should go commercial in the next month, all of which are using the same architecture, just a testimonial to the converted. cheers, jim fuller XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] cumulative sum along link, Jeni Tennison | Thread | [xsl] Adding to doc in extensions, Hunsberger, Peter |
[xsl] cumulative sum along linked l, Steve Renshaw | Date | Re: [xsl] cumulative sum along link, David Carlisle |
Month |