with schema specified object name. This will also works with
EntepriseDB's package too.
Also, added dependency on the current connection object, it will allow
us to use the keywords list specific to the database server in futuer.
You can use the qtIdent template filter as:
conn|qtIdent(name)
or,
conn|qtIdent(schema_name, name)
inputs.
In order to do the proper quoting around the identifier, different type,
and literal, we introduced respective functions qtIdent, qtTypeIdent,
qtLiteral in psycopg2 driver. Also, introduced them as the Jinja's
custom filter for using it directly inside the templates.
Also, created an utility - generate_keywords.py in order to generate
keyword lists from the latest PostgreSQL installation.
Introduced a new ajax function to return the HTTP Status code 410 (GONE).
Changed the location of the javascript from each modules, it loads.
Added .swp, .swo files in the .gitignore file
- Allow to release connection using the database OID (did).
- Generate correct url for the collection nodes.
- Removed the server-type from the collection node module, from the
generate_browser_collection_node(...) function.
- Show version string, and not version integer in the server properties
(when connected).
connect to the database server. Also, added modified the way, we do
check the node is supported by the server.
Instead of creating separate blueprint for the server types, they will
be independently works. In order to add different variant of the
PostgreSQL, we need to extend the ServerType class, and override the
'instanceOf' function for identification using version string. Please
take a look at the ppas.py for the example.
During checking the back-end support for the node, we will also check
the server type (variant) along with the version within the range of
maximum and minimum version for the node. And, the same support added
for the schema attributes in front-end (JavaScript).
Really thankful to Khushboo Vashi for her initial work in front-end. I
took it further from there.
driver)
1. Update correct variable for database information in the connection
manager.
2. Raise exception, when database not found, instead of return the
(boolean, error message) tupple.
manager, once the connection to the maintenance database has been made,
because - we will have did (i.e. Database OID) most of the time for the
any node, and not its name as identifier.
This will allow us to work directly with OID, and we will not need to
bother about renaming of the database name.
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
Still needs some work to:
- Minimise AJAX calls by writing multiple settings at once.
- Move the settings storage/retrieval JS code into a global file
- Avoid using synchronous AJAX calls in the main thread
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.
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....
