Skip to content
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

Closed
wants to merge 4 commits into from

Conversation

qsm-odoo
Copy link
Contributor

@qsm-odoo qsm-odoo commented Feb 16, 2018

Code refactoring and removal of oe_highlight.
See enterprise branch: https://github.com/odoo/enterprise/pull/1878

@qsm-odoo qsm-odoo added RD research & development, internal work Framework General frontend/backend framework issues labels Feb 16, 2018
@qsm-odoo qsm-odoo self-assigned this Feb 16, 2018
.text(node.attrs.string)
.appendTo($button);
}
var $button = this._renderButtonFromNode(node); // FIXME force oe_stat_button ?
Copy link
Contributor Author

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 ?

Copy link
Contributor

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

@qsm-odoo
Copy link
Contributor Author

@ged-odoo I let you assign as reviewer whoever is motivated 😄

@pedrobaeza
Copy link
Collaborator

@qsm-odoo does this mean that oe_highlight in community modules is not going to work anymore for v12 and should be replaced by btn-primary?

@qsm-odoo
Copy link
Contributor Author

@pedrobaeza No, as said in my commit, the JS rendering part will auto-convert oe_highlight to btn-primary. So no API change here.

I changed the XML for consistency but it is not necessary. We may also want to do the opposite (using oe_highlight everywhere). Both approaches make sense.

@pedrobaeza
Copy link
Collaborator

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 😃

@qsm-odoo
Copy link
Contributor Author

@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 oe_link class, so you might want to wait before reviewing.

@qsm-odoo
Copy link
Contributor Author

@aab-odoo the opportunity to assign someone falls on you :)

Copy link
Contributor

@aab-odoo aab-odoo left a 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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Copy link
Contributor Author

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).

Copy link
Contributor

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

Copy link
Contributor Author

@qsm-odoo qsm-odoo Feb 19, 2018

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')
Copy link
Contributor

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?

Copy link
Contributor Author

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)

Copy link
Contributor

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

Copy link
Contributor Author

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 :)

Copy link
Contributor

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

Copy link
Contributor Author

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 ?

Copy link
Contributor

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...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JKE-be What do you think about commit: 5113952 ? The JS code would still replace them automatically with btn-primary but we might want to use only one class in views for consistency (same goes for oe_link/btn-link). Is it worth breaking clients' xpaths ?

.text(node.attrs.string)
.appendTo($button);
}
var $button = this._renderButtonFromNode(node); // FIXME force oe_stat_button ?
Copy link
Contributor

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

@qsm-odoo qsm-odoo force-pushed the master-highlight-qsm branch 4 times, most recently from ee8833f to 5113952 Compare February 26, 2018 13:41
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'.
@qsm-odoo
Copy link
Contributor Author

This was merged with the less2scss convertion except for this commit: a76dc98

@ged-odoo @aab-odoo I let you decide if this must be merged and if we should also stop supporting oe_highlight / oe_link as discussed

@qsm-odoo qsm-odoo closed this Apr 18, 2018
@xmo-odoo xmo-odoo deleted the master-highlight-qsm branch November 20, 2019 09:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework General frontend/backend framework issues RD research & development, internal work
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants