RE: Re: Calling Restlet from Restlet

2009-06-15 Thread webpost
That did the trick. I would not have thought to look at that as a solution.

String targetUrl = "riap://application/foo";

// invoke the request   Response fooResponse = 
getApplication().getContext().getClientDispatcher().get(targetUrl);

Thank you,

Perry Hoekstra

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361730


Re: Response for a 405 can't be parsed by SAX

2009-06-15 Thread John Prystash
Thanks for the replies guys.  I definitely don't need to parse it as XML, I'm 
using XMLUnit in my integration testing to compare the responses (my service 
returns XML entities).  Also, our QA tell prefers to compare XML.  So I wasn't 
pointing it out as a shortcoming by any means, just raising the discussion.



- Original Message 
From: Stephan Koops 
To: discuss@restlet.tigris.org
Sent: Sunday, June 14, 2009 7:51:45 AM
Subject: Re: Response for a 405 can't be parsed by SAX

Hi Rhett,
>>> SAX can't parse it because it's HTML, not XML.  ( alone is valid
>>> HTML.)  You should be able to determine whether it is HTML or XML in
>>> your client by examining the content type header.  Is restlet not
>>> setting that header correctly?
>>>
>>> If you want to provide XML-formatted error responses, I believe  
>>> you'll
>>> have to implement them yourself.
>>>  
>> But it is a problem, if Restlet would return  instead od  ?
>> Than it is also correct XML (and XHTML?)
>>
> I wouldn't have a problem with that.  At the same time, though, I  
> don't see why you'd need to parse it as XML.  The message is basically  
> just translating from the error code into English.  Since the error  
> code is already part of the response, doesn't it make more sense to  
> skip parsing the body if there's an error and the service you're  
> talking to doesn't define special error bodies?
>
> After all, if the representation being requested were JSON (or PNG, or  
> PDF, etc.), you'd get this same response body back with the error (by  
> default).  It's not Restlet's job to provide error bodies that are  
> parseable as the same content type as a success would be.
>
> Rhett
You are right. But XML parser will than have no problem with the 
content, also if it is not intended to be used by them. And it's very 
easy to implement. But we could leave it as it is.

best regards
  Stephan

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2361955

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2362178


Designing restlet applications

2009-06-15 Thread Matt
Hi there,

I though I would ask you all a couple of questions about designing Restlet
applications.

I want to use the minimal number of resources that perform operations on
"Users" and display them in different ways using Freemarker.

So I might have some routes like:

router.attach("/users", UsersResource.class);
router.attach("/user/{id}", UserResource.class);

That should handle the basic stuff.

Now I'll need to support the following:

Displaying a user, adding a user and editing a user. 

Now for each of these things I might need to do slightly different things.

Display a user --> Load the user --> display with view.ftl
Add a user --> Sets some defaults --> display with add.ftl
Edit a user --> Load the user ---> display with edit.ftl

I can see that I could end up with additional routes like this:

router.attach("/users/add", UserAddResource.class) 
router.attach("/user/i{id}/edit", UserEditResource.class)  

I don't really want to d this if I can avoid it.

Any suggestions on how I can avoid doing the above?

Thanks in advance,
Matt
-- 
View this message in context: 
http://n2.nabble.com/Designing-restlet-applications-tp3084513p3084513.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2362353