On Thursday 03 July 2003 07:15 pm, Robert Ferney wrote: > For the project I am currently working on, I have the following design > thought. > > I've written a database Provider module that will turn the url > http://foo.com/bar/<key>.xml > and provide the xml formatted results for the sql query > select <fields> from <table> where <keyfield> = <key> > where <fields> and <table> and the database connection parameters are > taken from a .htaccess file in /bar > > I would then like to be able to use > http://foo.com/bar/<key>.xml/<style> > to handle various diffrent views of the record, including such things as > edit forms ect, then also be able to apply some conditional stylesheets > after the <style> pipeline to account for the method that the user is > using to access the system.. aka MSIE, Mozilla, Opera, WAP, ect..
You can do that with a combination of stylechooser and media type choosing directives. I don't believe there is currently a 'browser type chooser' but you could certainly build one easily enough... Or if the differences are very small, which is likely, then just conditionalize in XSP or XSLT. > > Also.. > It would be nice to be able to do > http://foo.com/bar/<key>.pdf > and get a PDF render of <key>.xml at the same time allowing for the > http://foo.com/bar/<key>.xml/edit > syntax for editing the edit form for the record. Again the stylechooser will let you do that, or you can use FILES directives in .htaccess to conditionalize stylesheets. In terms of producing multiple types of output my personal preference is to first generate generic XML. In your case you can do that in your provider. Then merge in any common static (graphic) elements, and then convert to the output format of choice. You could also base your choice on media types, so a printable media type could result in the output of a PDF, though I think in general that doesn't work too well because you cannot tell what a user is going to do with a web requested file. > > potential problems.. > In the case of the edit form(s), using logic sheet(s) infront of the XSP > stage will mean that it likely will not be cashable, which I believe > means that performance will be closer to running a CGI rather than > direct unmodified Apache file access. I wouldn't use XSP at all. What is the need? XSP is just a way to get perl code in your pipeline, but with a custom provider you already have all the opportunity for that you need. Essentially there is nothing you can do in XSP you cannot do just as well in a provider. You may also find you can do basically 100% of what you want as far as what form to display your data in with just XSLT. AxKit itself will choose a stylesheet for you and from there your XSLT just builds what you want. > > Also, I am wondering, would the xml record => logic sheet => XSP works > well with the PerForm taglib library. and what considerations would need > to be made when doing so. The alternative to your design would be to say 'well, I need XSP, so why bother with a provider at all?' Just have XSP first in the pipeline and run your query there. Providers are nice, but it seems to me their main advantage is caching of their output, and with database queries you can rarely do much caching anyway. If you can, then great, go for it, but if not then its a coin toss between XSP and Provider. > > Thanks for the help, > -Robert Ferney > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Tod Harter Giant Electronic Brain http://www.giantelectronicbrain.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
