Github user Leemoonsoo commented on the pull request:
https://github.com/apache/incubator-zeppelin/pull/740#issuecomment-190285327
Hi @doanduyhai. Sorry for the late response. I've got some feedbacks here.
##### two different feature in a function.
I think it's more clear to provide `z.runParagraph()` than
`z.angularBind()` has flag of runParagraph.
Having two different feature in a single function should be avoided.
##### passing paragraph id.
It's passing paragraph id or ids using paragraph / paragraphs field in
Parameters.
I think it can be improved by considering two perspective. The First one is
easy of use. User need to repeat paragraph id to series of z.angularBind()
again and again. e.g.
```javascript
z.angularBind('name1', value1, { paragraph : '20160126-153136_1060166247'})
z.angularBind('name2', value2, { paragraph : '20160126-153136_1060166247'})
z.angularBind('name3', value3, { paragraph : '20160126-153136_1060166247'})
...
```
Second one is notebook portability, the code now depends on paragraph id
and it's not portable anymore. If you export notebook and import notebook, the
code will not work anymore unless user update all paragraph id in the code.
Considering easy of use and notebook portability, i think following style
of API would help.
```javascript
// we can get paragraph id from any html element in the paragraph.
// This way, paragraph id is no longer hardcoded so notebook becomes more
portable.
var z = getZeppelinContext(htmlElement)
// user can avoid passing paragraph id repeatedly.
z.angularBind('name1', value1)
z.angularBind('name2', value2)
z.angularBind('name3', value3)
```
##### front-end z.angularBind() call creates/updates angularObject into all
interpreters binded.
z.angularBind() updates angularObject of all interpreters binded.
I think it should be update one interpreter who serves that particular
paragraph.
##### Advantage of having API in both front-end, back-end side
It's more general question. Basically, this PR brings the API that
currently only back-end side provides.
There can be Pros and Cons.
Cons side, if user creates something that mixes both front-end side API and
back-end side API at the same time, while front-end side(js in webbrowser) and
back-end side (heterogeneous interpreters) runs asynchronously, i can easily
imagine understanding behavior of those code will be really difficult.
Not having front-end API will force user manage all angularObject in one
side (back-end side), that will help simplicity of use.
Could you explain advantage of having API in both front-end and back-end
side ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
