selection, creation, upload/download files/directories resides on the
server side.
This will be useful for file selection/creation for different server
side utilites like pg_dump, pg_dumpall, pg_restore.
There are times, a module is loaded multiple times, and returns same set
of CSS files mulitple times, in order to avoid loading the same file
multiple times, we will create a set out of the list of CSS files.
required by its javascript module.
This will allow us to load the javascript modules as a static file, and
not as a Jinja2 template. This will increase the load time, as it will
decrease number of templates to be processed during loading those
javascripts.
While accessing the configuration database from multiple session, it
results in to the error - OperationError, because - sqlite locks all the
database, and does not allow to access it simultaneously. We added the
timeout to give some time window for accessing it simultaneously.
DriverRegistry is executed second time.
Also, initialize the driver before registering different blueprints,
which uses those driver inside them.
Thanks Khushboo for reporting the issue.
server connection.
The BaseDriver and BaseConnection are two abstract classes, which allows
us to replace the existing driver with the currently used. The current
implementation supports to connect the PostgreSQL and Postgres Plus
Advanced Server using the psycopg2 driver.
(lazy loading) using the require.js. This allows us to load the
javascript required for any node, only when it was loaded in the browser
tree. Also, introduced the mechanism to show/edit/create of any node in
a tab panel (wcDocker.Panel).
submodules inherited from the PgAdminModule instead of regular
Blueprint. This allows us to load the module automatically from the
under the pgadmin directory, and will work to extend the pgAdmin
extension module.
PgAdminModule is inherited from the Blueprint, and bring several
methods:
- get_own_stylesheets, which returns the stylesheets used by the module
(excluding its submodules stylesheets)
- get_own_javascripts
- menu_items, which returns a dictionray mapping the old hook names
(context_items etc) to a list of MenuItem instances
For more specialized modules (as for now, any module that should be part
of the browser tree construction), one can define an abstract base class
defining additional methods.
For example, the BrowserPluginModule abstract base class defines the
following methods:
- jssnippets
- csssnipeets
- node_type
- get_nodes
This commit adds the following:
- Storage of server groups in the configuration database
- Creation of a default server group on in the database
- A mechanism for plugging in treeview node types
- A node type for server groups with:
- Treeview display
- Custom per-node javascript implementing a menu option/dialogue to add new groups
- Custom per-node CSS to style the treeview node
- JSON formatted data in response to AJAX requests, including:
- Success/failure indication
- Error message
- Extra info (e.g. stack trace)
- The original request data
- Additional return data, e.g. node ID and label etc.
Modules may now include functions that return lists of menu items
that will be included on the main browser window menu. While we're
at it, move the test views into a separate module.
This uses a single default user in the config database, which is
auto-logged into the app when SERVER_MODE = False. In this mode we
also hide/remove user-related functions in the UI.
A user authentication module based on flask-security is added, which
allows users to login and change/recover passwords etc. Custom templates
are included for the user/password UIs.
A new setup script will initialise the user (and later settings) DB,
adding the first user and granting them an Administrator role.
A redirects blueprint module is added to handle simple URL redirects.
A browser module is added and currently renders a skeleton page with
a menu bar, gravatar and jumbotron.
NOTE FOR LATER: Currently this code might make the nice basis for any
web app that needs user management and plugins. Hmmm....
