Assets directory

OpenEMR Development
#21

mdsupport wrote on Monday, June 27, 2016:

While support for multiple versions sounds terrible, may be a project manager’s perspective will be of help.

This project has an old version of CKEditor buried somewhere. Current version of same product lets user edit textareas inline which is great productivity enhancer for staff. So we enabled it for several textarea and textboxes. We had to retain old version used in layouts since it supports custom templates. When funding permits, we will modify layouts. Until then conceptually we consider these as two separate products being used in this project based on the fact that the vendor completely revamped API at some point.

While all modern approaches will bring more order, we have used this (sample) central library to isolate scripts from individual components. Just providing as an example of product management flexibility needed over time.

#22

bradymiller wrote on Monday, July 04, 2016:

Hi,

Placed a pull request to support multiple versions of packages in bower:

-brady
OpenEMR

#23

bradymiller wrote on Tuesday, July 05, 2016:

Hi,

Building on above commit, decided to see what happens if bring in “react” and “literallycanvas” libraries via bower instead (Rod brought this into the codebase very recently for the drawing widget on the LBF forms). And odd things happen when a package has dependencies (in this case the literallycanvas package has react as a dependency). Here is what happens with the following bower.json file:

{
  "name": "openemr",
  "homepage": "http://www.open-emr.org",
  "authors": [
    "OpenEMR"
  ],
  "description": "",
  "main": "",
  "license": "GPL3",
  "ignore": [
    "**/.*",
    "node_modules",
    "bower_components",
    "test",
    "tests"
  ],
  "dependencies": {
    "font-awesome-4-6-3": "font-awesome#4.6.3",
    "literallycanvas-0-4-13": "literallycanvas#0.4.13",
    "react-15-1-0": "react#15.1.0"
  }
}

If I then do “bower install”, get the following output:

[21:51][brady2@nonsense:~/git/openemr(bower-improvement_2)]$ bower install
bower literallycanvas-0-4-13#0.4.13           cached https://github.com/literallycanvas/literallycanvas-bower.git#0.4.13
bower literallycanvas-0-4-13#0.4.13         validate 0.4.13 against https://github.com/literallycanvas/literallycanvas-bower.git#0.4.13
bower react-15-1-0#15.1.0                     cached https://github.com/facebook/react-bower.git#15.1.0
bower react-15-1-0#15.1.0                   validate 15.1.0 against https://github.com/facebook/react-bower.git#15.1.0
bower react#0.14.3                            cached https://github.com/facebook/react-bower.git#0.14.3
bower react#0.14.3                          validate 0.14.3 against https://github.com/facebook/react-bower.git#0.14.3
bower literallycanvas-0-4-13#0.4.13          install literallycanvas-0-4-13#0.4.13
bower react#0.14.3                           install react#0.14.3
bower react-15-1-0#15.1.0                    install react-15-1-0#15.1.0

literallycanvas-0-4-13#0.4.13 interface/static/literallycanvas-0-4-13
└── react#0.14.3

react#0.14.3 interface/static/react

react-15-1-0#15.1.0 interface/static/react-15-1-0

And when then do a ‘bower list’, get the following output:

[21:51][brady2@nonsense:~/git/openemr(bower-improvement_2)]$ bower list
bower check-new     Checking for new versions of the project dependencies...
openemr /home/brady2/git/openemr
├── font-awesome-4-6-3#4.6.3
├─┬ literallycanvas-0-4-13#0.4.13
│ └── react#0.14.3 (latest is 15.2.0)
└── react-15-1-0#15.1.0 (latest is 15.2.0)

The issue here is that bower is creating an unneeded library at interface/static/react/ !!
Here is the commit after I do this (along with changes in Rod’s prior code to use the new libraries). It would be working perfectly except for that pesky unneeded interface/static/react/ library:


Does anybody know of a way to avoid this type of thing in bower?

thanks,
-brady
OpenEMR

#24

bradymiller wrote on Tuesday, July 05, 2016:

Hi,

Ok. was able to sort this out by having bower ignore the ‘react’ sub-dependency in the .bowerrc file. Here is the commit with the solution and is working well. Thus when bring in a package that tries to bring in sub-dependencies, need to place them in the .bowerrc file to prevent them from being brought in:

-brady
OpenEMR

#25

bradymiller wrote on Tuesday, July 05, 2016:

Also placed most recent overview on this ongoing project here:
http://www.open-emr.org/wiki/index.php/Bower

#26

sunsetsystems wrote on Tuesday, July 05, 2016:

Very cool, though I’m kind of a minimalist and would not have thought to use a package manager like this. :slight_smile:

Rod
http://www.sunsetsystems.com/

#27

sunsetsystems wrote on Tuesday, July 05, 2016:

What happens with Bower if we modify an external script after it’s brought in? There’s already a bug in literallycanvas that may be worth fixing.

Rod
http://www.sunsetsystems.com/

#28

bradymiller wrote on Tuesday, July 05, 2016:

Hi Rod,

I am guessing this will be fine (will just plan to record that a change was made on the bower wiki page). Just make the fix in the current codebase (ie. your original library), and I’ll see what happens when try it in the bower stuff.

The reasons for going to bower and standarizing the front-end libraries are:

  1. Make the path to them flexible, so can change the path if needed when/if re-organize codebase in future.
  2. Take control of the front-end packages (these things can be found in many places in the codebase with non-standardized names/paths).
  3. When the packages are all in one place and using standardized names then can begin to upgrade the scripts that are using the older libraries to the newer libraries in a organized/standardized fashion.

-brady

#29

bradymiller wrote on Tuesday, July 05, 2016:

Hi Rod,

Also recommend getting upstream (literallycanvas) to fix it. Then could
upgrade to the newer version (with this fix and the internationalization
fixes) in the future.

-brady

On Tue, Jul 5, 2016 at 11:29 AM, Brady Miller bradymiller@users.sf.net
wrote:

Hi Rod,

I am guessing this will be fine (will just plan to record that a change
was made on the bower wiki page). Just make the fix in the current codebase
(ie. your original library), and I’ll see what happens when try it in the
bower stuff.

The reasons for going to bower and standarizing the front-end libraries
are:

  1. Make the path to them flexible, so can change the path if needed
    when/if re-organize codebase in future.
  2. Take control of the front-end packages (these things can be found in
    many places in the codebase with non-standardized names/paths).
  3. When the packages are all in one place and using standardized names
    then can begin to upgrade the scripts that are using the older libraries to
    the newer libraries in a organized/standardized fashion.

-brady

assets directory
https://sourceforge.net/p/openemr/discussion/202506/thread/d4ec2b8b/?limit=25&page=1#7cae

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/openemr/discussion/202506/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

#30

sunsetsystems wrote on Tuesday, July 05, 2016:

Thanks Brady. They know about the problem now:

However the fix may not happen very soon. We’ll see.

Rod
http://www.sunsetsystems.com/

#31

robertdown wrote on Tuesday, July 05, 2016:

We cannot edit the libraries we bring in with Bower. If there is a bug
you should follow that packages contribution guidelines and when they
fix it we can bring it in by upgrading that Bower project.

We should never be editing third-party plugins, that will break
compatibility with future updates.

#32

sunsetsystems wrote on Tuesday, July 05, 2016:

The time may come when we need to. Upstream may be unwilling to accept our change, or to do it soon enough. In that case we remove them from Bower and maintain a fork?

#33

robertdown wrote on Tuesday, July 05, 2016:

We could fork it and point Bower to our own fork, instead of the
upstream. Hopefully that doesn’t have to happen

#34

bradymiller wrote on Tuesday, July 05, 2016:

Hi,

Note we are not using bower in purist form and are not using it to upgrade packages. Only using it to install packages, which is a 1 time deal for each package. When a new version gets brought in, then another ‘bower install’ is called which should only install the specific version of package that has not yet been installed (and won’t touch the prior version). Thus it would be ok to fix third-party packages if needed (of course, we should avoid this; and if do this, will need to document this on the bower wiki page).(note I do need to test that a ‘bower install’ doesn’t check that already installed files have not been modified, but I am pretty sure it only looks for the bower.json file).

-brady

#35

osverdlov wrote on Wednesday, July 06, 2016:

Let’s assume for example we brought a package into package-123 folder and linked this library in all the code.

Then we discover a bug in the package and help its maintainer to fix the bug.

The maintainer publishes v1.2.4 and we need to fix paths in all the code again.

With best regards,
Oleg Sverdlov

#36

bradymiller wrote on Wednesday, July 06, 2016:

Hi Oleg,

Changing the link in even several hundred scripts would be easy via sed. Testing it is another matter. Are you proposing a different solution?

If not proposing a alternative strategy, then planning to proceed. Note that even if proceed and commit these changes to the codebase, things are never set in stone, and it would be straighforward to change the “strategy” since we are only in the early stages (I am planning to bring in almost 10 or so assets soon for Ray’s eye form and Kevin’s EDI stuff in the near future, so that will be a good feasibility test).

-brady
OpenEMR

#37

bradymiller wrote on Wednesday, July 06, 2016:

Hi,

I’ve confirmed that we can change third party files after installing them via bower without causing problems (ie. the fixes would not be reverted during a ‘bower upgrade’ or ‘bower install’). Of course, we should avoid this if possible. But good to know we can do it if needed(and if do this, would track this on the bower wiki page: http://www.open-emr.org/wiki/index.php/Bower ).

-brady
OpenEMR

#38

bradymiller wrote on Friday, July 08, 2016:

Hi,

I’m starting to bring in packages to prepare for Ray’s eye module; it’s still a work in progress:

The question I had is if we should be removing the .gitignore and .gitattributes files from the packages?

-brady
OpenEMR

#39

sunsetsystems wrote on Friday, July 08, 2016:

I did for literallycanvas but forget what the issue was. Probably best to look at what’s in them and then decide.

Rod
http://www.sunsetsystems.com/

#40

bradymiller wrote on Saturday, July 09, 2016:

Hi,
Was experiencing some strange behavior regarding end of line processing with a .gitattributes file that was included, so figured was best to just always remove these things as part of the package install.
-brady
OpenEMR