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

[MERGE] website, *: make website JS available in all 'frontend' pages #29442

Closed
wants to merge 10 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@qsm-odoo
Copy link
Contributor

qsm-odoo commented Dec 11, 2018

  • web, im_livechat, survey, web_editor, website_forum, account,
    auth_signup, payment, portal, project, sale, sale_management,
    web_unsplash, website_mail, website_rating, website_sale,
    website_blog, website_crm_partner_assign, website_event_track,
    website_links, website_slides, website_mail_channel,
    website_mass_mailing, website_sale_comparison, website_sale_delivery,
    website_sale_wishlist, website_event, website_form,
    website_sale_stock, website_twitter

When website is installed, the JavaScript code has access to utilities
to define improved widgets which are automatically attached to existing
DOM elements on page load. Those mechanics are more and more needed in
portal which does not depend on website (as it is website which depends
on portal). This moves part of website JS to web, so that it can be used by all
'frontend' apps whose only common dependency is web (portal, survey, ...).

See sub-commits for details.

task-1932066

@qsm-odoo qsm-odoo self-assigned this Dec 11, 2018

@robodoo robodoo added the seen 🙂 label Dec 11, 2018

@qsm-odoo qsm-odoo force-pushed the odoo-dev:master-portal-root-qsm branch 2 times, most recently Dec 14, 2018

@qsm-odoo qsm-odoo force-pushed the odoo-dev:master-portal-root-qsm branch Jan 10, 2019

qsm-odoo added a commit to odoo-dev/odoo that referenced this pull request Jan 22, 2019

[FIX] *: review 'frontend' pages init (web_editor.base)
* auth_password_policy_signup, auth_signup, website, portal, survey,
  web_unsplash, website

Following the new editor's merge at odoo#29775
web_editor.base has been moved to website while it was still used by
frontend pages which do not depend on website (especially portal).

This commit moves web_editor.base to portal while waiting for
odoo#29442. It also removes the unnecessary
dependencies to it in non-portal pages (in survey for example).

robodoo pushed a commit that referenced this pull request Jan 22, 2019

[FIX] *: review 'frontend' pages init (web_editor.base)
* auth_password_policy_signup, auth_signup, website, portal, survey,
  web_unsplash, website

Following the new editor's merge at #29775
web_editor.base has been moved to website while it was still used by
frontend pages which do not depend on website (especially portal).

This commit moves web_editor.base to portal while waiting for
#29442. It also removes the unnecessary
dependencies to it in non-portal pages (in survey for example).

robodoo pushed a commit that referenced this pull request Jan 23, 2019

[FIX] website, *: restore 'animation' system to the way it worked
* website_forum

Following the new editor's merge at #29775,
the website 'animation' system was 'extended' to vaguely use a
'Registry' instance instead of an object. This was however left
undocumented, with a require in the middle of a file, restarting all
animations when used, only used by website_forum... with more code for
no reason at all, ...

This commit restores the system to the way it was before and re-adapts
website_forum:
- No need to check if website_forum is in the DOM as it is already
  checked by the animation system (on top of that... the new code was
  checking the DOM before it was ready...).
- No need of a dynamic add on a registry, this is always done before the
  DOM is ready, so before the animations are started.
- No need to know the root instance in website forum, just use the
  animation as the Wysiwyg instance's parent.

The goal of this commit is also to avoid useless conflicts with
#29442 (that should not have had any
conflict at all as totally independent of the editor task...)

closes #30478

qsm-odoo added a commit to odoo-dev/odoo that referenced this pull request Jan 24, 2019

[FIX] website, *: restore 'animation' system to the way it worked
* website_forum

Following the new editor's merge at odoo#29775,
the website 'animation' system was 'extended' to vaguely use a
'Registry' instance instead of an object. This was however left
undocumented, with a require in the middle of a file, restarting all
animations when used, only used by website_forum... with more code for
no reason at all, ...

This commit restores the system to the way it was before and re-adapts
website_forum:
- No need to check if website_forum is in the DOM as it is already
  checked by the animation system (on top of that... the new code was
  checking the DOM before it was ready...).
- No need of a dynamic add on a registry, this is always done before the
  DOM is ready, so before the animations are started.
- No need to know the root instance in website forum, just use the
  animation as the Wysiwyg instance's parent.

The goal of this commit is also to avoid useless conflicts with
odoo#29442 (that should not have had any
conflict at all as totally independent of the editor task...)

qsm-odoo added a commit to odoo-dev/odoo that referenced this pull request Jan 24, 2019

[FIX] portal: remove useless dependency to 'web_editor.ready'
Following the new editor's merge at odoo#29775,
the 'web_editor.ready' module was moved to website without caring about
where it was used.

