On 8/2/2013 4:41 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Friday, 2 August, 2013 12:33:05 AM
> Subject: [keycloak-dev] latest commits and next steps
>
> I had to refactor my code a bit to support Picketlink 2.5.Beta6 and the
> picketlink abstraction we have. So you may have issues when you merge.
> Another thing I had to do was disable all of your modules because it
> depended on an earlier version of Picketlink. I would have fixed your
> code, but I'm not sure what you're doing with it, or if it will just be
> deprecated and removed as we move forward.
No problem, I'll sort it out. Social should definitively be a separate module, in
fact I'd like there to be one social module, then one separate module per social site
we integrate (social, social-facebook, social-twitter, etc.). There's quite a lot of
stuff in UI, and this could also be deployed separately, so it makes sense to leave that
as a separate module. Sdk-html I'm not 100% sure about, maybe we can leave it as a
separate module until it's closer to finished then see whether or not it would make
sense to merge it into services.
I don't doubt you'd need separate modules.
>
> Do you mind if I hook your UI into the services I wrote? I'd really
> like to get a better hold on angular and this would be a good task for
> me to do. Do you have enough work that wouldn't conflict with this
> work? I'll have to expand my REST interfaces and refactor your code a
> bit too. I'd probably just copy it.
Feel free. BTW if you're very fresh to Angular I'd highly recommend going through
the tutorial on the website (
http://docs.angularjs.org/tutorial). My plan was going to
finish the social stuff, then start doing the login/registration forms. We also need a
JavaScript SDK. At the very least it has to be able to parse/validate the bearer token.
Ya, I skimmed the tutorial and walked through eventjuggler code a few
weeks ago and got a good idea.
What code are you talking about refactoring? If you're referring
to the UI REST endpoints, those where really intended as throw-away, so you can do
whatever you want with that.
The REST endpoints and will probably have to add to refactor the admin
UI too.
BTW, eventually we might also want to introduce EJBs/CDI to at least
manage the persistence session/transactions. I couldn't do it with
JAX-RS filters because response filters aren't run after a resource
locator is invoked, nor are do they run if a servlet forward has been
done. Instead I've been using the old inner-class wrapper pattern.
Honestly its much easier and faster to test code this way. Arquillian
is a beast, IMO, but this inner class approach is error prone.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com