'static' directory from 'templates' in the respective module directory:
- Server Group
- Server
- Database
- Schema
- Cast
- Event trigger
- Extension
- Foreign data wrapper
- Language
- Catalog Object
- Collation
- Domain Constraint
- Domain
- Foreign server
- FTS Configuration
- FTS Dictionary
- FTS Parser
- FTS Template
- Function
- Procedure
- Trigger Function
- Package
- Sequence
- Catalog
- Schema
- Synonym
- Table
- Type
- Materialized View
- View
- pgAgent Modules
+ Job (pga_job)
+ Schedule (pga_schedule)
+ Steps (pga_jobstep)
Added new dynanic modules for listing the supported server types, and
current user information.
NOTE: We've not yet moved the javascripts for the children of the table
module.
Created a url_for function module to be used by different javascript
modules to use the same functionality of flask at client side.
A python module can expose the list of endpoints, used by its
javascripts, by overriding the 'get_exposed_url_endpoints(self)'
function.
In this patch, we have modified all the browser modules to use this
function. It will allow us to move the majority of the javascript
modules of browser nodes from templates directory to the static
directory.
TODO::
- Move these javascripts modules to the static directory.
- Use this function in all the applicable javascript modules.
e.g. tools, miscellaneous modules
tree nodes.
Each individual node is responsible for introducing the 'canDrop'
function/flag to decide whether the 'Delete/Drop' context menu should be
enabled/disabled.
In commit-id: 26aa5607ad, 'obj.canDrop'
was set to true in the 'pgBrowser.Node' in delete callback, just to make
the server-group droppable, which is wrong, as all the nodes are
getting affected because of this change in a wrong way.
To fix the issue, added the 'canDrop' function in the server-group node.
Apart from them, also added restriction for not allowing to delete the
default server-group.
Also, handled the same restriction at the server end.
creation, and editing within the properties panel infrastructure.
We do use the backgrid.js for listing the subnode collection, and for
editing/creating new object for the subnode, we do use the same
infrastructure using the backform.
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).
PostgreSQL node(s).
Browser Tree Node (PostgreSQL object) requires more than just CRUD.
i.e.
- CRUD (Create, Read, Update & Delete)
- Reversed Engineered SQL for the object
- Modified Query in edit mode
i.e. ALTER TABLE ...
- Statistics
- List of dependents
- List of dependencies
- Children node list
This class can be inherited to achieve the different routes for each of
the object types/collections.
OPERATION | URL | Method
---------------+------------------------+--------
List | /obj/[Parent URL]/ | GET
Properties | /obj/[Parent URL]/id | GET
Create | /obj/[Parent URL]/ | POST
Delete | /obj/[Parent URL]/id | DELETE
Update | /obj/[Parent URL]/id | PUT
SQL (Reversed | /sql/[Parent URL]/id | GET
Engineering) |
SQL (Modified | /sql/[Parent URL]/id | POST
Properties) |
Statistics | /stats/[Parent URL]/id | GET
Dependencies | /deps/[Parent URL]/id | GET
Dependents | /deps/[Parent URL]/id | POST
Children Nodes | /nodes/[Parent URL]/id | GET
NOTE:
Parent URL can be seen as the path to identify the particular node.
i.e.
In order to identify the TABLE object, we requires information
about the server -> database -> schema objects.
Hence, the Parent URL for the TABLE object will be something like
this as below:
<int:sid>/<str:database>/<str:schema>
Inherited a new classes ServerGroupView and ServerView, which are
inherited from the NodeView for the implementation of above operations.
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
The File menu now includes a "Create" submenu, and Delete/Rename
options. Nodes can offer Delete/Rename functionality, and the
options on the menu are automatically enabled/disabled based on
the selected node. Each node can also offer Create functionality,
and specify a list of node types (including itself) from which the
option should be made available. The menu is dynamically generated
based on the selected node.
The Context menu on the treeview works in a similar way, except that
nodes can offer any context menu items (we don't allow this on the
top menu, as that should stay consistent to avoid user confusion).