On Wed, Feb 1, 2017 at 4:04 PM, Manuranga Perera <[email protected]> wrote:
> Hi Kasun, > > +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. >> > Ok, how about, > >> Must keep code in Java side, if >> >> - It talks to the database >> - It touches the file system >> - Computation heavy >> - Needs multi threading to work >> >> Anything else is up to you to decide, but as a rule of thumb, if it has >> to do with the presentation of the data, not the data itself, it's better >> in JS side. >> > > Yes, makes sense. > > >> It is not some boilerplate code. It does have its own logic. >> > If it has logic its ok, but I don't see it. eg: what is the business logic > in [1]? Every method in it just call the same named method form > RealmService. > > I am sure you remember */ui/**/*ServiceClient.java files [2] from C4. We > also wrote Jaggery module wrappers, eg [3]. I condenser most (not all) of > that code boilerplate, people have spend lot of time to write them, for no > real gain. Feel like we are repeating that same mistake, and not even > seeing it as a mistake, since we are so used to it. > > Please take a step back and think fresh. If you came across this kind of > code [2] [3] for the first time, will you tolerate set of *Zombie classes* > that has no brains of their own, depends on other classes brain to work, > and grows in number over time? If you feel it need to be wrapped for some > reason, (eg: to convert backbend errors to more user friendly errors) let's > invent a proper way (eg: a mapping file in UUF that maps Exception type to > error code/message). Let's not write bunch of wrapper code, again. > > In C4-era, ServiceClient was separated, and it did result in loads of boilerplate code like [1]. In there, we are blindly delegating the call to the stub. Those ServiceClients acts as a proxy, and does not have any real logic. So, this should be avoided in C5. IdentityStoreClientServiceImpl was not intended for that purpose. If we can directly call the realmservice, then we should. [1] https://github.com/wso2/carbon-identity/blob/7a421e21941ff48914115f772d01027766f556a5/components/oauth/org.wso2.carbon.identity.oauth.ui/src/main/java/org/wso2/carbon/identity/oauth/ui/client/OAuthServiceClient.java > > [1] https://github.com/wso2/product-is/blob/6.0.x-C5_m3/ > portal/osgi-services/org.wso2.is.portal.user.client.api/src/ > main/java/org/wso2/is/portal/user/client/api/ > IdentityStoreClientServiceImpl.java > [2] https://github.com/search?utf8=%E2%9C%93&q=ui+* > ServiceClient+in%3Apath+org%3Awso2&type=Code&ref=searchresults (If you do > a find in old svn you'll find more) > [3] https://github.com/wso2/jaggery-extensions/blob/ > master/carbon/module/scripts/user/user-manager.js > > On Wed, Feb 1, 2017 at 5:25 AM, Danushka Fernando <[email protected]> > wrote: > >> Hi Kasun >> I think logic is related to #1. If we are eliminating that then it will >> be a middle man. >> >> Thanks & Regards >> Danushka Fernando >> Senior Software Engineer >> WSO2 inc. http://wso2.com/ >> Mobile : +94716332729 <+94%2071%20633%202729> >> >> On Wed, Feb 1, 2017 at 10:50 AM, KasunG Gajasinghe <[email protected]> >> wrote: >> >>> >>> >>> On Wed, Feb 1, 2017 at 6:15 AM Manuranga Perera <[email protected]> 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 <[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] >>>> >>> -- >>> >>> *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] > -- *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 [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
