[xwiki-devs] [GSOC] [Refactoring Notification] XWIKI ANDROID
Hi, All, Thomas Just to notify a design decision. Since you said to notify on major decisions, There is a little issue in the earlier projects RestConnector. module "xwiki-android-rest" I' ll take a sample method where you can check. public Page getPage(String pageName) in PageResources. If the page is not found in the server the underlying HttpConnector will get a "404 not found".(there are other situations as well ex: unauthorized etc...) Currently these are not identified in the low level rest connector. So I deprecated the "class Requests" (because I don't wont to break application layer code in the earlier project) . Made a new class that throws the exceptions up. Also some methods as "public String addPage(Page page)" return the response codes up to the Application layer . This does not seem a good idea for me. The knowledge of response codes should be handled in there itself. An exception should be thrown for unsuccessful operations. Currently String "error" is passed up for IOExceptions. I re-factored back to throw RestConnectionException for IO errors. I will introduce a new exception RestException , to be thrown at these exceptional situations. What is you opinion on introducing exceptions? The current exception hierarchy is as follows. Exceptions at RestConnector (low level fine grained XWiki Restful API) RestConnectionException : for IO errors RestException : to capture and throw as a exception, 404, 401, 405..... Exceptions at the Restful Access Layer. RestAPIUsageException : runtime exception. For things that cannot be handled. RALException : RestException are wrapped. Well in a more friendly manner. ex: add object to a Document in a document update operation. Client App is ignorantly adding a object to a page that is not yet even created. So a 405 is returned. This is thrown as a RestException from the Connector layer(low level) At the RAL we see the 405 and identify that this was because page was not created earlier. We wrap the RestException in RALException and give the more friendlier message.( Also note that the client can handle this exceptional situation by asking the RAL to do a create document) Can you give your opinion on this? Regards Sasinda.
On Tue, Jul 24, 2012 at 5:28 AM, sasinda rukshan <[email protected]> wrote:
Hi, All, Thomas
Just to notify a design decision. Since you said to notify on major decisions,
There is a little issue in the earlier projects RestConnector. module "xwiki-android-rest" I' ll take a sample method where you can check. public Page getPage(String pageName) in PageResources. If the page is not found in the server the underlying HttpConnector will get a "404 not found".(there are other situations as well ex: unauthorized etc...) Currently these are not identified in the low level rest connector. So I deprecated the "class Requests" (because I don't wont to break application layer code in the earlier project) . Made a new class that throws the exceptions up.
Also some methods as "public String addPage(Page page)" return the response codes up to the Application layer . This does not seem a good idea for me. The knowledge of response codes should be handled in there itself. An exception should be thrown for unsuccessful operations. Currently String "error" is passed up for IOExceptions. I re-factored back to throw RestConnectionException for IO errors. I will introduce a new exception RestException , to be thrown at these exceptional situations.
What is you opinion on introducing exceptions?
I completely agree with you.
The current exception hierarchy is as follows.
Exceptions at RestConnector (low level fine grained XWiki Restful API) RestConnectionException : for IO errors RestException : to capture and throw as a exception, 404, 401, 405.....
Exceptions at the Restful Access Layer. RestAPIUsageException : runtime exception. For things that cannot be handled. RALException : RestException are wrapped. Well in a more friendly manner. ex: add object to a Document in a document update operation. Client App is ignorantly adding a object to a page that is not yet even created. So a 405 is returned. This is thrown as a RestException from the Connector layer(low level) At the RAL we see the 405 and identify that this was because page was not created earlier. We wrap the RestException in RALException and give the more friendlier message.( Also note that the client can handle this exceptional situation by asking the RAL to do a create document)
Can you give your opinion on this?
Sounds good to me, will think more about the details and will tell you if I have some things I think about.
Regards Sasinda. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Thanks for the confirmation. Regards, Sasinda. On Tue, Jul 24, 2012 at 9:28 PM, Thomas Mortagne <[email protected]>wrote:
On Tue, Jul 24, 2012 at 5:28 AM, sasinda rukshan <[email protected]> wrote:
Hi, All, Thomas
Just to notify a design decision. Since you said to notify on major decisions,
There is a little issue in the earlier projects RestConnector. module "xwiki-android-rest" I' ll take a sample method where you can check. public Page getPage(String pageName) in PageResources. If the page is not found in the server the underlying HttpConnector will get a "404 not found".(there are other situations as well ex: unauthorized etc...) Currently these are not identified in the low level rest connector. So I deprecated the "class Requests" (because I don't wont to break application layer code in the earlier project) . Made a new class that throws the exceptions up.
Also some methods as "public String addPage(Page page)" return the response codes up to the Application layer . This does not seem a good idea for me. The knowledge of response codes should be handled in there itself. An exception should be thrown for unsuccessful operations. Currently String "error" is passed up for IOExceptions. I re-factored back to throw RestConnectionException for IO errors. I will introduce a new exception RestException , to be thrown at these exceptional situations.
What is you opinion on introducing exceptions?
I completely agree with you.
The current exception hierarchy is as follows.
Exceptions at RestConnector (low level fine grained XWiki Restful API) RestConnectionException : for IO errors RestException : to capture and throw as a exception, 404, 401, 405.....
Exceptions at the Restful Access Layer. RestAPIUsageException : runtime exception. For things that cannot be handled. RALException : RestException are wrapped. Well in a more friendly manner. ex: add object to a Document in a document update operation. Client App is ignorantly adding a object to a page that is not yet even created. So a 405 is returned. This is thrown as a RestException from the Connector layer(low level) At the RAL we see the 405 and identify that this was because page was not created earlier. We wrap the RestException in RALException and give the more friendlier message.( Also note that the client can handle this exceptional situation by asking the RAL to do a create document)
Can you give your opinion on this?
Sounds good to me, will think more about the details and will tell you if I have some things I think about.
Regards Sasinda. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (2)
-
sasinda rukshan -
Thomas Mortagne