On 18 January 2012 02:05, Merrill, Jason <jason.merr...@bankofamerica.com>wrote:
> > > The problem isn’t even that large companies are in bed with Microsoft > (that is a problem), but it’s that they have many many existing legacy > enterprise apps that only work or have only been tested to work in IE, and > those systems need to be supported and in place for years to come. > It is also worth mentioning that if any of you have spent any time being a Windows desktop system administrator, you will appreciate the management features that only IE has in conjunction with group policy. Changing/enforcing proxy settings, certificate authorities, cache policies, homepages, look and feel settings and more can be done by just flicking a few settings in Group Policy. To do the same with Firefox, you'll have to modify a bunch of files on installation, and on every change, push out a new prefs.js file. Sounds easy enough, but try doing that when you have different settings that apply depending on the site the user is at, the groups they're a part of, etc. Unfortunately, none of the alternative browsers seem to pay much attention to the enterprise, so IE is pretty safe until there is a reasonable alternative. > Jason Merrill > Instructional Technology Architect II** > > *Bank of America* Global Learning **** > > ** ** > > ** ** > > ** ** > > ** ** > > ** ** > > _______________________**** > > ** ** > > *From:* flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] *On > Behalf Of *valdhor > *Sent:* Monday, January 16, 2012 9:20 AM > > *To:* flexcoders@yahoogroups.com > *Subject:* [flexcoders] Re: Flex alternatives**** > > ** ** > > **** > > Good luck on convincing IT departments in large corporations who are > generally Microsoft shops. > > > --- In flexcoders@yahoogroups.com, Guy Morton <guy@...> wrote: > > > > A thought on cross-browser hell… > > > > If every web developer in the world today decided to drop support for > IE, everyone would go get Chrome or Firefox. > > > > This would be a win-win, as they would get a better browser, and we > would get a better development environment. > > > > Who's with me? > > > > Guy > > > > > > On 16/01/2012, at 6:31 AM, Ron G wrote: > > > > > > > > > > > Valdhor: > > > > > > You are right about that. That is precisely why we went with Flex > originally (it insulated us from X-Browser issues). But, since we can't > count on that lasting, and even Adobe is telling developers to plan on > moving to HTML5, it seems like they're pushing us back into x-browser hell. > > > > > > I didn't want to go there, which is why we chose ZKoss. Yes, there is > still going to be HTML/JS/CSS ultimately used, but it's how much. Even Flex > SWFs are wrapped in HTML and JS when deployed. So, it's not that I'm > against using any amount of HTML/JS; it's how little can I get away with to > avoid these issues. > > > > > > Even with HTML5 libraries, such as the much touted jQuery, is, to a > large degree, an insulator against x-browser issues. If you read the actual > jQuery code, it deals with those issues for you. > > > > > > Now, ZK has a ZK Client JS library, which includes jQuery, that is > designed to be a communicator mechanism between the client and the bulk of > app logic that resides on the server. So, your normal editing and data > manipulation that you might write in JS in a full blown HTML5 app is > actually stored as Java on the server, and executed as needed per the EDA > (event driven architecture). This type of JS is typically what breaks the > page on different browsers and versions thereof. By limiting the amount of > client-side JS, as does a jQuery type library, yes, you have some exposure > to potential x-browser issues, but not as much as a HTML5 app that does > everything on the client. And, when there are issues, they can be resolved > in the ZK Client library as a patch/fix. > > > > > > So, now it seems to me that developers have several choices. Stick > with Flex and you won't break the browser; you just won't be able to have > your app viewed by millions on iOS products. If that seems like a better > solution that minimal exposure to x-browser issues by using ZK or some > other technology, well, that's certainly a choice each company has to make. > > > > > > Ron > > > > > > --- In flexcoders@yahoogroups.com, "valdhor" <valdhorlists@> wrote: > > > > > > > > > > > > On a side note, I like the look of ZKoss. I don't know if there are > cross browser issues with it seeing as we use older versions of browsers. > One of the great features of Flex is we don't have to bother coding for > compatibility between different browsers and versions. When IT deployed > IE7, Flex applications worked just as they had before. > > > > > > > > Anyway, just my 2c from the enterprise perspective. > > > > > > > > > > > >**** > > **** > ------------------------------ > This message w/attachments (message) is intended solely for the use of the > intended recipient(s) and may contain information that is privileged, > confidential or proprietary. If you are not an intended recipient, please > notify the sender, and then please delete and destroy all copies and > attachments, and be advised that any review or dissemination of, or the > taking of any action in reliance on, the information contained in or > attached to this message is prohibited. > Unless specifically indicated, this message is not an offer to sell or a > solicitation of any investment products or other financial product or > service, an official confirmation of any transaction, or an official > statement of Sender. Subject to applicable law, Sender may intercept, > monitor, review and retain e-communications (EC) traveling through its > networks/systems and may produce any such EC to regulators, law > enforcement, in litigation and as required by law. > The laws of the country of each sender/recipient may impact the handling > of EC, and EC may be archived, supervised and produced in countries other > than the country in which you are located. This message cannot be > guaranteed to be secure or free of errors or viruses. > > References to "Sender" are references to any subsidiary of Bank of America > Corporation. Securities and Insurance Products: * Are Not FDIC Insured * > Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not > a Condition to Any Banking Service or Activity * Are Not Insured by Any > Federal Government Agency. Attachments that are part of this EC may have > additional important disclosures and disclaimers, which you should read. > This message is subject to terms available at the following link: > http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender > you consent to the foregoing. > > > >
