Re: [openstack-dev] [horizon] function expressions vs function declarations in JavaScript
Just to expand a bit on Thai's response.. Make the changes to horizon/doc/source/contributing.rst and submit a patch, once that gets approval then go update the wiki. On 1/14/2015 3:49 PM, Thai Q Tran wrote: Wow, that IS interesting. No process required, just modify /horizon/doc/source/contributing.rst and submit a patch. -Matthew Farina m...@mattfarina.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org From: Matthew Farina m...@mattfarina.com Date: 01/14/2015 12:20PM Subject: Re: [openstack-dev] [horizon] function expressions vs function declarations in JavaScript Thai, I'm still poking around at JavaScript things and did a little testing on function declarations vs function expressions. Seems Firefox is faster with function expressions by quite a bit at parse time. For reference see http://jsperf.com/mfer-function-types. I'm not suggesting what we do. I'm just sharing a data point I found surprising. I'm curious about the process for proposing changes to https://wiki.openstack.org/wiki/Horizon/Javascript. Is there any process? On Wed, Jan 14, 2015 at 1:15 PM, Thai Q Tran tqt...@us.ibm.com mailto:tqt...@us.ibm.com wrote: It was definitely an interesting the read, I never really noticed the subtle difference. Since then I have also read a few other thoughts on it. For me, function declarations can get convoluted very fast if not use correctly. Surely, you should never define functions inside of an if statement, and quite confusing to do it after a return statement. But they do have their uses when used correctly. I think it ultimately depends on what you are trying to do and whether it make sense to use declarations vs expressions. As long as people understand the difference, and take it case-by-case, its not really something I'm going to mull over too much. -Matthew Farina m...@mattfarina.com mailto:m...@mattfarina.com wrote: - To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org From: Matthew Farina m...@mattfarina.com mailto:m...@mattfarina.com Date: 01/14/2015 07:04AM Subject: [openstack-dev] [horizon] function expressions vs function declarations in JavaScript JavaScript has multiple ways to deal with functions. There are function declarations and function expressions (and named function expressions). In looking at some reviews and the current code I found some inconsistencies which leads me to ask, is there any guidance for handling this in Horizon? I noticed no documentation in https://wiki.openstack.org/wiki/Horizon/Javascript. Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] [ux] Changing how the modals are closed in Horizon
The more I think on it. I agree with Rob Cresswell comment While clicking off the modal is relatively easy to do my accident, hitting Esc or 'X' are fairly distinct actions. While there is nothing wrong with warning the user that they will lose data after they clicked the 'x' / 'esc'... That was a deliberate action by them. So might be over engineering this. My vote is to just keep it simple and go with changing the default behavior to 'static'. On 12/4/2014 8:08 AM, Timur Sufiev wrote: Hi Aaron, The only way to combine 2 aforementioned solutions I've been thinking of is to implement David's solution as the 4th option (in addition to true|false|static) on a per-form basis, leaving the possibility to change the default value in configs. I guess this sort of combining would be as simple as just putting both patches together (perhaps, changing a bit David's js-code for catching 'click' event - to work only for the modal forms with [data-modal-backdrop='confirm']). On Thu, Dec 4, 2014 at 1:30 AM, Aaron Sahlin asah...@linux.vnet.ibm.com mailto:asah...@linux.vnet.ibm.com wrote: I would be happy with either the two proposed solutions (both improvements over the what we have now). Any thoughts on combining them? Only close if esc or 'x' is clicked, but also warn them if data was entered. On 12/3/2014 7:21 AM, Rob Cresswell (rcresswe) wrote: +1 to changing the behaviour to 'static'. Modal inside a modal is potentially slightly more useful, but looks messy and inconsistent, which I think outweighs the functionality. Rob On 2 Dec 2014, at 12:21, Timur Sufiev tsuf...@mirantis.com mailto:tsuf...@mirantis.com wrote: Hello, Horizoneers and UX-ers! The default behavior of modals in Horizon (defined in turn by Bootstrap defaults) regarding their closing is to simply close the modal once user clicks somewhere outside of it (on the backdrop element below and around the modal). This is not very convenient for the modal forms containing a lot of input - when it is closed without a warning all the data the user has already provided is lost. Keeping this in mind, I've made a patch [1] changing default Bootstrap 'modal_backdrop' parameter to 'static', which means that forms are not closed once the user clicks on a backdrop, while it's still possible to close them by pressing 'Esc' or clicking on the 'X' link at the top right border of the form. Also the patch [1] allows to customize this behavior (between 'true'-current one/'false' - no backdrop element/'static') on a per-form basis. What I didn't know at the moment I was uploading my patch is that David Lyle had been working on a similar solution [2] some time ago. It's a bit more elaborate than mine: if the user has already filled some some inputs in the form, then a confirmation dialog is shown, otherwise the form is silently dismissed as it happens now. The whole point of writing about this in the ML is to gather opinions which approach is better: * stick to the current behavior; * change the default behavior to 'static'; * use the David's solution with confirmation dialog (once it'll be rebased to the current codebase). What do you think? [1] https://review.openstack.org/#/c/113206/ [2] https://review.openstack.org/#/c/23037/ P.S. I remember that I promised to write this email a week ago, but better late than never :). -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur Sufiev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Cookie collision between Horizon Stacktach
I was posed this question, but am not familiar with Horizon or StackTach cookie management. Anyone know what the issue might be? Issue: Logging into one site logs you out of the other. (horizon/stacktach) First I open horizon and notice there are two cookies: csrftoken (horizon) and sessionid. I log into Horizon, then open up a new tab and log into stacktach (same domain, different port). After logging into stacktach, there's another cookie created named beaker.session.stacktach. I go back to the horizon dashboard and get logged off after clicking anything. After trying to log back in, this error comes up: Your Web browser doesn't appear to have cookies enabled. Cookies are required for logging in. I then clear the cookies and am able to log in, but see this error message: Forbidden (403) CSRF verification failed. Request aborted. I go back to the Horizon log in page, finally log in, go to stacktach tab and am logged out of that. Note that stacktach is at a separate port on the controller and uses beaker to create the cookie session. I've read that cookies aren't port-speciic on the same domain name, but should still work with different cookie names.. I've also tried changing the paths on the stacktach urls, but no luck there either. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] Licensing issue with using JSHint in build
I noticed that the build is using JSHint now, and before I consider syncing it with the proposed options from the JavaScript best practices (https://review.openstack.org/#/c/117595/), I wanted to double check and be sure Horizon got past the legal problem with the good/evil licensing. Some background for those who are not aware. JSHint was authored by Doug Crockford, and he added an extra line in the licensing, The software shall be used for good, not evil. The issue is in the definition of what is good and what is evil. It is too subjective, what is evil differs from person to person therefore ends up being a liability and leaving users open to frivolous lawsuits. Did Horizon get permission or find some way around the licensing issue? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Licensing issue with using JSHint in build
What you are finding is the same as I found, which raised my concern. Thanks for the pointer to legal-disc...@lists.openstack.org, I will post the question there (let the lawyers figure it out). On 9/10/2014 12:16 PM, Solly Ross wrote: - Original Message - From: Jeremy Stanley fu...@yuggoth.org To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, September 10, 2014 1:10:18 PM Subject: Re: [openstack-dev] [Horizon] Licensing issue with using JSHint in build On 2014-09-10 13:00:29 -0400 (-0400), Solly Ross wrote: JSHint *isn't* Douglas Crockford. It was written by someone who (understandably) thought Douglas Crockford had some good ideas, but was overzealous. [...] Overzealous enough to copy his code. ?? This sentence doesn't make much sense. I meant to say that Douglas Crockford was overzealous (which he is, IMO). The license is as such: https://github.com/jshint/jshint/blob/master/LICENSE Ahem. https://github.com/jshint/jshint/blob/master/src/jshint.js#L19 Fair enough. I stand corrected. I didn't catch that. The general license, however, is as stated. You are thinking of JSLint, which is written by Douglas Crockford. JSHint is a derivative project of JSLint. Sorry to burst your bubble. To be fair, it's been undergoing *major* revisions lately, making it resemble JSHint less and less in terms of what it checks for. Having used it in the past, functionality wise it's very different. While it maintains some backwards compatibility, it has added in new checks, doesn't complain about nearly the number of things that JSLint complains about (for good reasons). -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
