search

moqui / moqui-runtime

The default runtime directory for Moqui Framework
Other
37 stars 78 forks source link

screen-theme-type-enum-id not work in vuejs mode #82

Closed chunlinyao closed 6 years ago

chunlinyao commented 7 years ago

In html mode, subscreens can use different theme, in vuejs mode it still use default STT_INTERNAL.

jonesde commented 7 years ago

Not sure what we'd do about that... because the vuejs mode uses a single page application (SPA) sort of shell all the resources for the theme are loaded there. This is a rarely used feature from my experience, what are you using it for or what are you using it to make happen?

chunlinyao commented 7 years ago

Make different module use different theme, e.g. use a different header footer background color and logo for accounting module and change STRT_HEADER_NAVBAR_ITEM for modules.

jonesde commented 7 years ago

The vuet/vuejs mode used under /vapps will never be the same as full server-side rendering, it just doesn't work that way and in order to be more responsive and provide a smoother user experience it can't work that way. There are various framework features and conventions that have been used in the past that won't work in vuet mode. I don't plan to deprecate or remove these sorts of features because not everyone will be using the vuet mode, some will prefer to continue using full server-side rendering (while others will use the hybrid like /vapps, and yet others will use full client-side rendering where most of the Moqui XML Screen functionality just isn't used).

In order to keep a shell that is always there after the initial page load, making it a sort of single-page application, that HTML and the root Vue component only loads once and all changes to the header must happen through JavaScript after the initial load.

Taking the logo image as an example the image URL could be made dynamic in the WebrootVue.vuet.ftl file with a variable added to the moqui.webrootVue component in the WebrootVue.js file (near the bottom). Then some JavaScript would need to set the logo image URL field on the moqui.webrootVue object in response to something. That could come down from the server with the menu data data which is requested from the server for each navigation to a different screen. The menu data is generated (by default anyway) in the ScreenRenderImpl.getMenuData() method through the menuData transition in the webroot.xml screen. Either the getMenuData() method or the menuData transition script would need to be modified to lookup the logo image URL to use and pass it down as part of the JSON object that gets returned, then the JavaScript that handles the menu data would need to be changed to be aware of it and set the logo image URL field on the moqui.webrootVue component.

It's not that the client-side rendering approach is more constrained, but it is more complicated because everything has to be built to work together between the client and server sides of it. Anything can be done, but overall it isn't as easy as full server-side rendering.

The vuet mode offers a heck of a lot more flexibility and is already a much better user experience (with the potential to get even better over time) but it comes at a development cost. That has always been, and always will be, the case with client/web rendering technology.

Don't expect things to work the same as server-side HTML rendering, in fact the vuet templates that are sent to the browser aren't even really HTML, they are Vue Templates. Fortunately Vue templates are very similar to HTML, with the option of using elements that are Vue components instead of HTML tags. That is one of the reasons we are using Vue and why other client rendering frameworks simply would not work for the hybrid client/server rendering that the vuet/vapps stuff is doing as they either don't have templates or the templates require server-side transpiling into JavaScript (or MASSIVE JavaScript libraries loaded into the browser for client-side transpiling).

jonesde commented 6 years ago

Closing as part of general cleanup for the move to HiveMind and for no recent activity on this issue. If this comes up again or anyone wants to pursue it feel free to create a request on moqui.org. For more information see:

https://www.moqui.org/m/docs/moqui/Community+Guide