Attached is my diff from what I had pulled down as of Wednesday or so. Feel free to discuss, dissect, etc
On Sun, Jul 1, 2012 at 12:49 PM, Jason Porter <[email protected]>wrote: > I have some stuff I did on the plane from Summit. I'm going to go back > over it tomorrow and see if I included everything I wanted. I'll send the > diff to the list. > > Sent from my iPhone > > On Jul 1, 2012, at 9:43, Boleslaw Dawidowicz < > [email protected]> wrote: > > > I think it all comes down (again) to use cases [0] which we think this > API should address. Current ones are mainly around typical web application > development and proposed API prototype was focusing on easy usage. My main > fear is to go end up with too abstract and generic design that won't be > really appealing to most of developers. If you look at use cases addressed > by JSR 351 [1] it is all about dealing with attributes and scenarios closer > to healthcare - and this so far results in quite different API design. API > which I believe will be less appealing to typical web developer who doesn't > care about such use cases. > > > > More inline below > > > > [0] > https://cwiki.apache.org/confluence/display/DeltaSpike/Security+Module+Drafts > > [1] http://java.net/projects/identity-api-spec/pages/UseCases > > > > On Jun 29, 2012, at 4:56 PM, Jason Porter wrote: > > > >> == Security IDM prototype feedback == > >> > >> * Fold PermissionQuery into PermissionManager to give the developers a > >> similar model as JPA. > >> > >> * Because a Group is an IdentityType, I wonder if it would be better to > >> just have one set of methods and pass in the IdentityType sub interface > you > >> would like to receive back > > > > I guess thats a bit matter of taste. We could prepare quick prototype > and compare which one looks more useful to majority of folks here. > > > >> > >> * I feel the methods on UserQuery are restricting how the IDM can be > used. > >> We can't always guarantee that there will be a first name, last name, > >> email, etc. However, being completely open and free form like what was > done > >> in the PicketLink IDM is too much. Perhaps we can find some sort of > balance > >> or meta model similar to JPA? > >> > >> * Maybe we could have a base no method interface for things and fold all > >> the Query and Manager objects into one (similar to above about JPA) > >> > >> * We probably don't want to go down the route of create a query > language, > >> but we almost have a DSL with a fluent API here. Maybe we should think > >> about about JPA the names out a bit more and actually create a fluent > API > >> for the Query objects > > > > Would you have time to prepare some simple prototype like this to > discuss? I'm not sure how much generic design are you proposing in fact. > Just some bare code snippets would do to back your suggestions with some > example usage. > > > > UserQuery is not something I'm perfectly satisfied with however it is > still an attempt to have something similar to JPA Criteria Query - which is > very intuitive and easy to use IMO. I would love to see more feedback from > others on how to improve this part in fact. > > > >> > >> * I believe we should remove some of the exception constructors and > make a > >> message required (this would probably be good to have in all of > >> DeltaSpike). Adding a cause is great, but being able to create an > exception > >> without a message is less helpful for everyone. > > > > Good point. I think this part is simply not really polished yet. > > > >> > >> * Is there a point for having addObject and addObjects type methods? > Would > >> one that's simply a varag be enough? We could check the type that comes > in > >> if thy send us a collection, or simply have varags and collection > >> addObjects methods. > > > > Sounds good to me. Again this is probably more matter of taste and > consistency with other APIs in the project. Maybe there should be some > general project wide design guideline for choices like this. > > > > > >> > >> > >> -- > >> Jason Porter > >> http://lightguard-jp.blogspot.com > >> http://twitter.com/lightguardjp > >> > >> Software Engineer > >> Open Source Advocate > >> Author of Seam Catch - Next Generation Java Exception Handling > >> > >> PGP key id: 926CCFF5 > >> PGP key available at: keyserver.net, pgp.mit.edu > > > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu
