Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 2.3.0-rc1, 2.3
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-8226Improve ability to track changes to maintenance data, such as Assets and Vendors.
      KULRICE-4289improve error handling in KualiAction.performLookup(..)
      KULRICE-9739Improve ease of configuration of JPA for a module that is using KRAD
      KULRICE-9599Validation framework improvement for handling collections differently
      KULRICE-10454Improve handling of the binding errors
      KULRICE-12551Improvements on handling of template options
      KULRICE-3247Improve handling in KualiDecimal constructor
      KULRICE-8558improve error handling in KualiDocumentActionBase.docHandler(..)
      KULRICE-9105Determine how to do a more efficient and less wasteful approach for XML object serialization for the maintenenace framework
      KULRICE-9537Document the approach for conversion to krad-data of the various internal Rice modules
    • Rice Module:
      KRAD
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      Currently the handling of asset tagging, minification, and general theme building could use some improvements. See comments for more information.

        Issue Links

          Activity

          Hide
          Jerry Neal (Inactive) added a comment -

          Well, we might consider executing the minification programatically as well if that would help. I think it actually might make sense if what we did was provide a standard location where javascript and css files could be added such that they would automatically be loaded and compiled into any views for that particular module (i.e. src/main/assets or src/main/webapp/assets or src/main/webapp/WEB-INF/assets maybe?) . This is how a lot of other convention-based frameworks work and is something which saves time for developers because they really don't have to do anything manually to enable all of this behavior.

          See the asset pipeline for Ruby on Rails:

          http://guides.rubyonrails.org/asset_pipeline.html

          Or the equivalent in the Java Play! framework:

          http://www.playframework.com/documentation/2.0/Assets
          http://www.playframework.com/documentation/2.0/AssetsLess
          http://www.playframework.com/documentation/2.0/AssetsGoogleClosureCompiler

          These kinds of frameworks are our "competition" so to speak since we are trying to build similar levels of functionality into KRAD.

          I suppose what you guys are talking about below though are "theme"-related assets. It seems like for that as well a custom theme should have a standard directory structure to it which might also include a set of asset directories where you would place css, javascript, etc. Then when the theme gets bundled up you could do the minification (still using maven) but you wouldn't have to manually list out every file (it would just include everything in the appropriate directory based on convention). But I could be oversimplifying things a bit as I haven't really looked much at the custom theme stuff

          At any rate, I would love to see KRAD having a similar level of capability as the Rails asset pipeline where it can automatically minify, etag, and fingerprint for you and the developer gets all of that for free without having to configure anything. I wonder if someone has already built something similar in Java that we could use?

          Thanks,
          Eric

          Show
          Jerry Neal (Inactive) added a comment - Well, we might consider executing the minification programatically as well if that would help. I think it actually might make sense if what we did was provide a standard location where javascript and css files could be added such that they would automatically be loaded and compiled into any views for that particular module (i.e. src/main/assets or src/main/webapp/assets or src/main/webapp/WEB-INF/assets maybe?) . This is how a lot of other convention-based frameworks work and is something which saves time for developers because they really don't have to do anything manually to enable all of this behavior. See the asset pipeline for Ruby on Rails: http://guides.rubyonrails.org/asset_pipeline.html Or the equivalent in the Java Play! framework: http://www.playframework.com/documentation/2.0/Assets http://www.playframework.com/documentation/2.0/AssetsLess http://www.playframework.com/documentation/2.0/AssetsGoogleClosureCompiler These kinds of frameworks are our "competition" so to speak since we are trying to build similar levels of functionality into KRAD. I suppose what you guys are talking about below though are "theme"-related assets. It seems like for that as well a custom theme should have a standard directory structure to it which might also include a set of asset directories where you would place css, javascript, etc. Then when the theme gets bundled up you could do the minification (still using maven) but you wouldn't have to manually list out every file (it would just include everything in the appropriate directory based on convention). But I could be oversimplifying things a bit as I haven't really looked much at the custom theme stuff At any rate, I would love to see KRAD having a similar level of capability as the Rails asset pipeline where it can automatically minify, etag, and fingerprint for you and the developer gets all of that for free without having to configure anything. I wonder if someone has already built something similar in Java that we could use? Thanks, Eric
          Show
          Jerry Neal (Inactive) added a comment - http://yui.github.com/yuicompressor/
          Hide
          Jerry Neal (Inactive) added a comment -

          Part of the theme work being done

          Show
          Jerry Neal (Inactive) added a comment - Part of the theme work being done
          Hide
          Jessica Coltrin (Inactive) added a comment -

          moving out of scope for 2.3 as we narrow down to what's critical for release.

          Show
          Jessica Coltrin (Inactive) added a comment - moving out of scope for 2.3 as we narrow down to what's critical for release.
          Hide
          Jerry Neal (Inactive) added a comment -

          This is part of the theme work that is going in

          Show
          Jerry Neal (Inactive) added a comment - This is part of the theme work that is going in

            People

            • Assignee:
              Jerry Neal (Inactive)
              Reporter:
              Jerry Neal (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel