Results 1 to 5 of 5

Thread: Building Ext local Packages in multi theme build (multiple build profiles)

  1. #1

    Default Building Ext local Packages in multi theme build (multiple build profiles)

    I have multiple build profiles, one for each theme, each defined in app.json as follows
    Code:
    "crisp": {
          "theme": "tsl-crisp",
          "toolkit": "classic",
          "requires": [
            "package-loader",
            "ext-locale",
            "saki-field-icon",
            "charts",
            "ux"
          ],
          "uses": [
            "dashboard"
          ],
          "sass": {
            "generated": {
              "var": "classic/sass/save.scss",
              "src": "classic/sass/save"
            }
          }
        },
    and the following mods to create separate build outputs:
    for production build:
    Code:
    "output": {
        "base": "${workspace.build.dir}/${build.environment}/${build.id}",
        "manifest": "../${build.id}.json",
        "resources": "resources",
        "js": {
            "version": "ES5"
        },
        "css": "${app.output.resources}/${app.name}-all.css",
        "microloader": {
            "path": "../microloader.js",
            "embed": false,
            "enable": true
        },
        "page": {
            "path": "../index.html"
        }
    }
    and for dev build:
    Code:
    "bootstrap": {
        "base": "${app.dir}",
        "manifest": "${build.id}.json",
        "microloader": "microloader.js",
        "css": "${build.id}_bootstrap.css"
    }

    I have added some packages as local, generated by Cmd. After solving several issues with includes, I get the following problem with the build:
    each build will create a separate folder (that worked just fine), but now the package output is located in repeated build id folder!
    build/production/crisp/crisp/resources/dashboard
    but it should be in

    build/production/crisp/resources/dashboardIn the build log I can see [INF] Writing concatenated output to file C:\TSL.DEV\HDC_GITLAB\WebApp\build\production\crisp\crisp\resources\dashboard\dashboard.js

    Same thing will happen for the development build

    Build/development/crisp/crisp/resources/dashboard/Can anyone give me some hints on where does this come from?
    Thanks a lot!

    Mike

  2. #2
    Sencha Premium User mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    40,449

    Default

    You can control the output via the output object. All the paths you see are relative to the output:

    Code:
        "output": {
            "base": "${workspace.build.dir}/${build.environment}/${app.name}",
            "manifest": "${build.id}.json",
            "js": {
                "path": "${build.id}/app.js",
                "version": "ES6"
            },
            "framework": {
              "enable": true,
              "path": "${build.id}/framework.js"
            },
            "resources": {
                "path": "./${build.id}/resources",
                "images": "./${build.id}/resources/images",
                "shared": "./resources",
                "toolkit": "${toolkit.name}/resources",
                "base": "."
            },
            "appCache": {
                "enable": false
            }
        },
    The ${build.id} is equal to the name of the build so if you have something like this:

    Code:
        "builds": {
          "foo": {
              "toolkit": "classic",
              "theme": "theme-classic"
          },
          "bar": {
              "toolkit": "classic",
              "theme": "theme-gray"
          }
          }
    Then foo and bar are the ${build.id} values.

    So the manifest files (the json and jsonp files) will be in the build/production/MyApp/ directory. The JavaScript files for each build id will be nested in the build id directory as a theme may or may not have overrides that others don't. We also split the resources out to the build id specific ones since the slicer will of course slice different images for each theme. I specify the framework option here which will make your app.js files much smaller since they update more frequently than the framework would so server caching can help load times with framework.js being much bigger (2.7MB for a testing build in my tests). I nest it in the build id directory only because I cannot remember if the theme overrides get tossed in with the framework or not. If they don't, then you can just have a single framework file (per toolkit) like "path": "framework-${toolkit.name}.js" but if not, then you'll have to keep them nested in the build id.
    Mitchell Simoens @LikelyMitch
    Modus Create, Senior Fullstack Engineer
    ________________
    Modus Create is based on the model of an open source team. We’re a remote, global team of experts in our field. To find out more about the work we do, head over to our website.

    Check out my GitHub:
    https://github.com/mitchellsimoens

  3. #3
    Sencha Premium Member richardvd's Avatar
    Join Date
    Jun 2011
    Location
    NL
    Posts
    255

    Default

    +1 just for uncovering the secret of enabling split builds by using the framework option in app.json! Thanks!

  4. #4

    Default

    Hi mitchellsimoens, thanks for the update!
    I have now made some rearrangements and it seems to behave better.

    Never the less I have a big headache with trying to use Packages as application modules that was part of this topic.
    I want to be able to both create Workspaces (as separate single page apps), but also I wanted to structure the code and have a control over loading "modules", lets say admin panel or dashboard.

    I have tried to move simple dashboard that we have into a Package to start with. It's a disaster so far and it got me nowhere closer to a "better design"

    I have went through
    https://docs.sencha.com/cmd/guides/c..._packages.html
    https://docs.sencha.com/cmd/guides/c..._packages.html

    as well as dynamic loading of packages
    https://www.sencha.com/blog/create-a...th-sencha-cmd/

    With sample apps
    https://github.com/adwankar/extjs-dy...package-loader



    First of all, Is it a good practice or makes any sense to have package as a module that has standard app structure like below?
    Actually example above had a "modules" like Dashboard, but it was really trivial and only used view controllers. I would like to use a full structure like so:
    Code:
    packages/local/dashboard//controller
    /view
    /model
    /store
    
    I'm not using view controllers that are in the samples, rather "classic" ones.
    If I build the package, the main controller in the package should "require" other controllers and views from within the package.
    Normal controllers (listed in Application.js in Controllers section) will get initialized automatically.
    Others that I don't want initialized, are listed only on requires array, and I can call "getController()" to init them.
    How will that work with a Package controller when the package is loaded? Well they are not initialized for sure...

    The package itself is listed as
    Code:
     "uses": [
            "dashboard"
          ],
    and then loaded with the following code when needed (a user wants to navigate to a new module)
    Code:
       Ext.Package.load(pkg).then(function () {
                     //now use the package classes, create vnew iew from package, controller should be active but its not...
                     //do I have to make an awkward call here to init the controller like:
                     HyperDoc.app.getController('MyApp.dashboard.controller.MainDashboardController');
                });
    Dependent controller will not get initialized anyway, so that still does not make any sense, I would have to call that for all of them one by one?
    Whats more, if I want to reference (or require) other controllers from the main controller, I would have to use full namespace/class names:

    Code:
        controllers: [
            'MyApp.dashboard.controller.UserWidgetController',
            'MyApp.dashboard.controller.SystemActivityController'
        ],
    Otherwise if I leave them as they were in the main application, loader will try to load them and of course fail, as it expects that I'm trying to load a controller from the main application "Controller" folder.

    Code:
    client/app/controller/UserWidgetController.js

    Yet another problem is that these are not really independent packages, but rather modules that depend on main application code as well.
    So I need to reuse some views or tools from the main app, and the includes will fail, like here
    Code:
       requires: [
            'MyApp.lib.ux.AppModulesSelector'
        ],
    @mitchellsimoens I have seen your input about it somewhere and use of this kind of comment was discussed in relation to external libraries:
    Code:
    //@define MyApp.lib.ux.AppModulesSelector
    That will make the build error go away, but does this actually work corectly?
    I have tried adding main app directory to classpath but it did not change a thing:
    Code:
        "classpath": [
          "${package.dir}/src",
          //also look for components in the main application (outside this package)??
          "${app.dir}/app"
        ],
    So I feel like I'm doing something "backwards" here

  5. #5

    Default

    I've been struggling with that today and I can now wrap up questions more clearly.
    The title should be maybe "How to move a part of application written using "old" MVC into a Package in multiple themes environment".

    1. Controllers
    How should we approach controllers handling in a package, when they are not ViewControllers so that
    -- they are properly initialized (a controller will not be initialized just because the package was loaded, its like putting Ctrl ref into requires only instead of Controllers section)
    -- how to reference controllers from withing package, only full names?
    'MyApp.dashboard.controller.UserWidgetController', is needed instead of 'UserWidgetController',
    -- content of my package was moved from main app, where the controllers were initialized just because they were listed on controllers section.
    For those that were only on require, it was enough to call "getController" and not only this controller, but also all listed within the one requested were initialized.
    If I initialize a controller from within a package, the others listed on Controllers section will not be initialized.

    Of course I can add something like "package controller" in every package, and in it add logic to init all controllers within a package. Then i can create a package loader that will always load a package and get the package controller, and call "init package" function. On the other hand I might be doing something wrong and this should work out of the box.

    2. Packages and Themes
    How to apply package style that is theme specific.
    If I add style to theme (e.g. in packages/local/theme-name/sass/src/app-name/dashboard/view/UsertWidgetView.scss), it will not be picked up and will not be available in the application CSS.
    (It was picked up when the dashboard was part of main app)
    If I put it in the package, it will work, but how to make it theme specific?
    In the package the styling can be only theme independent and located in
    packages/local/dashboard/sass/src/
    As a result it will be included in the package CSS, that is nice as it encapsulates all package elements.
    Maybe my approach is totally wrong, and I should add color definitions and other really specific parts in each theme, and then in the styling for component only refer to theme variables?
    Or maybe map Sass configuration properties to take theme specific files as well (shouldn't they be taken automatically?) I couldn't find a proper path config here...

    3. Dependency between package and application
    The standard approach would be that application requires one or more packages, and packages can require other packages.
    Is it a bad idea to include parts of main application, or should I rather avoid that move that part into another Package that can be then required as a Package and not as a main app class.
    Why I want to access some parts - because I cant "convert" entire app to packages at once
    Without @define the build process will fail with "not found" exception

Similar Threads

  1. [OPEN] [ 5.0.1] multi theme build is broken
    By urban.novak in forum Sencha Cmd
    Replies: 12
    Last Post: 26 Mar 2019, 2:16 AM
  2. ExtJS Build profiles with different packages.
    By Bharath` in forum Sencha Cmd
    Replies: 3
    Last Post: 29 Oct 2015, 11:23 AM
  3. [ 5.0.1] multi theme build is broken
    By urban.novak in forum Ext 5: Bugs
    Replies: 1
    Last Post: 11 Aug 2014, 11:32 PM
  4. Replies: 2
    Last Post: 7 Apr 2014, 1:16 PM
  5. [OPEN] examples/theme.html is broken after sencha packages build
    By leeboonstra in forum Sencha Cmd
    Replies: 4
    Last Post: 31 Jul 2013, 6:35 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •