jquery vs dojo vs yui etc
in [JavaScript]
|
Prev: Interactive web-based graphs for iPads?
Next: FAQ Topic - How can I disable the back button in a web browser? (2010-06-17)
From: VK on 17 Jun 2010 17:06 On Jun 18, 12:38 am, Kenneth Tilton <kentil...(a)gmail.com> wrote: > Aside from the stuff that requires browser support*, yes, you could be > wrong. Of course you might not be aware that Lisp can call C and be > called back from C. In my career I had to extend and to adjust some AutoLISP for AutoCAD http://en.wikipedia.org/wiki/AutoLISP and I dare to tell that I never had anything more contre-OOP and contre-instinctive ever since Sinclair Basic http://en.wikipedia.org/wiki/Sinclair_BASIC or *even* before it: but again I might be missing the appropriate mind set - still my first aim was out to the VBA higher level asap and where to solve the posed problems. Again, it is a purely personal experience.
From: Garrett Smith on 17 Jun 2010 19:43 On 6/17/2010 10:31 AM, Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> I've looked for, but found no unit tests. If I'm going to use something, >>>> I want to run tests on it to verify the edge cases. >>> What's wrong with JsUnit?<http://www.jsunit.net/> >> >> There aren't any JsUnit tests on cinsoft.net, so I assume you are asking >> what I think of JsUnit in general. > > Yes, I misunderstood what you were aiming at. > >> From memory, last I used JsUnit (over 3 years), my complaints were: > > The master branch at github was last updated 2010-02-18, the latest release > (2.2) was uploaded 2009-11-28. So it might be time for another review. > >> * UI problems. Nested frame layout makes it hard to view source > > That hasn't changed, but I do not consider it a problem in itself. I have a > source code editor to view and edit the source if it turns out to be > erroneous. What I have a problem with is that the test site of JsUnit 2.2 > is apparently not scrollable in Firefox (so I need full screen), but that > could be remedied. > >> * Doesn't scale well; large suites, such as those on w3.org, are a >> runaway train that can't be stopped (the UI is really bad). > > There is a Stop button, so that appears to have changed in the meanwhile. > That actually sounds familiar. However, I do not recall useful stop functionality. >> * poor stack trace functionality / reporting > > It can only be as good as what the ECMAScript implementation provides. I > think they are doing not bad there. I could even reuse their approach in > providing a stack trace along with my exceptions. > >> * No dom abstraction layer for dispatching events > > That appears to have changed. > >> * No asynchronous testing features. > > How do you propose that to be implemented? > wait and waitForCondition can each use setTimeout. The test that fires oncomplete when all deferred segments are done and to know when that happens, it subscribes to the "oncomplete" of each segment. This means that tests may complete out of order. A test is part of a tree structure and has a testableList of deferred segments (possibly 0 length). A deferred segment is also a Test and when a deferred segment calls wait, then the deferred segment gets an item in its testableList; it won't fire oncomplete until is not done. TestRunner is the root node of the tree. TestRunner can have tests and suites, but the caller doesn't actually have to create formal structures, the caller can just add things to the TestRunner. I explained a little recently in MessageID: hv3v71$km$1(a)news.eternal-september.org It's a little sloppy right now; I've got some rough spots in it. > Which alternatives to JsUnit are you recommending? The most relevant I found at the time I was searching was YUI Test I've run into too many problems with that. Starting with the author takes a long time to fix bugs (1 year+). Getting free contributions accepted to YUI requires you to sign legal documentation that I don't want to sign. I have had to patch many things in it, such as relatedTarget not working properly. The source code shows the problems in code comments and the author shows how he did not solve them. /* * Check to see if relatedTarget has been assigned. Firefox * versions less than 2.0 don't allow it to be assigned via * initMouseEvent() and the property is readonly after event * creation, so in order to keep YAHOO.util.getRelatedTarget() * working, assign to the IE proprietary toElement property * for mouseout event and fromElement property for mouseover * event. */ if (relatedTarget && !customEvent.relatedTarget){ if (type == "mouseout"){ customEvent.toElement = relatedTarget; } else if (type == "mouseover"){ customEvent.fromElement = relatedTarget; } } You can see the test function is tied to the code that is being tested. The author's comment "in order to keep YAHOO.util.getRelatedTarget() working, assign to the IE proprietary toElement property" Mentioning problems to the author is a waste of time; he just either ignores email or won't fix the bugs. http://sourceforge.net/tracker/?func=detail&atid=836476&aid=1889966&group_id=165715 Got fixed. Other bugs that didn't were the event simulation req for Apple Touch Events. I submitted a patch and the reply I got was "please sign these legal documents so we can use your code for free.". Wow, what a great way to show appreciation. No thanks, I'll just patch where I need to and forget about submitting bugs in the future. The debugging issues in YUI Test are painful. Each dispatched event calls a very long function -- around one hundred statements or so. This is a problem when you want to step from dispatching the event through to the callback. Given an element "myTargetObject" with a mousedown event handler, the following test would dispatch that event and then afterwords, the condition of `a` could be checked. Synth events are not always the same, so sometimes you want to step into with debugger to see what actually happens. For example: testMyEvent : function() { debugger; // Click 'step over' 47 times after this Action.mousedown(myTargetObject); Assert.isTrue(myTargetObject.a, msg); } After explaining to the author how to refactor that, he brushed off the possibility and claimed that the functions must be long and then ignored all subsequent emails. So again, I wasted time to try to help but got no appreciation for it. I get the sense that it is more of a public image type of thing with the author. I also found that focus and blur events were not implemented, but needed to be for some cases; that is: Where `focus()` on particular object would not work for that given case. I can't remember why, maybe it had to do with onfocusin -- I forgot. I added support for focus and blur events (which also fire onfocusin and onfocusout). Other frustrations are the inability to rerun just one particular test function. In 2007, I found that YUI Test was attractive. The limitations have become so burdensome that it is time to move on. Garrett
From: Kenneth Tilton on 18 Jun 2010 00:24 VK wrote: > On Jun 18, 12:38 am, Kenneth Tilton <kentil...(a)gmail.com> wrote: >> Aside from the stuff that requires browser support*, yes, you could be >> wrong. Of course you might not be aware that Lisp can call C and be >> called back from C. > > In my career I had to extend and to adjust some AutoLISP for AutoCAD > http://en.wikipedia.org/wiki/AutoLISP What has an AutoCAD embedded language got to do with Lisp? Please do not answer "the sequence l, i, s, and p.". Hint. > and I dare to tell that I never had anything more contre-OOP and > contre-instinctive ever since Sinclair Basic > http://en.wikipedia.org/wiki/Sinclair_BASIC > or *even* before it: but again I might be missing the appropriate mind > set - still my first aim was out to the VBA higher level asap and > where to solve the posed problems. Again, it is a purely personal > experience. Of AutoCAD. Of Lisp you know nothing. hth, kt -- http://www.stuckonalgebra.com "The best Algebra tutorial program I have seen... in a class by itself." Macworld
From: Stefan Weiss on 18 Jun 2010 01:47 On 18/06/10 01:43, Garrett Smith wrote: > I submitted a patch and the reply I got was "please > sign these legal documents so we can use your code for free.". Wow, what > a great way to show appreciation. No thanks, I'll just patch where I > need to and forget about submitting bugs in the future. I don't think it's unreasonable to require patch submitters to waive their rights to the code. Many of the larger open source projects have similar policies. They exist to protect the company from malicious contributors, and from those who change their minds later on. Without this procedure, you could for example submit someone else's code to the project, wait until it has been distributed, and then sue or blackmail them. It also gives Yahoo! the option to change or update the license later one without having to get approval from each and every contributor. The Linux kernel is in that situation - the kernel maintainers couldn't change the license from GPL2 to GPL3 (even if there was a consensus to do so among the maintainers). Having a dedicated upload form for patches with a checkbox to that effect may not be enough; to be legally safe, they'd need to be reasonably sure of your identity. Smaller projects may opt for a simpler procedure or just ignore the possible legal consequences, but Yahoo! is a high profile company with a significant investment in this library. Imagine that there was a rival company - let's call it "Mondosoft" - trying to acquire Yahoo!. They could just smuggle in some of their code bits at a time, and then use scare tactics like "YUI violates 235 of Mondosoft's patents". It would make for good ammunition in their next acquisition attempt. That said, I was in a similar situation as you, twice. Both times I decided it wasn't worth the hassle to sign and send back their documents, and in the end didn't submit the patches. So yes, I agree that the legal safeguards can be a huge motivational hurdle for potential submitters. -- stefan
From: Garrett Smith on 18 Jun 2010 02:15
On 6/17/2010 10:47 PM, Stefan Weiss wrote: > On 18/06/10 01:43, Garrett Smith wrote: [...] > > That said, I was in a similar situation as you, twice. Both times I > decided it wasn't worth the hassle to sign and send back their > documents, and in the end didn't submit the patches. So yes, I agree > that the legal safeguards can be a huge motivational hurdle for > potential submitters. > It's not just that. I'm trying to help - FOR FREE - and don't want to be asked to go through the extra effort to sign legal obstacles to satisfy some corporate lawyers. The author can copy the code I wrote, and change it as I suggested, and, for extra-credit, try and improve on it. http://yuilibrary.com/projects/yui2/ticket/2528514 Opened last September and I'll bet you that uneaten kipferl that it'll sit there for at least another 5 months. This one has been in cue for two years! http://yuilibrary.com/projects/yui2/ticket/1924108 (yes I'm the reporter there, too). It might seem like I've got beef with the author -- well, in addition to the unfixed bugs, ignored emails, yes, I do. I'm going to make a post about that. Garrett |