I''ve been thinking about this for a little while.
I like what you''ve done in terms of making it easy to say. This
controller is xmlrpc while the rest of the controllers in the app are
normal http/html style.
Ideally we''d have something like this:
webservice :xmlrpc
# with other options being soap, etc...
class TestController < ActionController
def index
@model = Model.find( @xmlrequest[''id''] )
end
end
The controller_style would be a mixin which sets the response headers,
parses the request, defines the current object as an xmlrpc ServiceInterface.
All public methods in the TestController would be available as an xmlrpc method.
This would let us open up our apps to webservices without exposing unwanted
security holes.
The only real difficulty to doing this, is the way dispatcher.rb works
right now.
It does the heavy lifting of creating a cgi object, parsing it, finding out what
controller and method to call. The trick is, it''s not the controller
which
decides which method to call, but the dispatcher.
As it is, the dispatcher only lets the controller get access to the parsed query
string, which as we see in Lars'' example, isn''t always what we
want.
My thoughts are we could maybe provide a hook in the dispatcher where it knows
about the various kinds of webservices. If it''s calling a controller
which is a
normal cgi process it uses cgi to parse the request and determine the method.
If it''s a webservice then we have a xmlrpc dispatcher, a soap
dispatcher, etc..
which know how to parse the request differently, and then call the right method
in the controller.
All of this will change a bit i believe with the rewrite of the dispatcher which
is supposed to becoming along for rails before rails 1.0.
Without changing Dispatcher i don''t see how we can get good support for
xmlrpc,
soap, and other webservices in to rails. We could get good RESTful support in
as that relies on just the url for request paramaters. I believe that''s
what
most people have been doing so far in their rails apps.
-rabbl
On Tue, 18 Jan 2005 14:12:07 +0100, Lars Hoss
<woeye-ee4meeAH724@public.gmane.org> wrote:> Hi all!
>
> I am currently implementing support for the MovableType API in my Rails
> based weblog engine (known as RubyTwaddle). For now the XML-RPC
> invocations are handled by a special controller:
>
> class XmlrpcController < ApplicationController
> model :weblog
>
> def initialize
> @server = XMLRPC::BasicServer.new
> @server.add_handler("metaWeblog", MetaWeblogAPI.new)
> end
>
> def index
> xmlData = @params.to_a[0].to_s
> logger.info("xml-requst: #{xmlData}")
> begin
> xmlResponse = @server.process(xmlData)
> rescue Exception => error
> logger.info("error: #{error}")
> end
> @headers["Content-Type"] = "text/xml"
> logger.info("xml-response: #{xmlResponse}")
> render_text(xmlResponse)
> end
> end
>
> Though most of the time this approach works fairly well there''s
still a
> major problem. In order to get the XML sequence of the XML-RPC
> invocation I convert the params hash into an array, fetch the first
> element and convert it into a string. I have to convert it into an
> array because the the xml sequence of the XML-RPC invocation is the key
> in hash and has no value.
> Now the problem is that Rails automatically formats all request
> parameters. For example something like
> "&foo+moo=this+is+a+string+with+spaces" will become
@params["foo moo"]
> = "This is a string with spaces". This is of course the correct
> behaviour. In my case, however, this means that all "+"
characters in
> the XML sequence gets converted into " " characters. And this
affects
> embedded base64 encoded data as well. Therefore it is not possible to
> decode this base64 data back.
>
> I guess that a controller for processing the XML-RPC invocation
isn''t a
> good approach for a controller seems to be more focused on regular HTTP
> browser requests. What I need is a way to get access to the raw request
> data. Any suggestions? :-)
>
> Regards,
> Lars
>
> --
> "Stil ist die Fähigkeit, komplizierte Dinge einfach zu sagen - nicht
> umgekehrt." -- Cocteau, Jean
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>