On Wed, Feb 1, 2017 at 6:15 AM Manuranga Perera <m...@wso2.com> wrote:
> 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. > It is not some boilerplate code. It does have its own logic. :-) > > > 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 > > +1. This does not mean we are limited by these though. When you have complex logic I would rather do it in Java than JS. Especially for IS portals, we are following 90/10 rule where 90% of the code is executed in the back-end. So, there's a lot of logic involved in the backend. > - > > > On Tue, Jan 31, 2017 at 7:40 PM, KasunG Gajasinghe <kas...@wso2.com> > 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 <danush...@wso2.com> > 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 <m...@wso2.com> wrote: > > > ---------- Forwarded message ---------- > From: *Manuranga Perera* <m...@wso2.com> > Date: Tue, Jan 31, 2017 at 2:44 PM > Subject: Why re-write User class? Why re-wrap RealmService? > To: Kasun Gajasinghe <kas...@wso2.com>, Indunil Upeksha Rathnayake < > indu...@wso2.com>, Danushka Fernando <danush...@wso2.com>, Ayesha > Dissanayaka <aye...@wso2.com> > Cc: Kishanthan Thangarajah <kishant...@wso2.com>, Rasika Perera < > rasi...@wso2.com>, Shariq Muhammed <sha...@wso2.com>, Shan Mahanama < > sh...@wso2.com>, Sajith Ariyarathna <sajit...@wso2.com> > > > 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 : m...@wso2.com > > > > -- > With regards, > *Manu*ranga Perera. > > phone : 071 7 70 20 50 > mail : m...@wso2.com > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > > > _______________________________________________ > Dev mailing list > Dev@wso2.org > 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 : m...@wso2.com > -- *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, 77 678 0813
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
