You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by James M Snell <ja...@gmail.com> on 2006/06/22 23:20:51 UTC
API Refactoring
There are a number of API refactorings that I've been meaning to do for
a while to simplify the way entry content and text elements are set.
Whereas currently the API has a whole bunch of methods like
entry.setContentAsText(...), entry.setContentAsXhtml(...), etc, the
refactoring I have ready to check in changes it to just a limited
handful of setContent(...) methods with various options. The same kind
of refactoring is applied to all of the various
setTitle/setRights/setSubtitle/setSummary methods. This refactoring also
affects content/text related methods in the Factory interface.
//<content type="text">Testing</content>
content = entry.setContent("Testing");
//<content type="html"><p>Testing</p></content>
content = entry.setContent(Content.Type.HTML, "<p>Testing</p>");
//<content type="xhtml">
// <div xmlns='http://www.w3.org/1999/xhtml'>Testing</div>
//</content>
content = entry.setContent(
Content.Type.XHTML,
"<div xmlns='http://www.w3.org/1999/xhtml'>Testing</div>");
//<content type="application/xml"><a><b /></a></content>
content = entry.setContent(
new MimeType("application/xml"),
"<a><b/></a>");
//<content type="text/plain">foo</content>
content = entry.setContent(new MimeType("text/plain"), "foo");
//<content type="image/png">{base64}</content>
content = entry.setContent(
new MimeType("image/png"),
new DataHandler(new ByteArrayDataSource("foo".getBytes())));
//<content type="image/png" src="http://foo" />
content = entry.setContent(
new MimeType("image/png"), new URI("http://foo"));
Thoughts? Complaints? Concerns before I check it in?
- James
Re: API Refactoring
Posted by Elias Torres <el...@torrez.us>.
+1
I'd rather we start with less.
-Elias
James M Snell wrote:
> The key improvement is that this refactoring eliminates a large number
> of fairly redundant methods. That said, the goal should be to make the
> most common cases as easy as possible. To that end, having
> setContentAsHtml(string), setContentAsXhtml(string) method makes sense.
> I'll make sure those stay in.
>
> - James
>
> Garrett Rooney wrote:
>> On 6/22/06, James M Snell <ja...@gmail.com> wrote:
>>
>>> Thoughts? Complaints? Concerns before I check it in?
>> I'm honestly not sure it's a huge improvement in useability. You end
>> up typing a lot more this way (setFooAsXhtml("blah") ->
>> setFoo(Content.Type.XHTML, "blah")), and instead of distinct methods
>> that do different things you've got methods with the same name that do
>> potentially different things. How is this a step forward again?
>>
>> -garrett
>>
>
Re: API Refactoring
Posted by James M Snell <ja...@gmail.com>.
The key improvement is that this refactoring eliminates a large number
of fairly redundant methods. That said, the goal should be to make the
most common cases as easy as possible. To that end, having
setContentAsHtml(string), setContentAsXhtml(string) method makes sense.
I'll make sure those stay in.
- James
Garrett Rooney wrote:
> On 6/22/06, James M Snell <ja...@gmail.com> wrote:
>
>> Thoughts? Complaints? Concerns before I check it in?
>
> I'm honestly not sure it's a huge improvement in useability. You end
> up typing a lot more this way (setFooAsXhtml("blah") ->
> setFoo(Content.Type.XHTML, "blah")), and instead of distinct methods
> that do different things you've got methods with the same name that do
> potentially different things. How is this a step forward again?
>
> -garrett
>
Re: API Refactoring
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 6/22/06, James M Snell <ja...@gmail.com> wrote:
> Thoughts? Complaints? Concerns before I check it in?
I'm honestly not sure it's a huge improvement in useability. You end
up typing a lot more this way (setFooAsXhtml("blah") ->
setFoo(Content.Type.XHTML, "blah")), and instead of distinct methods
that do different things you've got methods with the same name that do
potentially different things. How is this a step forward again?
-garrett
Re: API Refactoring
Posted by James M Snell <ja...@gmail.com>.
Yeah, I realized what you'd meant after I stepped out for a bit. :-)
Stephen Duncan wrote:
> Well, not literally, I suppose. But I mean that there are several
> methods with the same name, one that takes in only the content, and
> the rest that take content & a MIME type. I prefer the "extra"
> parameter to come after the common one. That's what I meant.
>
> -Stephen
>
> On 6/22/06, James M Snell <ja...@gmail.com> wrote:
>> For the methods that accept MimeType, it is not optional. That is, if
>> @type is not "text", "html" or "xhtml", a mime type MUST be specified.
>>
>> - James
>>
>> Stephen Duncan wrote:
>> > Seems like the MimeType should be the second parameter, not the first.
>> > At least, that's my preferred style; optional parameters are tacked
>> > on after, required ones...
>> >
>> > - Stephen
>> >
>>
>
>
Re: API Refactoring
Posted by Stephen Duncan <st...@gmail.com>.
Well, not literally, I suppose. But I mean that there are several
methods with the same name, one that takes in only the content, and
the rest that take content & a MIME type. I prefer the "extra"
parameter to come after the common one. That's what I meant.
-Stephen
On 6/22/06, James M Snell <ja...@gmail.com> wrote:
> For the methods that accept MimeType, it is not optional. That is, if
> @type is not "text", "html" or "xhtml", a mime type MUST be specified.
>
> - James
>
> Stephen Duncan wrote:
> > Seems like the MimeType should be the second parameter, not the first.
> > At least, that's my preferred style; optional parameters are tacked
> > on after, required ones...
> >
> > - Stephen
> >
>
--
Stephen Duncan Jr
www.stephenduncanjr.com
Re: API Refactoring
Posted by James M Snell <ja...@gmail.com>.
For the methods that accept MimeType, it is not optional. That is, if
@type is not "text", "html" or "xhtml", a mime type MUST be specified.
- James
Stephen Duncan wrote:
> Seems like the MimeType should be the second parameter, not the first.
> At least, that's my preferred style; optional parameters are tacked
> on after, required ones...
>
> - Stephen
>
Re: API Refactoring
Posted by Stephen Duncan <st...@gmail.com>.
Seems like the MimeType should be the second parameter, not the first.
At least, that's my preferred style; optional parameters are tacked
on after, required ones...
- Stephen
On 6/22/06, James M Snell <ja...@gmail.com> wrote:
> There are a number of API refactorings that I've been meaning to do for
> a while to simplify the way entry content and text elements are set.
> Whereas currently the API has a whole bunch of methods like
> entry.setContentAsText(...), entry.setContentAsXhtml(...), etc, the
> refactoring I have ready to check in changes it to just a limited
> handful of setContent(...) methods with various options. The same kind
> of refactoring is applied to all of the various
> setTitle/setRights/setSubtitle/setSummary methods. This refactoring also
> affects content/text related methods in the Factory interface.
>
> //<content type="text">Testing</content>
> content = entry.setContent("Testing");
>
> //<content type="html"><p>Testing</p></content>
> content = entry.setContent(Content.Type.HTML, "<p>Testing</p>");
>
> //<content type="xhtml">
> // <div xmlns='http://www.w3.org/1999/xhtml'>Testing</div>
> //</content>
> content = entry.setContent(
> Content.Type.XHTML,
> "<div xmlns='http://www.w3.org/1999/xhtml'>Testing</div>");
>
> //<content type="application/xml"><a><b /></a></content>
> content = entry.setContent(
> new MimeType("application/xml"),
> "<a><b/></a>");
>
> //<content type="text/plain">foo</content>
> content = entry.setContent(new MimeType("text/plain"), "foo");
>
> //<content type="image/png">{base64}</content>
> content = entry.setContent(
> new MimeType("image/png"),
> new DataHandler(new ByteArrayDataSource("foo".getBytes())));
>
> //<content type="image/png" src="http://foo" />
> content = entry.setContent(
> new MimeType("image/png"), new URI("http://foo"));
>
> Thoughts? Complaints? Concerns before I check it in?
>
> - James
>
>
--
Stephen Duncan Jr
www.stephenduncanjr.com