Geoff Talvola wrote:
> Tom Schwaller wrote:
> > Geoff Talvola wrote:
> > >
> > > The XMLRPCServlet I checked in will only work for XML-RPC, not for browser
> > > requests. If you're willing to do a small amount of extra work, you can get
> > > the effect you want, by implementing the function in a mixin class, then
> > > creating two servlets that utilize the mixin class. For example (untested):
> > >
> > > class AdderMixin:
> > > def add(self, x, y):
> > > return x + y
> > >
> > > class XMLRPCAdder(XMLRPCServlet, AdderMixin):
> > > def exposedMethods(self):
> > > return ['add']
> > >
> > > class HTMLAdder(Page, AdderMixin):
> > > def writeBody(self):
> > > req = self.request()
> > > try:
> > > x = int(req.field('x'))
> > > y = int(req.field('y'))
> > > except:
> > > self.writeln('Your input was bad')
> > > else:
> > > self.writeln('The answer is <B>%d</B>' % (self.add(x, y)))
> > For a reduced API this is certainly the way to go, when you
> > have more methods it gets cumbersome..
> But the XML-RPC request needs to return data, while the browser request needs to
> return the data formatted meaningfully for a user to view. You'll have to write
> some extra code anyway to format the output for the browser, so I don't see why
> it's much more cumbersome to use separate servlets.
> > > Or there may be some clever way to get one class to be able to respond to
> > > either XMLRPC or regular browser requests. I'll think about it.
> > yeah, that's what I was thinking about too. Propably you
> > have code for something like
> > class XMLRPCPage(HTTPServlet):
> > before I start my night session today :-)
> > The class should have the funtionality of Page and XMLRPCServlet,
> > which unfortunately have both HTTPServlet as base class
> > class XMLRPCServlet(HTTPServlet):
> > class Page(HTTPServlet):
> > so one needs to factor out some of the XMLRPCServlet Code
> > into another Mixin class.
> Exactly. You could put the stuff that's in XMLRPCServlet now into XMLRPCMixin,
> then write
> class XMLRPCServlet(HTTPServlet, XMLRPCMixin):
> for use when you only want XMLRPC, and
> class XMLRPCPage(Page, XMLRPCMixin):
> for use when you want both.
> > I have the feeling that you need extraURLPath
> > for a class beeing able to respond to either XMLRPC
> > or regular browser requests. The circle is closing here :-)
> Yes, you could use the extraURLPath to determine which method to call in the web
> browsing case. But see my objections below.
> > B.T.W: How many methods should one expose in such a XMLRPCPage then?
> > To many of them is not good memorywise I think. comments?
> I'm still not convinced it's a good idea to just go ahead and serve up the same
> methods via XML-RPC and via web browsing. First of all, in the web browsing case
> you have to do extra work to format the data for the user, as I mentioned above
> (or you could just format the data in some arbitrary way, I suppose, but what use
> is that?). Second, I think XML-RPC is stateless -- there are no cookies or other
> state information that can be used to preserve sessions, unless you explicitly add
> them as parameters in your XML-RPC methods. So there's some incompatibility
> there. Finally, I see XML-RPC as a way of exposing a lower-level API for your
> application to be controlled programmatically. You don't _want_ to be exposing
> that level for the user to see through their browser -- the browsing experience
> should be prettier and higher-level. So separating the XML-RPC and the web
> browsing into separate servlets that make use of shared mixin for common
> functionality seems like the right way to me.
Somehow I viewed Zope as a model here,
but I completely agree with the above statement.
With Zope you get everything (in this case XML-RPC)
for free, but you pay performancewise for the overhead,
which in most cases you just don't need (I always wrote
spezial Zope-Methods to be used by XML-RPC, but you can
call all other methods by XML-RPC too, which gives no sense
in most of the cases, because you get plain (useless) HTML..).
> Anyone else have any thoughts?