Its certainly a tricky decision to make and I do think it comes down to working out what might be best for others involved in the project and for possible future maintainers
> Well, you should be able to feed your data into an AxKit pipeline. I am > not 100% clear when you say 'prototype Class' exactly what you mean, but > there are several alternatives you can use. I wasn't very clear in my explanation. The code I have written so far (as a prototype) works like this. 1. XML is generated by PHP, from Mysql queries. 2. The XML is available over HTTP to third parties. 3. My website makes calls to fetch the XML document over HTTP (this a localhost connection at the moment, but would scale well). The XML is cached locally as the data doesn't change more than one a day at the most. 4. I only fetch small amounts of data at a time, so the parsing seems fairly fast (though I don't really know how this would fare under heavy load). 5. The XML is parsed into PHP native data types and wrapped up in a class which is then used as an API to be accessed using tags in the HTML and WML. If was to use AxKit, then I guess I would be looking at feeding the XML into a pipeline and using XSLT to generate the output. I am certainly tempted by the AKit route, lots to think about Jon On Friday 01 October 2004 15:58, Tod Harter wrote: > Jon Hill wrote: > >Hi > > > >I have only just stumbled upon AxKit today and am very interested in what > > I read. > > > >I mostly develop with PHP, I have a good grounding in XML and Perl also. I > > am about to undertake a project which needs to be presented on Web > > browsers and Mobile handsets (maybe others). I usually work with OOP > > techniques in PHP and do what I can to decouple various layers from each > > other, relying on my own APIs rather than template engines (so far). I am > > very keen to look more at the possbilities that XML may give me to take > > this approach further. For example I currently use XML to export content > > descriptions to third party companies and I have knocked up a prototype > > Class that produces XML data from the database and can be called over > > HTTP, I then simply parse the XML into php data structures at the moment. > > > You can simply access your data via the existing http interface within > an AxKit pipeline. For example in an XSLT stylesheet you can use the > document() function to grab your data and process it, which is good if > you have small dynamic chunks of stuff that get incorporated into other > documents and are used often in several places (ie say a menu which > might need to include or exclude certain links based on user > permissions). <xinclude/> can also be used similarly in some cases. > > You can write an AxKit provider. It would simply use your existing code > to generate the content and pass it on. There are some code examples and > its pretty easy to build these modules in perl by reference to existing > providers like the file provider. Generally all you have to do is get > the bytes and maybe deal with 'mtime'. > > Other possibilities exist. XSP is one possibility, and using the Filter > provider is another. > > I think all this is covered in the AxKit book (http://www.axkitbook.com > its published by O'Reilly, you can order it online). > > >Would someone be willing to help me work out if AxKit could be the tool I > > am looking for. I like what I am doing with my prototype but I do need to > > think about processing efficieny, scalability, and standards. > > > >What would be some of the key questions to ask myself before going down > > the route of XML transformation? > > Personally I think the only really MAJOR question is customer > acceptance. Someone is going to have to maintain your application and > depending on the application there may be people (possibly 3rd parties) > managing content and styling information. Those people may need to be > exposed to technologies like XSLT. A common kind of thing with webapps > you may get is 'Yeah, well our designers cannot deal with this XSLT > stuff, they want (plug in whatever here CF, ASP, Mason, PHP, etc) > templating technology instead'. > > There is no question at this point that AxKit isn't going to limit your > performance any more than any similar XML based approach, you have the > full power of Apache/mod_perl at your fingertips. As far as standards go > XML support in Perl is generally pretty standards-based at this point. > You can pull in whatever functionality you need from CPAN libraries, > etc. IE you have libxml and libxslt to work with and perl based SAX > processing.Other standards issues are generally more relevant to > software intracting with your system, but I know people have been > working on supporting XForms and things like that. Validating incoming > XML is another interesting area, you can certainly do that, but its > somewhat outside the realm of AxKit itself (which really focuses on > output transformations). I know people have built SOAP services (again > handling incoming SOAP requests doesn't involve AxKit directly) etc. > > >regards > > > >Jon > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
