Github user Leemoonsoo commented on the pull request:
https://github.com/apache/incubator-zeppelin/pull/740#issuecomment-191504454
#### two different feature in a function.
> The reason why I add the runParagraph option for z.angularBind() is that
it will be used in 80% of the time. Indeed, what's the point to bind an Angular
variable if you don't refresh immediately the target paragraph for quick update
? I can't see any use-case where the user bind an Angular variable and do not
click on the "Run" button on the target paragraph(s) or on the whole notebook
itself.
>
> If we remove the runParagraph option, to achieve the same feature, we'll
need:
> ```
> <input type="text" ng-click="z.angularBind(....); z.runParagraph(...)" >
> ```
> or worst, the user should manually click on the target paragraph like in
the screenshot, it's far from being user-friendly.
Idea behind AngularDisplaySystem was, give possibility to interpreter
(back-end) interact with front-end. By leveraging two way binding and watcher
of AngularJS, AngularDisplaySystem could able to work without introducing any
Zeppelin API in front-end side.
Current api is designed like
| Actions | Front-end API | Back-end API |
| ------------- | ------------- | ------------- |
| Initiate binding | N/A | z.angularBind(var, initialValue) |
| Update value | same to ordinary angularjs scope variable |
z.angularBind(var, newValue) |
| Watching value | same to ordinary angularjs scope variable |
z.angularWatch(var, (oldVal, newVal) => ) |
| Destroy binding | N/A | z.angularUnbind(var) |
in my understanding, this PR trying to change it, to
| Actions | Front-end API | Back-end API |
| ------------- | ------------- | ------------- |
| Initiate binding | z.angularbind(var, initialValue) | z.angularBind(var,
initialValue) |
| Update value | same to ordinary angularjs scope variable, or
z.angularBind(var, newValue) | z.angularBind(var, newValue) |
| Watching value | same to ordinary angularjs scope variable |
z.angularWatch(var, (oldVal, newVal) => ) |
| Destroy binding | z.angularUnbind(var) | z.angularUnbind(var) |
In this perspective, i'm not sure it's good to embed run paragraph inside
of z.angularBind() function in front-end side, while corresponding api in
backend side does not.
Also not every case uses angular displays system to let user click and run
other paragraph.
Angular display system can be used to dynamically update front-end without
re-run the paragraph like this example
https://gist.github.com/granturing/a09aed4a302a7367be92.
So, to me, it's less ambiguous and more consistent to have two apis.
z.angularBind() and z.runParagraph().
#### passing paragraph id.
> But this issue also applies to ZeppelinContext.runParagraph(String
paragraphId) if we had chosen to use the ZeppelinContext to run paragraphs in
the back-end instead of front-end so I would say this issue is not really a new
issue, it has always been there.
Right, if user use just hardcoded paragraph id to call existing
`ZeppelinContext.runParagraph(String paragraphId)` then the problem will be
there. However, current API set provides option to write code without hardcoded
paragraph id.
```
z.runParagraph(z.getInterpreterContext.getParagraphId)
```
In the similar manner,
```
<div id="myEl"></div>
<script>
var htmlElement = angular.element('#myEl')
var z = getZeppelinContext(htmlElement)
...
</script>
```
will give an option to avoid use hardcoded paragraph id.
htmlElement is html Element that created by user code in the paragraph.
That's only way i know get current paragraph id from the javascript that
defined in particular paragraph.
> I think we should fix the dynamic paragraph id and persist the paragraph
id at the same time as the paragraph content. As far as I can see, the
paragraph id is generated using some timestamp plus a random part so there is
very few chance of collision. Consequently it is possible to export a note with
all the original paragraph ids and import them elsewhere
paragraph id can not be simply changed, while of some features (rest api to
run paragraph, iframe link, ...) and a lot of internal code (angulardisplay
system, job scheduler, etc) assumes paragraph id is immutable.
#### front-end z.angularBind() call creates/updates angularObject into all
interpreters binded.
> Allow me to disagree with this idea, if there are 10 paragraphs in the
note with 10 different interpreters, it will create a lot of pollution. There
is no reason that we push the Angular variable to many interpreters that are
not used by the target paragraph(s).
>
> Another argument against binding the variable to all interpreters used by
the note is because Angular variables are persisted in note.json file so we'll
create a lot of data that will be exported/re-imported and not used ....
Right, that's what i wanted to say actually :-)
#### Advantage of having API in both front-end, back-end side
> There is also a demande on the user-mailing list recently to be able to
update Angular variable from the front-end:
>
> So the demand for controlling Angular variable from the front-end is
real, not just some fancy idea I have in mind.
The question from the mailing list, "pass variable defined in a angular
interpreter to another paragraph which is scala interpreter", i can convert it
to "how to initiate angularObject binding from the front-end code?" Because
passing variable from front end to back end is already possible once they're
binded.
---
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.
---
