Matt Sergeant wrote:
On Monday, Feb 3, 2003, at 19:09 Europe/London, Kip Hampton wrote:
Explain "read only" in this context. What "changes", "back" to where?Given that a Provider has access to everything that is available for the Language modules *and* gets to control both the content and the styles that are applied, how does it lack flexibilty, exactly?
Simply because the Providers are read only at the moment, so there's no direct method for submitting changes back
You have the same access to the same Apache request object inside a Provider that you do from any of the Language modules. My app Provider can be just as responsive to user input and the other environmental conditions as any mod_perl handler (or document processed by an AxKit Language module, or AxKit Plugin module, or ..).
I'm sorry, Matt, but I think you're mentally stuck in "AxKit as document publishing solution" mode and, perhaps, a smidge myopic about how AxKit can be used to build/deliver dynamic application content (fortunately, AxKit itself is not thus afflicted :-)
Sure you do. You just use a layer that is implemented soley as a AxKit Language module.(which, incidently, limits you to being able to serve only URIs that have associated files on the disk -- application-based ContentProviders are *not* similarly limited)Consider the following:Application Framework (builds XML document) -> Custom Provider -> AxKit
Right - it's that App framework that I consider the extra layer. I'm not suggesting that's a bad thing, just a layer I don't have in my systems at the moment.
If I have an App Provider that accepts data from the client, handles some back-end side effects, and returns dynamic content in response-- how is that more of an "extra layer" than an writing an XSP or XPS document that is handed off to Language processors to do the same things?
-kip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
