Provide links to related models from edit views (CO-2229) #20
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some thoughts
* @license Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0) | ||
*/ | ||
|
||
if($this->request->getParam('action') == 'edit') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arlen Would it help if the configuration was part of the Controller or part of a helper?
app/templates/Rules/fieldsConfig.inc
Outdated
* @license Apache License, Version 2.0 (http://www.apache.org/licenses/LICENSE-2.0) | ||
*/ | ||
|
||
if($this->request->getParam('action') == 'edit') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@arlen Would it help if the configuration was part of the Controller or a Helper?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the current codebase, we generally set topLinks
via buttons.inc
, meaning the configuration is in the view (template) directory close to the rest of the configuration, so I think defining template specific links in the templates directory makes sense. I'm not a big fan of fieldsConfig.inc
as the name, since I don't know how to distinguish it from fields.inc
. We could stick with buttons.inc
, unless we want to merge in the search.inc
files at some point.
The other option would be to switch fields.inc
to an entirely configuration driven file, like columns.inc
. So, for example, we'd rewrite something like
if($action == 'add' || $action == 'edit') {
print $this->Field->control('name');
print $this->Field->control('description', [], false);
}
to something like
$controls = [
'name' => [
'actions' => ['add', 'edit'],
'required' => false
]
];
and then $topLinks
could be defined in the same file. I'm not sure how this will work for javascript logic that we have to eventually insert (render field X when field Y is true), but maybe we want that to be configuration driven also so we don't have to copy and paste javascript all over the place.
BTW $this->request->getParam('action')
could be simplified down to $action
, which is set in add-edit-view.php
.
Also, maybe we should rename $topLinks
to something less dependent on the position.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of having the fields.inc file be entirely configuration driven. This would keep the number of files simple and clean, and (as you state) we just put the links configuration in fields.inc. This will make the approach consistent for both the edit and index views. Instead of "topLinks" we might do "primaryLinks" or "mainLinks" ...or, given the nature of the add-edit view, just "links" (since we have no other collection of its kind - and even if we did it could probably be extended from "links" rather than creating something new).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking about a naming convention for this file, and perhaps simply nav.inc makes sense: it could be used for any navigation that's associated with the current view - whether subnavigation (i.e. tabs) or secondary links (topLinks). I think in the case of $topLinks, we can just call these $links. I've considered $primaryNav and $secondaryNav, but I'm not sure those names are explicit enough ... So I'm leaning towards $subnavigation and $links -- names which identify the relationship of the items but not the position or choice of widget.
This has been converted to a draft - the better UI/UX solution for the models we're discussing here is to use subnavigation tabs because the models are integral to each other - and should be presented as a "unit". |
This has been rebased against the latest develop and completely refactored. We now make use of a nav.inc file to incorporate general links (topLinks) and subnavigation. The behavior for the UX is better. There are two ways this could be improved, though neither are blockers:
|
* @param string $modelName Model name for form | ||
* @param string $action Current action | ||
* @param string $editable True if controls are read/write, false for read only | ||
* @param string $cssClasses CSS classes to add to the form list | ||
* @return string | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only the last parameter is an addition - the other lines here have one space of added white space to line up the descriptions but are otherwise unchanged.
'mapping' => 'nicknames.en' | ||
], | ||
'class' => 'buildbutton' | ||
] | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"topLinks" are now included in the nav.inc file as "links".
], | ||
'actions' => ['index','edit','add'] | ||
]; | ||
?> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's likely that we'll need to nest the actual links in the "links" array down a level much like the $subnavigation array so we can provide the same kind of meta information, e.g. what actions allow the rendering of the links (which is what "actions" is for in $subnavigation). This isn't needed now, but may be in time.
</script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only change here is to drop the <script> tag to the bottom of the fields.inc file. Having this at the top can cause problems with CSS due to it's placement in the DOM. (Probably something to discuss at a dev meeting.)
</div> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The #topLinks block is moved into its own element.
$target | ||
); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving this section up fixes breadcrumb layout issues for the config views.
$controller == 'AttributeMappings' || | ||
$controller == 'Rules' || | ||
$controller == 'RuleAttributes' || | ||
$controller == 'SystemsOfRecord')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this condition could become more readable if written like this:
$controllers = [
'MatchgridSettings',
'Attributes',
'ApiUsers',
'AttributeGroups',
'AttributeMaps',
'AttributeMappings',
'Rules',
'RuleAttributes',
'SystemsOfRecord'
];
if (!empty($vv_cur_mg) && in_array($controller, $controllers, true) {
... // Do stuff
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call - I'll update in this way (probably using $configControllers as name for clarity)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is made
This has been rebased against the latest develop. |
c7a60ef
to
2d3978e
Compare
This has been rebased against the latest develop. |
This PR has been converted to draft while we work on the edit views of related models within subnavigation. |
2d3978e
to
bf45ac5
Compare
This PR is ready for review. While this pass does not address title (and subtitle) handling, this is a big improvement in getting related models to feel like part of a cohesive whole. This PR establishes subnavigation for related models, and can be seen when visiting Rule Attributes and Attribute Mappings. |
a30dd76
to
8379629
Compare
8379629
to
89342e8
Compare
… subnavigation and toplinks into nav.inc. (CO-2229) Also includes correction to config page breadcrumbs
This solution to CO-2229 is similar to but has been superseded by the approach to subnav tabs in Registry PE (in which a global subnavigation file holds the tabs for related models together in one place). We will rework this solution to be like PE. |
No description provided.