Per Nyfelt wrote: > > > Sorry default was a bad choice of term. That is the behaviour of that > > method it doesn't change. XMLResource ALWAYS returns String from > > getContent and accepts String in setContent. If you're storing the value > > internally in some other format then you must serialize it to text when > > getContent is called. > > I understand that this is the intended functionality but I think it's not > clear for end users of the api. Yes you could put it in the JavaDoc - that > would help a little but i find this usage of Object as the return type that > is supposed to be one thing for Binary Resource and another for XMLResource > to be confusing. I think that getContent() and setContent() should be > removed from Resource all together and have > String getContentAsString() (or getContentAsText() if that name is > preferred) in XMLResource and > byte[] getContent() (or getContentAsByteArray() whatever is preferred) for > BinaryResource. >
Do you think we can cut down enough on the confusion by simply adding the getContentAsText method in addition to getContent? > An alternative would be to send a String (or an int if you like that better) > as a parameter to the getContent method to get different types back e.g. > I think this just creates more work for the programmer. > We change the signature for getContent() to look like this: > Object getContent(String contentType) > > Then we define the following constant in XMLResource > public static final String STRING_CONTENT_TYPE = String.class.getName(); > public static final String NODE_CONTENT_TYPE = Node.class.getName(); > > And in BinaryResource: > public static final String BYTE_ARRAY_CONTENT_TYPE = byte[].class.getName(); > > In an implementation of XMLResource you could have > getContent(STRING_CONTENT_TYPE) return a String and > getContent(NODE_CONTENT_TYPE) return a Node > > This would make getContentAsDOM() a convenience method. > > In an implementation of BinaryResource > getContent(BYTE_ARRAY_CONTENT_TYPE) would return binary content > > I think it would then become obvious for the user what is going on and what > is expected to come back. > > Best regards, > Per > > ---------------------------------------------------------------------- > Post a message: mailto:[EMAIL PROTECTED] > Unsubscribe: mailto:[EMAIL PROTECTED] > Contact adminstrator: mailto:[EMAIL PROTECTED] > Read archived messages: http://archive.xmldb.org/ > ---------------------------------------------------------------------- -- Kimbro Staken The dbXML Project http://www.dbxml.org/ ---------------------------------------------------------------------- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact adminstrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ ----------------------------------------------------------------------
