Re: [pgadmin4][patch] Initial patch to decouple from ACI Tree - Mailing list pgadmin-hackers
| From | Ashesh Vashi |
|---|---|
| Subject | Re: [pgadmin4][patch] Initial patch to decouple from ACI Tree |
| Date | |
| Msg-id | CAG7mmowGmtwfR+yBJ6d05N0pS+vEwTWC_ZoQ_RxZPf99T+sp8g@mail.gmail.com Whole thread Raw |
| In response to | Re: [pgadmin4][patch] Initial patch to decouple from ACI Tree (Joao De Almeida Pereira <jdealmeidapereira@pivotal.io>) |
| Responses |
Re: [pgadmin4][patch] Initial patch to decouple from ACI Tree
(Ashesh Vashi <ashesh.vashi@enterprisedb.com>)
|
| List | pgadmin-hackers |
...
3. Start the discussion on application architecture
Why should we care about location of files inside a our application?
Why is this way better the another?
These are 2 good questions that have very lengthy answers. Trying to more or less summarize the answers we care about
the location of the files, because we want our application to communicate intent and there are always pros and cons
on all the decisions that we make.
At this point the application structure follows our menu, this approach eventually make is easier to follow the code
but at the same time if the menu changes down the line, will we change the structure of our folders?
The proposal that we do with the last diff of this patch is to change to a structure that slices vertically the
application. This way we can understand intent behind the code and more easily find what we are looking for.
In the current structure if you want to see the tables code you need to go to
pgAdmin/browser/server_groups/this is a huge path to remember and to get to. Whatservers/databases/schemas/tabl es/
do we win with this?
If we open pgAdmin we know which nodes to click in order to get to tables. But for development
every time that you are looking for a specific functionality you need to run the application, navigate the menu so that
you know where you can find the code. This doesn’t sound very appealing.
What if our structure would look like this:
- web - tables - controller - get_nodes.py - get_sql.py - __init__.py - frontend - component - ddl_component.js - services - table-service.js - schemas - servers - ....
This would saves us time because all the information that we need is what are we working on and everything is right there.
Menu driven structure Intent Driven Structure Pros: Pros: Already in place Explicitly shows features Self contained features Self contained features Support for drop in features Support for drop in features Cons: Cons: Follows the menu, and it could change Need to change current code Hard to find features Some additional plumbing might be needed Drop in features need to be placed in a specific location according to the menu location What are your thought about this architecture?
NOTE:pgadmin/ - database_objects/ - server/ - __init__.py - create.py - get.py - sql.py - update.py - static/ - img/ - server.svg - server_bad.svg - javascripts/ - server.js - ui_schema.js - database/ - templates ... ... + schema/ ... - tests/ - api/ ... - gui/ ... - karma/ ... - browser/ + pgagents/ - server_groups/ - servers/ - databases/ - __init__.py - node.py - schemas ... ... ... ... + tests/ - tools/ + sqleditor/ + dataviewer/ + debugger/ - misc/ + sql/ + statistics/ ...
Around minute 7 of this video Uncle Bob shows an application written
in rails to talk about architecture. It is a long KeyNote if you are curious I would advise you to see the full video.
His approach to architecture of the application is pretty interesting.
pgadmin-hackers by date: