FLUID-5458 (for the 1.5.x branch)

[jobara]

Updated the .npmignore file and updated the version numbers to 1.5.1 in preparation for the 1.5.1 tag.

http://issues.fluidproject.org/browse/FLUID-5458

[colinbdclark]

Can we remove project.xml, project.properties, and pom.xml now that we've removed Ant and Maven from our build process?

[colinbdclark]

After reviewing and testing this pull request, I started to think through what we want to include in our Node module. There are two things that are currently left in, which we may not want to include:

• The ProgressiveEnhancement library
• The Preferences Framework

Both of these are DOM-dependent. The Preferences Framework is likely also dependent on jQuery UI, which we omit. Should we exclude these two libraries from our Node module as well, then?

Thoughts?

[jobara]

@colinbdclark is the issue with the progressiveEnhancement around the use of "window"? I think that progressiveEnhancement could generally be useful. Perhaps we just need to be more careful with the use of or inclusion of the built in feature detection functions. Maybe we could just fix up the issues for 1.5.1 and 2.0? What do you think?

[colinbdclark]

Hi @jobara, yes the issue is that there are a number of DOM-dependent parts to the current ProgressiveEnhancement.js file. It's not so much the use of "window," as the fact that we've got several checks--supportsBinaryXHR and supportsFormData in particular--that are expecting to be run in a browser environment, as well as the section at the end of the file that toggles CSS classes.

We would need to factor these checks out into separate files and think clearly about how they get linked to the environment. My impression is that this might be a bit much for the 1.5.1 release, but I'm cool if you think it's doable. It certainly would be useful to have this feature available in for Node.js code.

Alternatively, we could exclude the feature in our Node module until 2.0. What do you think makes the most sense?

[jobara]

@colinbdclark, supportsBinaryXHR and supportsFormData don't run automatically. I suppose we could factor them out into a separate file, but I don't think they should be too harmful. The css stuff only runs if we are in a browser, so this should also be safe, although again maybe it could be factored into a different file. What do you think would be best?

[colinbdclark]

Okay, that's fine. It seems like we should factor out the browser-specific code for 2.0, even if it doesn't run by default. We really should have some basic unit tests to show that our Node module actually works, since in the past we have regressed because of issues similar to this.

[jobara]

I've filed a couple new jiras related to the issues mentioned above.:

• http://issues.fluidproject.org/browse/FLUID-5467
• http://issues.fluidproject.org/browse/FLUID-5468

I've also filed another pull request to add some of the resent changes into master. #544

This pull request is ready for review again.

[amb26]

Hi @jobara - your previous comment includes the same JIRA twice - could you double-check the number? I placed a comment on #544 suggesting that removing the prefs framework from npm may be premature, similar to the status of progressiveEnhancement. I think we need to work harder to factor DOM/non-DOM code apart from each other before we can achieve this.

In the day when we have the "new renderer", this distinction will become even more unclear, since even viewComponents will be capable of running on the server.

[jobara]

@amb26 Thanks for catching that. I've updated the comment with the other jira number.