Paragraphs should be in the notebook $scope though. Or we can always send event for the paragraphs to execute some actions, but don't think it would help in that case On Jan 12, 2015 5:53 PM, "Kevin (Sangwoo) Kim" <[email protected]> wrote:
> @Damien, > > I mean, with current implementation, > it's really hard to control paragraph focus or move, > because a notebook doesn't know and doesn't control what paragraphs are > under the notebook. > Notebook controller will manage paragraph list in that notebook, and surely > the detailed action will be done in paragraph controller. > > > On Mon Jan 12 2015 at 5:03:22 PM Anthony Corbacho < > [email protected]> wrote: > > > For the refactoring part on the webapp side. > > - refactoring client-side code with clear Notebook\Paragraph object > > model and modularisation (Kibana4 guideline looks good > > https://github.com/elasticsearch/kibana/blob/master/STYLEGUIDE.md) > > JSHint is doing the job already (we are not picky enough on this > part), > > and there is already a notion of Notebook -> collection of paragraph and > > both 'component' are in separate file, we just inject the paragraphs in > the > > appropriate notebook. > > > > On Mon, Jan 12, 2015 at 4:41 PM, Alex B. <[email protected]> wrote: > > > > > Strong +1 on both suggestion, > > > - DI in server-side code (elasticsearch code could be a good example > of > > > codebase benefitted from it) > > > - refactoring client-side code with clear Notebook\Paragraph object > > model > > > and modularisation (Kibana4 guideline looks good > > > https://github.com/elasticsearch/kibana/blob/master/STYLEGUIDE.md) > > > > > > On Mon, Jan 12, 2015 at 4:40 PM, moon soo Lee <[email protected]> wrote: > > > > > > > Hi Anthony, > > > > > > > > Benefits from dependency injection you listed sounds nice. At the > same > > > > time, it sounds just general. To me, it's bit hard to imagine what is > > > > specific problem and what is specific solution you are thinking of. > > > > If you can share one example of problem in zeppelin and show how it > can > > > be > > > > improved, it'll be much helpful for understanding what you are > thinking > > > of. > > > > > > > > In front-end side, i totally agree that there are messes and we need > to > > > > address them. > > > > > > > > Best, > > > > moon > > > > > > > > 2015년 1월 12일 월요일, Kevin (Sangwoo) Kim<[email protected]>님이 작성한 > 메시지: > > > > > > > > > I talked with Anthony with this topic before, > > > > > +1 for refactoring server codes. > > > > > > > > > > Also I insist we need some refactoring on front-end codes. > > > > > The biggest problem is Angular and jQuery are mixed and it's > really a > > > > mess. > > > > > Also I think we need to refine object hierarchy, e,g. a notebook > need > > > to > > > > > manage the paragraph inside it. > > > > > (currently many features are rely on global events, sometime it's > > very > > > > > confusing) > > > > > > > > > > Regards, > > > > > Kevin > > > > > > > > > > On Mon Jan 12 2015 at 4:07:30 PM Anthony Corbacho < > > > > > [email protected] <javascript:;>> wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > This is a question I wanted to ask for long time. > > > > > > What do you think guys about refactoring Zeppelin (java code a > > first) > > > > to > > > > > > follow the principle of Dependency Injection? > > > > > > > > > > > > The benefit I can list are > > > > > > > > > > > > - Reduced Dependencies > > > > > > - Reduced Dependency Carrying > > > > > > - More Reusable Code > > > > > > - More Testable Code > > > > > > - More Readable Code > > > > > > > > > > > > What do you think guys? worth it or not? > > > > > > > > > > > > Best, > > > > > > Anthony > > > > > > > > > > > > > > > > > > > > >
