New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring of the rendering of views' buttons #23115
Conversation
.text(node.attrs.string) | ||
.appendTo($button); | ||
} | ||
var $button = this._renderButtonFromNode(node); // FIXME force oe_stat_button ? |
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 previous code forced the 'oe_stat_button' class, the new code supposes it is explicitly set in the view... is this a problem ?
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.
maybe... this should probably not even appear in views' arch, and should be automatically added by the webclient
@ged-odoo I let you assign as reviewer whoever is motivated 😄 |
@qsm-odoo does this mean that |
@pedrobaeza No, as said in my commit, the JS rendering part will auto-convert I changed the XML for consistency but it is not necessary. We may also want to do the opposite (using |
Thanks for the explanation. That's better for keeping compatibility, but I will start to change the class in v12 modules with the same consistency spirit 😃 |
88d5464
to
1722230
Compare
@ged-odoo I split the commit in 3 parts, the last one should be discussed and is not vital. I will also do the same for the |
1722230
to
3a813dc
Compare
@aab-odoo the opportunity to assign someone falls on you :) |
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.
Seems good
} else { | ||
$button.text(node.attrs.string); | ||
var $i = $button.children().detach(); | ||
$button.empty().append($i); |
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.
why?
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.
To do the equivalent as before (icon OR text for list buttons, the icon buttons in lists have no button appearance thanks to the o_icon_button
class).
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 don't like that :D
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.
Meh, I will parametrize the _renderButtonFromNode
function then
params.class = 'btn btn-' + (options.size || 'sm') + ' ' + (params.class || 'btn-default'); | ||
var classes = 'btn-default'; | ||
if (params.class) { | ||
classes = params.class.replace(/\boe_highlight\b/g, 'btn-primary') |
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.
add comment specifying that this is backward compatibility?
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.
Not sure. Depends if we want to get rid of oe_hightlight
in views / use only this class / use a new class / keep using it or btn-primary
(as we discussed regarding the last commit of this PR)
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'd be happy if people stop using it... one concept one keyword/classname
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.
Yes, but what keyword? :) btn-primary
depends on bootstrap. oe_hightlight
... is a crappy name :)
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.
whatever as soon as there is only one
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.
@aab-odoo I changed the PR following your comments, except for this one. Should I merge the PR without the last commit and leave it for some more framework-team-thinking ?
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.
What does @JKE-be think about it? For me it's ok...
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.
.text(node.attrs.string) | ||
.appendTo($button); | ||
} | ||
var $button = this._renderButtonFromNode(node); // FIXME force oe_stat_button ? |
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.
maybe... this should probably not even appear in views' arch, and should be automatically added by the webclient
ee8833f
to
5113952
Compare
Button rendering was most of the time wrong, incomplete or performed with duplicated code. This led to: - Both primary and default classes were put on some statusbar buttons - Icons were not able to be put for statusbar buttons - Stat buttons and list buttons code were duplicated - Classes and style were added twice - ...
* account, test_main_flows The style of a primary/link button is given by the 'btn-primary'/'btn-link' class. The old 'oe_highlight'/'oe_link' class should still be supported in views but not rendered in the DOM.
The 'oe_link' class is not linked to any style since .... The class is automatically converted to 'btn-link' for <button/> elements but this will not be done on <a/> elements as they are (nearly) unprocessed node during views rendering. Also there is minor difference between a '.btn-link' element and a <a/> element anyway (and maybe there should not be at all).
This is done for pure consistency, the 'oe_highlight' class is still supported. NOTE: we may want to do the opposite or introduce a new class like 'o_primary'.
5113952
to
a76dc98
Compare
Code refactoring and removal of
oe_highlight
.See enterprise branch: https://github.com/odoo/enterprise/pull/1878