Hi Kasun, > #1. Because UUF's #createSession function expects an instance > of org.wso2.carbon.uuf.spi.auth.User not org.wso2.carbon.identity.mgt.User > . > > But, this is actually an improvement that we need to do. UUF should > either use org.wso2.carbon.identity.mgt.User or an extended class. We > should not have two User objects. *@UUF team*, what are you thoughts on > this? > +1
#2. The reason is to have a balance between Nashorn js code and Java code. > If we eliminate this client service class, then we have to move the code to > Nashorn js. So, this does not result in less code. Having a client class is > preferable since Java execution is faster and developers are more familiar > with that. > >From UUF perspective, agreed. We should have part of the logic in java side (although I don't think execution time should be a key factor in deciding that, unless it's a computation heavy algorithm, eg a sort). But concern here has nothing to do with UUF vs Java. Danushka perfectly pointed it out, giving an excellent reference. It is boilerplate code that doesn't do any actual logic, just call someone else. PS: I have added following to the UUF best practices doc > Keep code in Java side, if > > - It talks to the database > - It touches the file system > - Computation heavy > - Needs multi threading to work > > On Tue, Jan 31, 2017 at 7:40 PM, KasunG Gajasinghe <[email protected]> wrote: > Hi Manu, > > #1. Because UUF's #createSession function expects an instance > of org.wso2.carbon.uuf.spi.auth.User not org.wso2.carbon.identity.mgt.User > . > > But, this is actually an improvement that we need to do. UUF should > either use org.wso2.carbon.identity.mgt.User or an extended class. We > should not have two User objects. *@UUF team*, what are you thoughts on > this? > > > #2. The reason is to have a balance between Nashorn js code and Java code. > If we eliminate this client service class, then we have to move the code to > Nashorn js. So, this does not result in less code. Having a client class is > preferable since Java execution is faster and developers are more familiar > with that. > > On Tue, Jan 31, 2017 at 8:31 PM, Danushka Fernando <[email protected]> > wrote: > >> I guess the idea was to write an api layer for web app which will call >> backend services and get all the data and do all the processing and return >> data sets that can directly be used in the frond end / UUF application. If >> there are no security reasons, +1 to remove the Middle man. >> >> [1] https://sourcemaking.com/refactoring/smells/middle-man >> >> Thanks & Regards >> Danushka Fernando >> Senior Software Engineer >> WSO2 inc. http://wso2.com/ >> Mobile : +94716332729 <071%20633%202729> >> >> On Tue, Jan 31, 2017 at 8:14 PM, Manuranga Perera <[email protected]> wrote: >> >>> >>> ---------- Forwarded message ---------- >>> From: Manuranga Perera <[email protected]> >>> Date: Tue, Jan 31, 2017 at 2:44 PM >>> Subject: Why re-write User class? Why re-wrap RealmService? >>> To: Kasun Gajasinghe <[email protected]>, Indunil Upeksha Rathnayake < >>> [email protected]>, Danushka Fernando <[email protected]>, Ayesha >>> Dissanayaka <[email protected]> >>> Cc: Kishanthan Thangarajah <[email protected]>, Rasika Perera < >>> [email protected]>, Shariq Muhammed <[email protected]>, Shan Mahanama < >>> [email protected]>, Sajith Ariyarathna <[email protected]> >>> >>> >>> 1) Why have we written org.wso2.is.portal.user.client.api.bean.UUFUser >>> instead of just reusing org.wso2.carbon.identity.mgt.User ? >>> >>> >>> 2) Even better, is there anything stopping us from directly calling >>> RealmService OSGi service from the UUF js (eg: for list users) instead >>> going through IdentityStoreClientServiceImpl wrapper. >>> >>> Less code the better. >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : [email protected] >>> >>> >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : [email protected] >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > > *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc. > email: kasung AT spamfree wso2.com > linked-in: http://lk.linkedin.com/in/gajasinghe > blog: http://kasunbg.org > phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813 > > -- With regards, *Manu*ranga Perera. phone : 071 7 70 20 50 mail : [email protected]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
