- Loading 'pgadmin' as 'sources/pgadmin', as found under the 'sources'
reference directory to be consistent with other files.
- Removed the 'pgadmin' reference from the base.html template.
- Renamed 'pgadmin.slickgrid.editors.js', and
'pgadmin.slickgrid.formatters.js' as 'editors.js', and 'formatters.js'
respectively, as they're already in the 'pgadmin/static/js/slickgrid'
directory.
- Removed the duplicate entry of 'translations' from the webpack.shim.js
This significantly speeds up loading of the application; in an average of 3 tests, v1.6
loaded in 11.5s in the runtime on a Mac, whilst the webpacked version of the code
loaded in 5.53s.
'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.
- Added DatetimepickerControl, MomentCell (using moment.js)
- Used the 'DatetimepickerControl' in Role (Also - resolved an issue, when unset the datetime for 'Valid Until'.)
- Added a 'Select All/Unselect All' adaptor for Select2 used by pgAgent nodes.
- Fixed an issue with SubNodeCollectionControl, which was not starting the modification session of the child model, when created default value for collection is not null/undefined. And, hence - validation on the child model was not working.
- Fixed a memory leak with SqlFieldControl, and SqlTabControl, which was not releasing the CodeMirror properly.
boolean values. (Modified quite a lot by Ashesh, before committing).
This patch also allow to set the header class in the backgrid through
setting 'cellHeaderClass' property of the schema object for any of the
node. It will allow us to set the different behaviour of the cell in the
list. One of the test case for it is: this will allow us to set the
different width of each column in the list using CSS class(es).
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.