Hi Jeff,

I think I figured things out, thanks to your pointers.

I'll try to explain what I did in case someone with the same question
stumbles upon this thread.

First, I created a class that extends HttpServlet. Thats different
from the classes that are made to communicate with GWT-client.
HttpServlet is a fairly simple way to create a respons to a webquery.
See this page for some general info:
http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/Servlet-Tutorial-First-Servlets.html

Second, I used a library to simplify creating XML responses. I used
jdom. See this page for some info: 
http://www.ibm.com/developerworks/java/library/j-jdom/

Then I edited web.xml so the app server will connect requests to a
certain URI to my newly created class:

  <servlet>
    <servlet-name>MyJustCreatedExternalInterfaceImpl</servlet-name>
    <servlet-class>net.arianprins.advsys.server.ExternalInterfaceImpl</
servlet-class>
  </servlet>

 <servlet-mapping>
    <servlet-name>MyJustCreatedExternalInterfaceImpl</servlet-name>
    <url-pattern>/advsys/ExternalInterfaceImpl</url-pattern>
  </servlet-mapping>


Just in case someone is interested; I'll add my test-class at the
bottom.

I'm now going to research the best method to do xml requests in
vba / .net but that's for another group :-)

Jeff, thanks for taking the time to help me.

Arian.
-------------------


public class ExternalInterfaceImpl extends HttpServlet {
    public void init(ServletConfig config) throws ServletException {
// Initialise anything if neede
    }