Fortunately the only non-website app which uses it is portal in a module
which in fact does not need it.
It would probably make more sense if it was in portal though (see
odoo#30409) but as an upcoming PR is about
to fix those problems (odoo#29442), this
can stay in website for now.

robodoo pushed a commit that referenced this pull request Jan 24, 2019

[FIX] portal: remove useless dependency to 'web_editor.ready'
Following the new editor's merge at #29775,
the 'web_editor.ready' module was moved to website without caring about
where it was used.

Fortunately the only non-website app which uses it is portal in a module
which in fact does not need it.
It would probably make more sense if it was in portal though (see
#30409) but as an upcoming PR is about
to fix those problems (#29442), this
can stay in website for now.

closes #30473

robodoo pushed a commit that referenced this pull request Jan 24, 2019

[FIX] website, *: restore 'animation' system to the way it worked
* website_forum

Following the new editor's merge at #29775,
the website 'animation' system was 'extended' to vaguely use a
'Registry' instance instead of an object. This was however left
undocumented, with a require in the middle of a file, restarting all
animations when used, only used by website_forum... with more code for
no reason at all, ...

This commit restores the system to the way it was before and re-adapts
website_forum:
- No need to check if website_forum is in the DOM as it is already
  checked by the animation system (on top of that... the new code was
  checking the DOM before it was ready...).
- No need of a dynamic add on a registry, this is always done before the
  DOM is ready, so before the animations are started.
- No need to know the root instance in website forum, just use the
  animation as the Wysiwyg instance's parent.

The goal of this commit is also to avoid useless conflicts with
#29442 (that should not have had any
conflict at all as totally independent of the editor task...)

closes #30478

@qsm-odoo qsm-odoo force-pushed the odoo-dev:master-portal-root-qsm branch 2 times, most recently Jan 24, 2019

qsm-odoo added a commit to odoo-dev/odoo that referenced this pull request Jan 25, 2019

[REF] website, *: remove 'web_editor.ready'
* website_event

Following the new editor's merge at odoo#29775,
'web_editor.ready' was moved to website without being renamed.

Following odoo#30409, this will remove
that 'web_editor.ready' module.

See upcoming improvements with odoo#29442

@qsm-odoo qsm-odoo force-pushed the odoo-dev:master-portal-root-qsm branch 2 times, most recently Jan 25, 2019

@qsm-odoo

This comment has been minimized.

Copy link
Contributor Author

qsm-odoo commented Jan 25, 2019

Hello @ged-odoo

In this PR (especially with current 729e8ab7939154d5b292d4fc6b41d765675d10cd), I will split the top widget of website (website root) and the 'animations' = frontend widgets so that the relevant parts (mostly everything) are in portal instead of website. This will allow to have better instantiation code for portal and stuff.

But in fact, after some thinking, I was wondering if all of this should be done in web/ instead, in a new folder like 'public' / 'frontend' / 'whatever'. Apps like survey, auth_signup, ... do not depend on portal but are typically doing the same things as the portal/website.

What do you think ? Ideally, I would like to merge this before the freeze :)

robodoo pushed a commit that referenced this pull request Jan 25, 2019

[REF] website, *: remove 'web_editor.ready'
* website_event

Following the new editor's merge at #29775,
'web_editor.ready' was moved to website without being renamed.

Following #30409, this will remove
that 'web_editor.ready' module.

See upcoming improvements with #29442

closes #30548
@qsm-odoo

This comment has been minimized.

Copy link
Contributor Author

qsm-odoo commented Feb 26, 2019

@robodoo retry

@robodoo robodoo added CI 🤖 r+ 👌 and removed error 🙅 labels Feb 26, 2019

[REF] *: definitely get rid of web_editor.base
* portal, sale, website, website_blog, website_crm, website_event,
  website_event_sale, website_forum, website_hr_recruitment,
  website_sale, website_sale_wishlist

At last, that ugly JS module can be removed. Before this current PR, it
was still used to wait for "page ready", to initialize widgets on page
loading. Now, all can be done thanks to public root and public widgets.

web_editor.base was also still used in tours, which should not be
necessary anymore for the same reason, especially since the tour manager
waits for the public root naturally.

Part of #29442
task-1932066

@qsm-odoo qsm-odoo force-pushed the odoo-dev:master-portal-root-qsm branch to c3a8d96 Feb 27, 2019

@qsm-odoo

This comment has been minimized.

Copy link
Contributor Author

qsm-odoo commented Feb 27, 2019

robodoo pushed a commit that referenced this pull request Feb 27, 2019

[MOV] web, *: simple moves of JS files to 'public' folder
* web_editor, website, survey, im_livechat

Part of #29442
task-1932066

robodoo pushed a commit that referenced this pull request Feb 27, 2019

[REF] website: split WebsiteRoot definition / instantiation
In preparation to future commits, the WebsiteRoot instantiation is moved
in an other file than its definition.

Part of #29442
task-1932066

robodoo pushed a commit that referenced this pull request Feb 27, 2019

[REF] website, web, *: move part of website into web
* im_livechat, survey, website_forum

When website is installed, the JavaScript code has access to utilities
to define improved widgets which are automatically attached to existing
DOM elements on page load. Those mechanics are more and more needed in
portal which does not depend on website (as it is website which depends
on portal). This commit moves part of website JS to web, so that it can
be used by all 'frontend' apps whose only common dependency is web
(portal, survey, auth_signup, ...).

This PR also questioned several other similar issues which will be
handled later like:

- website should maybe not depends on portal but only on http_routing

- part of portal should be moved to http_routing and http_routing
  should be renamed (especially for frontend layouts, etc) so that apps
  like survey can reuse some common code

Part of #29442
task-1932066

robodoo pushed a commit that referenced this pull request Feb 27, 2019

robodoo pushed a commit that referenced this pull request Feb 27, 2019

[REF] website: make the lazy renderer a public widget
Not sure this one is still useful but best to integrate it as a
public widget.

Part of #29442
task-1932066

robodoo pushed a commit that referenced this pull request Feb 27, 2019

[REF] *: use 'frontend' system in non-website apps
* account, auth_signup, payment, portal, project, sale, sale_management,
  web_unsplash, website, website_mail, website_rating, website_sale

This commit does probably not do what is stated for all non-website apps
but it is a first step. It also uses the system in apps which could have
already used it but did not.

Part of #29442
task-1932066

robodoo pushed a commit that referenced this pull request Feb 27, 2019

[REF] website, *: move and review the notion of edit mode
* portal, sale, web, website_blog, website_crm_partner_assign,
  website_forum, website_event_track, website_links, website_mail,
  website_slides, website_mail_channel, website_mass_mailing,
  website_sale, website_sale_comparison, website_sale_delivery,
  website_sale_wishlist

The `editableMode` option and its related options in public widget
should only be part of website, this commit moves them there. This is
also the occasion to implement something that is long overdue: stop
creating 'animations' / public widgets in edit mode by default. Indeed,
lots of 'animations' were defined by beginning with 'if not edit mode'.
Now, if a public widget should be considered in edit mode, it must be
defined explicitely through a property at *definition* of the widget.

Part of #29442
task-1932066

robodoo pushed a commit that referenced this pull request Feb 27, 2019

[REF] website, *: use public widgets instead of website animations
* website_blog, website_crm_partner_assign, website_event,
  website_event_track, website_form, website_forum, website_links,
  website_mail, website_mail_channel, website_mass_mailing,
  website_sale, website_sale_comparison, website_sale_delivery,
  website_sale_stock, website_sale_wishlist, website_slides,
  website_twitter

While using the 'Animation' class of website instead of the frontend
'Widget' class leads to the same behaviors, this refactoring is done for
two reasons:
- Stop using the confusing 'Animation' name for non-animated behaviors
- Instantiation of 'Widget' is slightly faster than 'Animation'

Part of #29442
task-1932066

robodoo pushed a commit that referenced this pull request Feb 27, 2019

[REF] website, *: stop using 'animation' confusing name
* web, website_blog, website_sale, website_twitter

Before this PR, all website widgets were named 'Animation'. Now that
they are 'Public Widgets', we can at last stop using the confusing
'animation' name.

Part of #29442
task-1932066

robodoo pushed a commit that referenced this pull request Feb 27, 2019

[REF] *: definitely get rid of web_editor.base
* portal, sale, website, website_blog, website_crm, website_event,
  website_event_sale, website_forum, website_hr_recruitment,
  website_sale, website_sale_wishlist

At last, that ugly JS module can be removed. Before this current PR, it
was still used to wait for "page ready", to initialize widgets on page
loading. Now, all can be done thanks to public root and public widgets.

web_editor.base was also still used in tours, which should not be
necessary anymore for the same reason, especially since the tour manager
waits for the public root naturally.

Part of #29442
task-1932066

robodoo added a commit that referenced this pull request Feb 27, 2019

[MERGE] website, *: make website JS available in all 'frontend' pages
* web, im_livechat, survey, web_editor, website_forum, account,
  auth_signup, payment, portal, project, sale, sale_management,
  web_unsplash, website_mail, website_rating, website_sale,
  website_blog, website_crm_partner_assign, website_event_track,
  website_links, website_slides, website_mail_channel,
  website_mass_mailing, website_sale_comparison, website_sale_delivery,
  website_sale_wishlist, website_event, website_form,
  website_sale_stock, website_twitter

When website is installed, the JavaScript code has access to utilities
to define improved widgets which are automatically attached to existing
DOM elements on page load. Those mechanics are more and more needed in
portal which does not depend on website (as it is website which depends
on portal). This moves part of website JS to web, so that it can be used by all
'frontend' apps whose only common dependency is web (portal, survey, ...).

See sub-commits for details.

task-1932066

closes #29442

@robodoo robodoo added merged 🎉 and removed merging 👷 labels Feb 27, 2019

@robodoo

This comment has been minimized.

Copy link
Contributor

robodoo commented Feb 27, 2019

Merged, thanks!

@robodoo robodoo closed this Feb 27, 2019

@qsm-odoo qsm-odoo deleted the odoo-dev:master-portal-root-qsm branch Feb 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.