Github user doanduyhai commented on the pull request:
https://github.com/apache/incubator-zeppelin/pull/678#issuecomment-177470392
Thanks @Leemoonsoo for you initial remarks.
> That i'm not quite sure the benefit of reading angularObject in dynamic
form compare to the complexity it brings. I mean complexity of the concept and
expected behavior that user need to understand.
I think I did not define clearly the objectives of this PR so let me
explain it again:
**Functional requirements**: As a Zeppelin user, I would like to design an
HTML form which:
1. can have custom styling and look n feel
2. can have extended form inputs (email input, calendar, checkbox, items
list ...)
3. can have custom behaviors (changing a drop-down will hide/show extra
form inputs)
4. can control the execution of one or many other **paragraph(s)** in the
**same note**
5. can interact with the AngularObjectRegistry for one or many other
**paragraph(s)** in the **same note**. For example, in my form, I want to set
an Angular variable called "name" and in another **pagragraph** execute the
SparkSQL query:
```sql
%sql
SELECT * FROM table WHERE name = ${name}
```
Current Zeppelin **dynamic forms** can be enhanced to support points 2. but
I think it's very hard (unless we redesign it from scratch) to support all
other points. And I want to have a very flexible form system so I need to
design my HTML form in another paragraph with %angular
**That's the main reason I want to be able to override dynamic forms system
if a variable is already present in the AngularObjectRegistry** (_whether it
was bound by a zeppelin context or by an AngularJS function client-side, it
doesn't not matter_). Currently to achieve the same goal, you need to use the
`z.angularUnbind()`, `z.angularBind()` and attach listener **programmatically**
using Scala like in this video: https://youtu.be/J6Ei1RMG5Xo?t=944. It's very
cumbersome, as a web-designer, I want to use pure HTML and AngularJS javascript
to design my forms
> i'd suggest split it into multiple smaller PR, if possible.
Totally agree, I would propose to split this PR in smaller ones like:
1. Add Show/Hide paragraph ID feature
2. Add AngularJS utilities functions (or we can split it in smaller PR, one
for each function (_bindToAngular()_, _unbindFromAngular()_ ...) but I think
one PR for all the functions is enough
3. Override the existing dynamic form with AngularJS
> collect all exposed functions into `z``
+1 Good idea
> So this function name may confuse a bit. How about different name, such
as bindAngularObject() ?
+1. I will rename to `bindAngularObject()` and `unbindAngularObject()` to
match naming convention from the `ZeppelinContext` object
> And this function give user access to any scope of AngularObjectRegistry
of any Interpreter process.
Is there any special reason?
There are **serious reasons** for the current design.
Right now, the current scope of the AngularObjectRegistry are, in
descending order:
1. Interpreter Group
2. Global
3. Note
4. Paragraph
If we want to bind an angular object to a particular **paragraph**, the
noteId is not necessary because we always choose the id from the current note
(and it is not possible to change it to enforce note scope isolation). However,
because of point 1. above, we need to provide also the interpreter group (so
the interpreter name) of the paragraph otherwise we won't be able to retrieve
the AngularObjectRegistry at the server-side. The below piece of code does this
job:
```java
final InterpreterGroup interpreterGroup = findGroupForInterpreter(noteId,
note.getNoteReplLoader().getInterpreterSettings(), interpreterName);
final AngularObjectRegistry registry =
interpreterGroup.getAngularObjectRegistry();
```
That explain why in the `parameters` map, we have the properties
`interpreter: 'sh'` or `interpreters: ['sh','md']`.
---
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.
---
