Skip to content
This repository has been archived by the owner on Feb 12, 2020. It is now read-only.

refactor UI Controller #257

Closed
balmas opened this issue Oct 17, 2018 · 3 comments
Closed

refactor UI Controller #257

balmas opened this issue Oct 17, 2018 · 3 comments

Comments

@balmas
Copy link
Member

balmas commented Oct 17, 2018

from alpheios-project/pwa-prototype/issues/6:

The UI Controller is responsible for application flow and interaction with user input. We will a base version of a UI controller that will define an API and features shared between all device classes. UI controller derived classes will use composition to add device-specific features (drag and resizing, gesture supports, etc.).

@kirlat
Copy link
Member

kirlat commented Oct 26, 2018

@balmas, @irina060981: I think we need to draw a line first between responsibilities of a UI controller and those of a content script. On my opinion:

  1. All browser-specific code should belong to a content script.
  2. Content script should be responsible for listening to a command and control messages from a background (background script or Safari app extension). Those messages would command a content script to create an instance of a UI controller, activate/deactivate it, etc. So the handlers and processors of those messages should be within a content script.
  3. UI controller, as its name suggests, should be responsible for handling all user interactions, except for those that it cannot listen to as those are rendered in a background (icon and menu interactions). So a UI controller and it's subcomponents (the Vue.js ones) will listen to user interactions with a content of a page (mouse clicks, text selections, etc.) mostly.

Do you agree to that concept?

Also, we probably all agree that a UI controller should be modular. Right now we have four types of clients that use a UI controller:

  • Webextension/Safari App Extension
  • Embedded Lib
  • Inflection Games
  • PWA
    I think what should be embedded into a UI controller is the lowest possible denominator between the four. The rest should be optional modules. What do you think?

Webextension requires everything a UI controller has currently (it was created to serve webextension, naturally). PWA probably needs the pretty much the same, but with different panel and popup instances. How about Embedded Lib and Inflection Games? What do they not need from what is currently in a UI Controller?

And finally, what type of modules we might have within a UI controller? Right now I can think of:

  • UI component (panel, popup)
  • Event handler for a specific action (what to do on a double click)
  • Lexical/Resource queries (what queries would a UI controller support)
    Anything else? What's your opinion on this?

@irina060981
Copy link
Member

@kirlat, @balmas, I believe that a part of my answer is in other issue - alpheios-project/webextension#130

But if shortly according to questions here there are my thoughts:

We have these main features used in the project (as I know of course)

  1. geting morph data (morph-client)
  2. geting treebank data (morph-client)
  3. geting grammar data (res-client)
  4. getting definitions (lexical-client)
  5. getting translations (lemma-clients)
  6. getting inflections (inflection-tables)
  7. alignment, treebank editor
  8. panel, popup vizualization (components)
  9. inflection games
  10. webextension wrap
  11. safari app extension wrap
  12. embedded lib wrap
  13. pwa wrap

So we could divide it into 3 big parts:

  1. getting different data - should be upgradable - so it should be in modules with the ability to add new module on some template base
  2. vizualizing data (vue-components for panel, popup, inflection games, lexical tests) - it should be customizable by styles, images and may be having the ability to add new components
  3. different wraps that is communicating with users - extensions, embedded, pwa - and I think embedded shouls be customizable with states, events , Local Storage properties, some data tracking usage

and upon all this there are some library functions that could operate data - UIController, LexicalQuery, Storage/State, Localization, Skins/Branding - components
some libraries that has base classes to data - data-models and inflection-tables.

So I think that we should move to the creation some basic classes, components, and libraries as services to define there required behaviour and they will have basic functioning. For example:

Module with data dictionary (data models + infl;ection-tables),
module with data api manipulating (uicontroller + lexical query + localization + storage)
module with data retrieving adapters (morph, res, lemma etc)
module with basic vizualization (vue-components from components repo)
modules with custom usage (inflection games, lexical tests)
modules for different wraps (embedded + extensions + pwa) with some ability for customization
modules for skins/branding/styling

Hope, I was able to describe my thoughts correctly :)

Anyway as I wrote before - I am not against approach above - as it could be a step to a better future :)

@balmas
Copy link
Member Author

balmas commented Mar 4, 2019

closing this as the major refactoring is now done.

@balmas balmas closed this as completed Mar 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants