3:33 p.m.
Hi Marek,
That's nearly what you wrote. This session manager is not yet in the API. The
SocialClient class in the Webapp example is a start for it.
First I have Injected lazily all the OAuthService beans :
@Inject
@Any
private Instance<OAuthService> serviceHandlerInstances;
Then I can dynamically instantiate a new bean for a given service in a method called from
the UI :
OAuthService newService=serviceHandlerInstances.select(new
RelatedTo.RelatedToLiteral(Service.Twitter)).get();
I only have to parameterize the Service.Twitter enum value and then add newService to a
Set of managed Service in my sessionManager. With a Set I can avoid doubloon account by
implementing equals() and hashcode() in my services based on userid for instance.
What I need to do now to finish :
1) create a clean separation between OAuthServiceSettings (OAuth Application config for a
given service), OAuthService (bean managing calls to service) and OAuthUserSettings (user
access token and probably a link to userid). The two last are still mixed so
OAuthUserSetting doesn't exist right now
2) create this Session manager where I'll be able to gather and mashup sessions to any
service (even multiple session to the same service).
3) Writes tests, tests, tests (I know you like this one)
4) Write doc, doc, doc...
5) create an extension to allow registration of an Oauth service bean with a qualifier
like in Seam Rest
6) import S***g Social model classes an call methods to map JSon and XML value returned by
services
7) Write more tests and more doc :-).
Regarding the point 1) the idea is to have simple settings beans that could be extended
later to become JPA entity or be loaded/written from/to a config file or being easily
injected for tests. I just want to avoid having a Spring like (stateless) OAuthService
with all the config parameter in each method signature...
Thanks for your feedback on this tasks list.
Antoine SABOT-DURAND
Le 17 mai 2011 à 17:48, Marek Schmidt a écrit :
----- Original Message -----
> From: "Antoine Sabot-Durand" <antoine(a)sabot-durand.net>
> To: seam-dev(a)lists.jboss.org
> Sent: Monday, May 16, 2011 6:25:23 PM
> Subject: [seam-dev] Seam social API stabilisation is near.
> Hi Team,
>
> After some pain, suffering and knots in my brain, I found a clean
> answer to my multi-account issue (thanks to dependent scope, @Any
> qualifier and Instance<> class).
> I created a qualifier to distinguish different services beans in a
> polymorphic context. The purpose of this qualifier is only to bind
> some beans (settings, controller) to a given social service. To be as
> generic as possible it takes a binding (in opposition to @Nonbinding)
> parameter which is an enum related to service name. So
> @RelatedTo(Service.Twitter) qualifies a bean in relation to Twitter.
> I'm not very happy with this name "RelatedTo" but didn't found
> something short and eloquent (I avoided @InRelationTo :-) ).
> Suggestion and commentaries are welcome. (the source is in
> multi_account feature branch)
Hi Antoine!
I am not exactly sure I understand correctly what is a multi-account issue, so let me
just write how I see it and correct me afterwards :) These new qualifiers will allow me to
create, let's say, multiple Twitter OAuthServiceSettingsImpl beans, right? I
understand that is useful when I want to configure different service providers that have
the same implementation (such as generic OAuth providers).
From reading SEAMSOCIAL-12, what I thought was a multi-account issue, is that you want a
single user (session) be tied to several accounts (that could or could not be from the
same service, so I can have two twitter accounts and one facebook account). I see this
issue as orthogonal to the one with multiple services, because I still don't see how I
would accomplish this using the new multi_account API. To do that I would imagine I would
need something like a session scoped account manager, which would manage my OAuthServices
and let me list them, authorize them, create new ones from configured
OAuthServiceSettings, etc...
Cheers,
Marek Schmidt
>
> thxs
>
> Antoine SABOT-DURAND
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
--