[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Need advice for BBAPI refactoring
|
Hi Erkki,
On 4/3/07, Erkki Lindpere <erkki@xxxxxx> wrote:
I started looking at the bot framework to see how it could relate to my
own bot code, then noticed that some of my code was broken due to the
Presence API refactoring (great work BTW!) and started updating it.
Unfortunately, I can't tell whether you're being sarcastic or not here.
So what I'm thinking now is:
a) make IMember extend IUser (from ECF Core)
b) replace usage of IMember in BBAPI with IUser as much as possible
c) use IMember only where group membership is concerned
d) IUser has a properties map -- maybe a property should tell whether a
user is a guest or not?
Does this sound good? Looking at IUser usage, it currently seems to be
used exclusively by UI bundles.
Don't really like A or B, and as you mentioned, it's not really used
much. Only place I can think of is as a representation of a local user
via IRoster's getUser() method, so it's not really appropriate for
"any user". I definitely will give a -1 D since I'm not a big fan of
the whole properties deal.
So I think C is the best route because all members are in a group
(certainly any phpbb, invision, and vbulletin forums I have partaken
in) but guests are not.
2) The Presence API prefers returning ID-s instead of full objects. For
example, IIMMessage.getFromID() returns ID instead of some kind of User
object. Bulletin Board API currently returns full objects in most cases.
This originates from my own usage of the API -- it was/is mostly used in
a way that usually expects to easily find the posters name and other
details about a post. For example some Velocity templates could be
written to directly reference a message author's name if given an
IMessageBase object: ${message.from.name}.
However, if BBAPI usage is to increase, such optimizations may not fit
all use cases and perhaps should be moved out of the API and left to the
client code? What do you think? On the other hand, returning ID-s and
expecting the full objects to be looked up separately if needed makes it
less object oriented IMO.
I guess the retrieval of additional information beyond what the ID
interface offers is generally up to a call to getAdapter(Class),
though of course, it is not realistic to expect every provider
implementation to do things this way. I think it is not a big deal in
your case because an ID is a unique identifier just as how an IMember
is unique to a forum, and it conveys the same information, per se.
3) Break some of the API-s into parts similar to the presence API's
I*Manager -s. Not sure yet how exactly I would do this.
I took a passing glance over it but I can't really see any need for
manager classes. A forum is a very rigid and tight data structure with
a specific flow to it, there is nothing that needs to be "managed" in
my opinion.
Regards,
Rem