    public void doGet(HttpServletRequest request, HttpServletResponse
response)
        throws IOException, ServletException {

        try {
// This gets the id in the request ie 
http://www.x.com/ExternalInterfaceImpl?id=5
                Integer eszId = Integer.parseInt(request.getParameter("id"));

// Build some example xml:
                Element carElement = new Element("car");
                Document myDocument = new Document(carElement);

// Output the xml document:
                try {
                    XMLOutputter outputter = new XMLOutputter();
                response.setContentType("text/xml");
                response.setHeader("Cache-Control", "no-cache");
                    outputter.output(myDocument, response.getWriter());
                } catch (java.io.IOException e) {
                    e.printStackTrace();
                }

// id request variable didn't contain a valid integer:
        } catch (NumberFormatException e) {
            response.setContentType("text/xml");
            response.setHeader("Cache-Control", "no-cache");
            response.getWriter().write("<message>invalid request:
"+request.getParameter("id")+"</message>");
        }
    }
}



On 9 jul, 17:23, Jeff Chimene <[email protected]> wrote:
> Hi Arian,
>
> I don't have a good answer for you, as I really don't do server-side Java.
>
> I've got to believe that there are quite a few examples "out there" of
> how a Java servlet can participate in CGI traffic on some arbitrary
> port. Such CGI traffic is what a non-Java RPC client request looks like
> to a CGI server. Your servlet is written in Java, but doesn't use GWT
> Java RPC. IOW, this servlet doesn't extend and implement
> RemoteServiceServlet. This doesn't change what the Office macro sends. I
> could produce a Perl script that interacts with your Office macro, and
> the macro would never know that it's not talking to a Java servlet.
>
> Your servlet then decodes the request parameters and replies with a
> CGI-compatible response.
>
> BTW, the reference to ".NET objects" in my earlier post referred to the
> client side as well as the server side. Although you're using Java on
> the server side, I think you'll still need .NET classes for the client
> (MS Office) side.
>
> On 07/09/2010 07:19 AM, Arian Prins wrote:
>
> > Hi Jef,
> > Thanks for taking the time to answer my questions.
>
> > I'll try to remove the fuzziness.
>
> > I have already built a lot of objects using server side java, so I'm
> > not going to build any services using .NET. I've used the eclipse GWT
> > plugin and that takes care of everything needed to get the GWT-client
> > talking to the java objects on the server. Hence my misnomer "GWT
> > server". It's java, it uses GWT-RPC (i presume) as a protocol to talk
> > to the client.
>
> > So now I have a complete server that talks to my client. Both created
> > in Java, both arranged through eclipse. Now I want to add some way for
> > an office macro (but actually it could be anything, eg. an rss feed
> > you want to publish) to query the server.
>
> > So I would need to use some java library to send incoming XHR requests
> > to a java object+method and I'd need to configure the server to
> > differentiate between requests coming from the GWT client and the XHR
> > requests coming from anywhere else.
>
> > I made a sketch of the different 
> > parts:http://www.arianprins.net/downloads/advsys.gif
>
> > While i'm discussing my problems with you I think the solution lies in
> > these two questions:
> > - how to create an XHR service / servlet in java (specifically: in a
> > way that can coexist with the way the GWT-eclipse plugin configures
> > java / the application server);
> > - how to configure the application server to receive the XHR requests
> > and send them to a Java object.
>
> > Thanks for the advice,
> > Arian.
>
> > On 8 jul, 17:41, Jeff Chimene <[email protected]> wrote:
> >> On 07/08/2010 07:34 AM, Arian Prins wrote:
>
> >>> Hi Jeff,
> >>> Just to explain my plan a little further:
>
> >>> I'm building an application where the user normally interacts with the
> >>> system using GWT in a browser (the most "normal" way of using GWT).
> >>> But I'd also like to generate some documents (in MS-Word) using data
> >>> and objects that are available in the GWT-server. There would probably
> >>> be only a small number of methods that need to be available on the
> >>> outside, so a very heavyweight library would be overkill.
>
> >> Please drop the concept of "GWT server", as it doesn't exist. GWT is a
> >> client-side solution that can interact with a variety of server-side
> >> solutions. Perhaps I'm misinterpreting the term "GWT server"?
>
> >>> It all boils down to:
> >>> I want to execute a function in a word-macro:
> >>> String GetTheTextForThisWordDocument(documentId);  :-) :-)
>
> >> That's fine. As I recall, you can access XHR technology from an Office
> >> macro.
>
> >>> XHR sounds good, but how can I get that to work?
>
> >> You'll want to use .NET objects
>
> >>> The way I think about
> >>> it I would probably need to perform the following steps:
> >>> - Create an object / methods that perform the function(s) that I want
> >>> to be available (the GetTheText... method mentioned above);
>
> >> Yes.
>
> >>> - Use some kind of library / construction that can make that object
> >>> available to the outside world (just like GWT does in its own way).
>
> >> I think the answer to this is "no". But there is still some fuzziness in
> >> terminology here that should be clarified before a definitive answer.
>
> >>> Is there some kind of standard XHR library?
>
> >> Yes, there are several GWT classes: JsonpRequestBuilder,
> >> RpcRequestBuilder, RequestBuilder. Of these, I think the first and third
> >> are what you'll want, since it sounds like you won't be using Java to
> >> handle the request (although there may be Java/Office interoperability
> >> classes available)
>
> >> Since the documents are on the server, you can construct a .NET service
> >> that listens for HTTP requests, evaluates the request, loads the
> >> document, executes the macro, retrieves the response, formats it, then
> >> sends it to the client.
>
> >> Using this solution, I think you'll be limited to UTF-8 scalars (i.e. no
> >> images, no structured document fragments). If you want more than that,
> >> you'll probably want to have the server send the document fragment using
> >> one of the MS MIME types.
>
> >>> - Somehow configure the application server (in web.xml?) to respond to
> >>> a certain URL using that library 
> >>> (example:http://localhost:8001/WordDocumentXHR)
>
> >> Unless you're using server-side Java, there's no use for the web.xml
> >> file. web.xml is for those using Java RPC services. The URL you provide
> >> above is defined in your application as a string constant, and used by
> >> one of the classes I mentioned above.
>
> >>> Those last two points I've never dealt with before (and I haven't
> >>> found anything googling), so any advise would be appreciated.
>
> >>> Arian.
>
> >>> On 8 jul, 02:26, Jeff Chimene <[email protected]> wrote:
> >>>> On 07/05/2010 02:28 PM, Arian Prins wrote:
>
> >>>>> Hello people,
> >>>>> I have a hard time figuring out what would be the best approach for my
> >>>>> problem.
>
> >>>>> I'd like to communicate some info from the server (side logic) to an
> >>>>> MS-Office macro. I could always use ODBC to let the office macro query
> >>>>> the database directly but that just feels like a kludge. I've got a
> >>>>> lot of objects in my application in which a lot of processing is
> >>>>> already implemented.
>
> >>>>> So, I figure, the best way would be to create a web service (SOAP?)
> >>>>> inside the gwt server-side implementation that can be queried by
> >>>>> outside applications.
>
> >>>>> I've done a lot of searching, but haven't really found any definitive
> >>>>> way that would be best. Should I use an existing RPC/SOAP/JSON library
> >>>>> and try to integrate it into GWT's structure (how to configure
> >>>>> web.xml? etc. etc.)? Is there something already provided by google or
> >>>>> in de code projects?
>
> >>>>> Any thoughts and tips would be greatly appreciated.
>
> >>>>> Arian Prins.
>
> >>>> Hi Arian,
>
> >>>> I've written some fairly complex Office macros.
>
> >>>> I'm not sure where GWT fits into your application. In your case, the
> >>>> client side is MS Office macros, not a browser JavaScript instance. The
> >>>> server side can be whatever you wish. You will probably want to use
> >>>> XMLHTTPRequests (XHR) to communicate with the server; I think SOAP is a
> >>>> bit heavy-handed to implement in an Office macro.
>
> >>>> I doubt RPC will work for you, as the serialization logic is also a bit
> >>>> much for an Office macro.
>
> >>>> This leaves JSON, application-specific XML (as opposed to the
> >>>> generalized SOAP DTD), CSV.
>
> >>>> If you are planning to use the Google App Engine, I'm not sure how to
> >>>> get Office macros to use Java RPC.
>
> >>>> I'm leaning towards the XHR solution: it's lightweight, can be tested
> >>>> independently of the macro environment, and straightforward to mock
> >>>> inside the macro environment.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to