I just completed a very busy page with Pyjs. It doesn't work under IE8 or IE9 when they are running in "compatibility mode" which may cause them to misidentify themselves and trigger IE6 type compensation on the pyjs side. Chrome does some strange things as well.
Basically, with IE in compatibility mode, which is the default setting in this very liimited customer base, the + to open a tree branch selects the item. A click on the circle which surrounds the plus at 8 to 9 o'clock will open or close, and a click about halfway between the + and the item seems to work for opening or closing. The result? I am probably going to be redoing the work in dojo unless I can figure out how to corret that sensitivity. No guarantee that Dojo will work, but it is "standard technology". Javascript may have its strengths but Javascript and jQuery have already failed on these browser clients which range from IE6 through this woeful "compatibility mode" setting in IE8 and IE9 to Chrome (click anywhere in the same line to the right of the tree item to select it on my pyjs trees using Chrome.) The fact is none of these technologies behave the same on different browsers, and that may be the browser design or the flaws in the ECMAScript standard itself.. And anyone who has to work with this technology will have his choices challenged by real life malfunctions even though they may be the same malfunctions that would occur in one or all of the competing technologies. Engineers tend to disagree. In other news, the sun rises in the east and sets in the west. That is not to say we should not listen. There is bloat, and some things are better blocked than allowed through. t s almost always a terrible idea to use recursion in Javascript, so my design was to send in flattened trees for display via JSONRPC-AJAX apparatus, and being careful how I coded in Pyjs to make minimal use of the calls that would invoke child-parent relationships. Pyjs is powerful and presents no greater learning curve than jQuery or Dojo, and is the logical choice when the data is better served with traversal than routes, and object databases than SQL-driven RDBMSes. It is the appspace that is the real problem, and the fat that some browsers are loading different feature sets, so that browser detection is no longer a good yardstick and the effort to adapt seems to be working at cross-purposes. I will help any way I can to bring some resolution to the issues, but none of us are going to resolve it by favoring one technology over another, even though I believe strongly that Java treats me like an idiot and is today's COBOL. Consider an app that displays a tree and some action buttons in a separate panel. Depending on what layer in the tree is selected, different action buttons appear in the other panel. Find a technology that handles that, AND behaves smartly in a plethora of browsers. Right now, I don't think it can be done, not by pyjs nor by any of the competing technologies, not without a lot of descent into Javascript. Michael On Fri, Aug 17, 2012 at 2:47 AM, Peter Bittner <[email protected]>wrote: > Alexander Tsepkov has written a thorough analysis on the drawbacks of > pyjs as a Web applications development framework. > > - Browser Detection instead of Feature Detection > - Bloat and Boilerplate Hell > - Debugging > - Python is not Java, DOM is not a Desktop > - JavaScript has its Strengths > > We probably should take these hints seriously, think of what can be > improved (under the light of feasibility, and sustainable investment), > and prioritize tasks derived from that. > > I've always suspected that the ideal world can only be a pyjs > framework that combines the ease of Python programming with the > lightweight of current JavaScript frameworks (e.g. jQuery, > CoffeeScript, etc). There's an obvious focus on the "ease of > programming" today, at the same time we're not following current > developments in Web development---at all or not fast enough. > > Tweeted today: > https://twitter.com/pyjsorg/status/236265223852552192 > > -- > > > > --
