[EDIT: this is a discussion better suited for the Dojo Core forum.]
Every time give v 0.9 a try I end up going back to v. 0.4.
1) v.0.9 lacks many 0.4 features
2) it doesn't seem to load faster
3) porting from 0.4 to 0.9 is a pain in the ...
4) documentation is poor
5) no demos
6) examples are too basic
7) the porting guide does not guide much
Disagree on #2
Heya,
I have to disagree on #2. When I looked at Dojo 0.4 about three months back, I decided I couldn't use it because it locked up the browser for 10 seconds or more every time Dojo had to load. 0.9 loads so much faster it's really something. Add to that the AOL CDN stuff...
I completely agree about the documentation. Dante tells me that documentation is the major goal before 1.0 (here). It's really unfortunate that more of the documentation wasn't done simultaneously with the coding/porting (especially the in-code documentation that feeds into the API tool), but it wasn't, so it will have to be done retrospectively.
On #5: It's true that there is a real lack of demos. In the meantime, I've learnt a great deal from the various test pages. Nearly everything that's in 0.9 has a test page, and those test pages usually (not always) provide the information I need to get going on stuff. It needs to be better, and I'm sure it will be better, but for now there is at least that to work with.
Have you sent in your CLA? This is open source... ;-)
--
T.J. Crowder
tj at crowder software dot com
Dojo 0.9 is good for me.
We've been preparing for Dojo 0.9 over the last couple of weeks and I'd have to say that our experiences are quite different from the original poster in this thread:
1. Dojo 0.9 is very much faster.
2. We've already ported some of our home grown widgets and it wasn't a big deal.
3. The porting guide was useful.
YMMV and it depends on how you have been using Dojo. For me, Dojo 0.9 is good stuff and a huge leap in the right direction.
I agree. Documentation is everything
CLA? I am afraid I am not familiar with this term.
Just to be clear: I like this toolkit a lot and actually use it in my projects. What I am complaining about is that its developers seem to do their best to discurage people from using it. And the reasons are:
1) this site is slow and poorly designed. It might be the CMS they use (Drupal?) but it needs some revamping.
2) same complaint about the SW that manages their forum. It wouldn't be difficult to find something better
3) the documentation is too fragmented, inorganic and lacks the big picture
4) the transition to v 0.9 is been done in the wrong way. First of all, the code based on v 0.4 doesn’t work any more, and you have to make a real porting to use v 0.9. They wrote a porting guide to help it, but after reading it I had no clue on what to do. They decided that the 0.4 widgets did too much, so 0.9 widgets are a stripped down version of what they had before. What the poor guy that invested on v0.4 has too do now that the bloated features on which he based its design have been removed? It is true that they say to have plans to add enhanced widgets that bring back the removed features, but I have preferred if they stated somewhere that this beta is feature incomplete and advice people not to try a port right now.
I understand this is an Open Source project, and as such people work on it in their spare time which may be very little, but as the previous post reminded, documentation is the main driving force.
CLA = Contributer's License Agreement
The CLA is what you send in so you can submit code and documentation to the project, details here: http://dojotoolkit.org/developer/GettingInvolved
I understand and empathize with your points. My big thing is documentation. I don't believe in retrospective documentation, if it's not done with the code, it's done too late in my book. But I think many of the committers were in "get it done" mode without worrying about that, and have a different definition of "done", which is their perogative. But again, the main project leads will be focussing on documentation before the first "real" release, 1.0.
--
T.J. Crowder
tj at crowder software dot com
Some replies.
What I am complaining about is that its developers seem to do their best to discurage people from using it.
I think that's a personal point of view, but I'll answer your points inline.
1) this site is slow and poorly designed. It might be the CMS they use (Drupal?) but it needs some revamping.
2) same complaint about the SW that manages their forum. It wouldn't be difficult to find something better
The site is slow partially because it's Drupal but mostly because it is running on a Virtual Machine with not a whole hell of a lot of support. Hosting costs money, and the Dojo Foundation doesn't really have a lot of it. Same thing with the forums: it's a Drupal module.
We did not bother trying to spend a lot of time with a site redesign yet, because frankly no one on the team had the time to do it. I don't know if you've ever worked on an open source project or not, but the fact of the matter is that almost all of us are volunteers, and those who are not are given very specific tasks (*not* determined by the committer team) to do.
There will be a site redesign to coincide with the 1.0 launch.
3) the documentation is too fragmented, inorganic and lacks the big picture
Documentation is and has always been an issue. Simply put: most of us are terrible writers, and the amount of fluctuation between 0.4 and 0.9 essentially forced us to wait until 0.9 is relatively stable before anyone can put some serious effort into documentation that is understandable and usable. We're pretty much at that point right now, and there are some documentation efforts under way.
4) the transition to v 0.9 is been done in the wrong way...
This particular paragraph has a lot of different points in it, so I'll try to address them one at a time.
WRT breaking backwards compatibility with 0.4, we felt that we had no choice. The bottom line is that we made some major mistakes in terms of "being permissive" WRT code being committed, and 0.4 is basically the pinnacle of a lot of different ideas being thrown into a melting pot without really considering other salient points, such as purpose and stability. Nowhere throughout 0.4 was this more apparent than the widget system--and the end result was that it was very slow and caused the commonly known "browser-freeze" onload.
There was no way to address that point (and others) without breaking backwards compatibility.
First of all, the code based on v 0.4 doesn’t work any more, and you have to make a real porting to use v 0.9. They wrote a porting guide to help it, but after reading it I had no clue on what to do.
Any salient suggestions on what you might think would give you that clue, please feel free to say so here. We're pretty open to that kind of suggestion; sometimes it's hard to separate ourselves from being very familar with the codebase, and not seeing what would be helpful to others.
They decided that the 0.4 widgets did too much, so 0.9 widgets are a stripped down version of what they had before. What the poor guy that invested on v0.4 has too do now that the bloated features on which he based its design have been removed?
That's not actually true. It's not the 0.4 widgets "did too much", it's that they lacked a real sense of point and purpose--and so it became a "we're going to commit whatever cool thingy we think should be there", as opposed to "this is going to be a stable and definitive UI development kit, with a common control set that most developers would recognize out of the box".
The endgame for Dijit is to be a very strong and stable--meaning "not changing much"--set of widgets that one can really rely on for RAD. That means that once 1.0 is out, it's not going to change. 0.4 was a snapshot of rapid change and development, and that made it hard for people to use. The only reason *why* it's easier now is because we stopped the 0.4 branch to move into the future, which means that 0.4 is actually pretty stable now (since it's not being actively developed anymore).
My suggestion is that if you were relying on bloated features, then I'd learn how Dijit is working and start moving towards streamlined stuff. It really is a pleasure to work with; it just takes a little time to get used to.
It is true that they say to have plans to add enhanced widgets that bring back the removed features, but I have preferred if they stated somewhere that this beta is feature incomplete and advice people not to try a port right now.
Which enhanced widgets are you talking about? The only things we've said are:
1. With the exception of the Grid, all of the widgets that will be a part of Dijit are there in some shape or form.
2. We're allowing some widgets to be ported to DojoX, but we consider those to be a "labor of love", and they should be using the Dijit infrastructure.
Or did you mean something else?
Some explanations
Thanks ttrenka for taking the time to answer.
I' like to make some comments on what you said. But first of all, I apologize for my rude statements. They are the fruit of much frustration trying a port to v0.9.
1) Hosting costs money, and the Dojo Foundation doesn't really have a lot of it
I was under the impression that the Dojo Foundation was not short of resources. This is what I gathered after having read that your sponsors and members include IBM, Sun, AOL, etc. These are names that not every Open Source project can boast. Moreover Dojo gets a lot of good reviews and I might say it is often the first Ajax toolkit to be quoted. So, the importance of Dojo is not well rendered by the shape of its web site. And marketing is often more important than quality (Microsoft rules). Besides hosting does not cost that much.
2) Documentation is and has always been an issue
Glad too see you didn't add "and always will be". :-). But really, this is an important issue. If you don't have the resources to write a programmer manual, at least write the internal design of Dojo, so that we might find easier to approach the source code. Besides this would also possibly attract more contributors.
3) There was no way to address that point (and others) without breaking backwards compatibility.
Right, I agree. I wasn't really complaining about breaking old code. I was complaining about lack of documentation, advice, and deleted features for which I could not find an evident way to replace them.
4) Any salient suggestions on what you might think would give you that clue
Here is one (and I am far from being the first to point it out): the executeScripts property has been deleted from ContentPane. The application I was trying to port is made by html fragments that are loaded into a ContentPane and they contain their own scripts. How should I handle this situation now? The porting guide only says
"But <script type="dojo/method">...</script>available in dojo.parser are supported" which is something pretty obscure to me.5) Which enhanced widgets are you talking about?
For instance in the migration guide, in the page for the ContentPane it is said: "There are plans to add a Dojox ContentPane with more the more advanced features.". The same is said in posts in the forum and in the bug tracking.
One last consideration about Open Source software in general. Open Source is not (should not be) synonym of poor quality, poor consideration for the users, lack of documentation, unprofessional attitude, etc. and I am not talking of Dojo here.
When someone publishes, advertises, encourages the adoption of some software, Open Source or not, it starts to have responsabilities toward the users (or customers) that invest time and money on it. The fact that Open Source developers are volunteer, not paid, etc. is no excuse to compromise on quality.
If I got it all wrong because Dojo is not 1.0 meaning that it is not yet ready for prime time, please say it clearly in you front page: "Don't use Dojo in production, until we say so"
Claraifications
1.) Hosting. We sustain upwards of 100K downloads for every release, run mailing lists, SVN, this drupal instance, development and build infrastructure, and bug tracking databases from our systems. Taken alone, each of these doesn't contribute much overhead, but taken together they really start to slam our poor systems. We're lining up better hardware, but we've already outgrown several systems and are bursting at the seams in our current environment. Hosting may not be expensive, but getting continuity and quality isn't free.
2.) Dojo's source is rather readable today. We've worked hard to make sure everything conforms to the style guide and is relatively straightforward. There's some voodoo (dojo.query, the style code), but things that aren't "user serviceable" are the exception. Please let us know if there are modules you're having trouble reading.
3.) Some features haven't been replaced and some won't be. Keep an eye on the porting guide for those details and please comment on porting guide pages where you find things missing.
4.) executeScripts was a bug. It was poorly designed, poorly implemented, and having it in the content page widget itself was probably also a mistake. In 0.9 you can just run a one-liner to handle much of it:
dojo.query("script", node).forEach(function(n){ eval(n.innerHTML); });5.) content pane is a somewhat thorny example, but like a lot of other things, many of the feature removals were intentional in order to deliver better, faster, more-focused components.
As for posturing about quality, I'd really like to suggest that you spend more time filing bugs and patches and less time impugning the hard work of the contributors. It's not going to win you any friends and certainly won't get your bugs fixed faster.
Readability
Alex - Absolutely agree, especially with your last point, which I would summarize as "engage and contribute in preference to complaining."
One comment:
"Dojo's source is rather readable today."
Coming to Dojo 0.9 fresh a couple of weeks back, I'm afraid I have to say that there still seems to be a fair bit of room for improvement on this front. Obviously there's a lot of variability and some parts are great, but in some places there still seems to be the belief that spaces and explicitness (and thorough comments) are taboo. I suspect a lot of that is legacy stuff and donated code from before ShrinkSafe, etc., and so it was written from the perspective of every unnecessary character written was an unnecessary character downloaded, but there's still a fair bit of it there.
All - IMHO, the thing with a toolkit like Dojo is that we need to be exceptional with clarity in the code and documentation in order to encourage participation. Not just good, exceptional. Ubergeek density, stringing together assignments and tests and conditional function calls all in one return statement and if some l053r can't get the rules of precedence right the first time, tough -- well, it tends to put off the more casual developer. It's worth breaking the statement up into its component parts -- or if there's a real performance aspect to some of the reevaluations being avoided, then thorough inline commenting explaining the what and why are worthwhile, again from the point of view of encouraging participation.
fermo111 - Note I said "...we need to be exceptional..." Not "you", "we". Okay, I'm not a committer on anything, but I can still file bug reports and patches for things I think should be clearer. I've only been around here a couple of weeks and I've been getting my footing before doing too much of that, but if I've figured out a public API that's not as clearly documented as it could be, I have the power to change that. So do you (well, you will once you send in your CLA). Okay, we're not going to do it every time, we're all busy people, but it's an "us" thing.
</soapbox>
--
T.J. Crowder
tj at crowder software dot com
Clarification on Hosting
Dojo is *USED* by those companies, and those companies provide labor/employees/assistance (not in the form of monetary donations) ie. AOL hosting Dojo on its CDN server, IBM providing technical writers and such. All Dojo money comes donations from users that I'm aware of. As for cheap hosting... Dojo would need VPS or Dedicated server due to the high load of the server (web, mysql, trac, various other processes) and we would need Ops support to manage the servers, keeping them up-to-date, up and running, and secured.
-Karl
If IBM is providing the
If IBM is providing the technical writers I suggest you remove their logo from this site. They don't deserve it.
If all AOL can give you is hosting in the form of a slow virtual server, I suggest you remove their logo as well. They don't deserve it. A powerful dedicated server is today something that is very cheap. Your advertisement of AOL is worth more than that.
I suggest you stopping coding and rethink the way you propose yourselves. And ask real money from your sponsors and partners. Come on guys, the time of proofing the concept is over.
Ok, so its attack anything
Ok, so its attack anything Dojo day today. I see that.
IBM rotates out 1 WRITER to help with the Dojo Book on the left menu... they also have developers on the committer team as well. AOL is the same way, they provide developers, and hosting, along with other things that arent visible (AOL and IBM have each hosted Dojo events in their offices free of charge to the Dojo Foundation). We aren't advertising for AOL, we are sharing our appreciation and acknowledging their contributions. It's an open source project, they don't have to provide anything, but they see something good here so they do.
To say any one of our partners/contributors doesn't deserve to be mentioned is a slap in the face of any Open Source project. If you have recommendations to help improve Dojo, we are all ears. But complaining with no constructive critism is just noise to most people. And insulting/degrading the names of others makes the noise level that much higher.
Reading your initial post, your list of complains, obviously you didnt spend much time with 0.9 since it is clearly faster than 0.4 in every way. If you have complaints about Dojo, keep those complaints about the Dojo Foundation/Toolkit not about the contributing companies/groups/people.
Lastly, if your feelings are that strong about Dojo, maybe you should file a Contributor's License Agreement and put your 2 cents into the project in a more positive way.
-Karl
That's a little strong.
My reaction was similar to yours but at the same time he makes some valid points. Not all, but some. It doesn't help that the hosting situation is unclear as well...
You misunderstand.
IBM and Sun have both contributed employee time towards book writing, and IBM (through its employees) are driving the development and requirements for Dijit. There's a lot more under the covers going on than you might think, and frankly we aren't going to advertise anything like that (unless we're asked to)--and we definitely won't take the advice of fairly anonymous voices in terms for what we show on the site or not. In that respect, having IBM or AOL host conferences and contribute a LOT of stuff says a lot more than commentary.
AOL does not *host* the Dojo site. They host the CDN code on their servers, so that you can use Dojo in an xdomain fashion. The current hosting for this website is via a virtual machine graciously donated by SitePen, Inc. In fact, the majority of the funding for Dojo is essentially coming directly out of SitePen's pocket, and to have that money available many of us have to concentrate our efforts on other things.
If you'd like to donate money and server ops services, we'd be glad to talk to you :)
As far as this statement goes:
I suggest you stopping coding and rethink the way you propose yourselves. And ask real money from your sponsors and partners. Come on guys, the time of proofing the concept is over.
Really? Stop coding? Rethink the way we propose ourselves? Why, because you're frustrated? Don't you think we *do* ask for real money? Do you think that we have dedicated people that all they do is Dojo?
As far as I'm aware of, there's one--ONE--person in the entire world that is getting paid to exclusively work on Dojo without any other considerations, and he's about as busy as it gets. I don't know what you are assuming Open Source is, but one thing it is definitely NOT is a well-funded venture. Particularly in our case, it is a labor of love by a large cadre of volunteers who dedicate a lot of their extra time to creating the kit. Though there are many of us that do wish it was a well-funded venture; more than one of us would love to be able to work on this full-time, with a real marketing, documentation and PR team to help push it well.
List your frustrations, and we'll listen. Make reasonable suggestions, and if they work with what we're doing we'll incorporate and give you credit for the idea. Be critical without having any clue what we're doing and trying to do, and you'll find that no one will listen to you anymore.
Be constructive.
Ok, I'll try to be
Ok, I'll try to be constructive.
1) Documentation
I like the online documentation on the PHP site. Good search capabilities, a cookbook approach (they call it User Contributed Notes), lots of examples, unobtrusive posting facility. All the docs should be downloadable in printed form (PDF) even the docs that are under construction. For instance you could generate it automatically from the online pages. Downloadable docs are even more important for slow sites. The pages in the Dojo book are too short. You are forced to switch from one page to another too often and a page of few lines can load in 10-15 second. One easy remedy would be to group articles to have longer pages that are easier to read.
As for the contents of the documentation, I hope that the writers will add a one on the Dojo internals, to guide us to the reading of the dojo source code (and possibly to write it too).
The API docs are more or less a replica of the source code tree. Every class should have examples on its use. Just adding to the class doc code taken from the tests would be nice. Here is the place where the site needs to be speeded most. Loading the API tree is a way tooooo slow. The suggestion made above about downloadable docs is even more important. I suggest using some hypertextual format like CHM. There are tools to generate a CHM from the code comments.
2) Site navigation
This Wiki/CMS approach does not work. Every page has a "Rate this" button which is pretty unuseful, and a "Post new comment" which is annoying to see and more to print. Adding user content should be allowed only where it make sense, to add user contributed code or documentation. The place for asking question and making comments is the forum. Otherwise information becomes scattered all over the place and is difficult to find. There are pages with one line of content and 2 screens of CMS stuff.
Get rid of some obscure menus like "Create content" on the left.
3) Forum. May I suggest using some better forum support SW like phpbb or something like that?
4) What about printing the FAQ as 1 document?
5) Demos
The first time I came across this site there where few demos that demonstrated what Dojo could do. And I was convinced. I think is I were to hit this site today for the first time I would be very less impressed. What about writing some complex application that would show all the Dojo feature? For instance developing the present Mail demo to a full featured mail application? It would serve the purpose to attract more users and as a "best practice" example for developers. But first of all, get rid of the Tiger, Butterfly, Lion etc, demos. They are undoubtedly nice but I find them very misleading about Dojo features.
6) Hosting
What about a powerful dedicated server with a 100Mbit bandwidth and few TB of disk space at $70 a month? This is the current price around here.
More to come...
Keep them coming.
Don't know how feasible some of the suggestions are but definitely keep them coming. And where is "around here"? I don't think we were able to find a price like that.
One thing to keep in mind: one of the requirements for hosting is that *someone* from the Dojo team with some ops experience needs to be able to have physical access to the server. I think the investigations for hosting were centered around San Francisco but I personally have no part in that whole process...
Physical Access?
Physical access, really? I've run sites for years without ever having to step into a data center. SSH and remote reboot/recovery have been plenty good enough...
This isn't an idle question: If physical access isn't a requirement, I may be able to sponsor a full dedicated server. Would a Celeron 1.7GHz 512MB 80GB 900GB/month transfer work?
--
T.J. Crowder
tj at crowder software dot com
I don't know...
...but I think I'm going to be forwarding this link to some relevant parties :)
Yes, physical access. IIRC, there's been issues before where physical access was needed. Don't ask me, I'm not that involved with this part.
Physical access
There were probably in excess of 5 times in a rather short time that required a physical reboot since the server wasn't responding to anything coming across the internet (or wasn't even accessible) 24hr on site tech support would suffice for this I believe... but that again jumps the cost of hosting...
-Karl
Ouch
That sounds unpleasant. :-) But rare, I would think.
The place I'm thinking of is in the U.S., comes highly recommended, and has remote tools, both to reboot the server when it's not responding to SSH, and to repair the file system, etc. They do have 24/7 techs. Baseline support is included and includes the tools I was talking about, any hardware problem, any network problem, reloading the OS from scratch, that sort of thing. Per-incident chargeable items are troubleshooting installed software like MySQL, Apache, etc., but I'm guessing whoever runs this place is able to handle that themselves. :-)
Drop me a note if you want to pick this up offline. The offer's there if it would help. If it wouldn't, no worries.
--
T.J. Crowder
tj at crowder software dot com
Hey TJ, Thanks for the
Hey TJ,
Thanks for the generous offer. Unfortunately, we've been slamming a box with a lot more horsepower than that to the wall for months now. Until we've got separate DB and web tier boxen, I don't think we're going to be able to really improve site responsiveness.
No worries, Alex
I thought I understood from Tom Trenka further up in the thread that the whole thing was running in a VM and that that was a main contributor to speed issues. It did seem a bit surprising... :-)
Good luck with lining up those new resources. The site gets a bit slow sometimes, but nothing like unusable.
--
T.J. Crowder
tj at crowder software dot com
It is.
...it's just seriously beefed up (2 dedicated CPUs, 4GB RAM, etc. etc.) The machine not only runs the web site, but pretty everything else Dojo-related, including the automated nightly build system.
Very cool
You know, I was thinking VM like VPS and that kind of thing, usually small and crippled, not VM in the other sense -- odd, given that I keep recommending VMs in the other sense to clients... ;-)
--
T.J. Crowder
tj at crowder software dot com
And where is "around
And where is "around here"?
Somewhere in Europe. If the physical access requirement will be dropped, I can be more specific (I don't have the info here right now).
Back to the original topic
About my 2nd point in the first post: it doesn't seem to load faster. I said, it doesn't seem I didn't say it is not faster in absolute terms. I have timed the Mail demo in Dojo 0.4 and the same demo ported to Dojo 0.9. Here are the results:
0.4)
- time to load from local server: about 4.5sec
- bytes transferred: 406K
0.9)
- time to load from local server: about 3sec
- bytes transferred: 332K
Now to that figures you must add the internet delay which could give:
For a 40KB connection (which is what I get at my office during work hours):
0.4) 10sec
0.9) 8sec
For a 150KB connection:
0.4) 2.7sec
0.9) 2.2sec
In conclusion if a user has to wait for 10 seconds instead of 13 seconds, the impression that he receives is only slightly better. Of course I haven't done much testing. Just taking one case to see how it fared.
Links?
Can you supply links for what you are comparing these on? Currently the mail demo isnt ported to 0.9 that I'm aware of...
New changes as well... after todays IRC meeting, we revisited the forum layout and have reduced the # of forums again... hopefully eliminating more problems there (and reducing scrolling a bit).
-Karl
Mail demo
I have simply taken the 0.4 demo and replaced the widget types with the new one. The Dojo bootstrap part look like this:
dojo.require("dijit.layout.ContentPane");
dojo.require("dijit.Tree");
dojo.require("dijit.form.Button");
dojo.require("dijit.form.Checkbox");
dojo.require("dojo.data.JsonItemStore");
dojo.require("dijit.layout.SplitContainer");
dojo.require("dijit.layout.TabContainer");
dojo.require("dijit.Dialog");
dojo.require("dojo.parser"); // scan page for widgets and instantiate them
Cool! If you've done the work...
...how 'bout sharing? If you haven't already sent in your CLA, this would be a great time to do that. Then you can create a trac ticket requesting that the Mail demo be restored to the Demos area, and attach your ported copy to the ticket. (The CLA just lets the Foundation use the code you contribute, without creating IP problems. The Apache and Mozilla Foundations do something similar.)
--
T.J. Crowder
tj at crowder software dot com
dijit-all.js
Sounds like a good first whack at it, although to go apples-to-apples on this, you'd want to be either pulling in those widgets from a build or use the dijit-all.js file which has been created for things like this. It's big, but it will be a single XHR hit for the code (which I'm guessing is your major latency contributor here). The version of dijit-all.js in Beta is 60K on the wire (gzipped). You can try pulling it out of AOL's CDN build to get a feel for how a "deployment" version of 0.9 will really feel once you subtract all the extra HTTP overhead.
Tried this...
Didnt work at all... partially loads... but not useful...
I started porting this yesterday myself, I got this far currently: http://dojo.xnet.org/dijit/demos/apps/Mail.html
working on the tree stuff today.
-Karl
Ok
Give me the time to polish it a little bit and then I'll post it
You can try it
at this address: http://lucapriorelli.no-ip.com/dojo/demos/widget/Mail.html.
Beware that there are still some issues that I am trying to solve: the event model of the Tree widget and the reason why the dialog does not work (Options button)
You can try it (update)
at this address: http://lucapriorelli.no-ip.com/dojo/demos/widget/Mail.html.
Beware that there are still some issues that I am trying to solve: the event model of the Tree widget and the reason why the dialog does not work (Options button)
UPDATE
I have loaded in the same site also the v.0.4 of the demo to help benchmarking.
http://lucapriorelli.no-ip.com/dojo-0.4/demos/widget/Mail.html
Another thing that I am exploring is how to add icons to the tree nodes
BTW: Sorry for the double post
No worries on the double post.
Quick q: how long did it take you to get to that point?
Don't know
I worked on it at intervals beginning sometime in the middle of this discussion. Maybe 3 hours.
Broken links
404 on both of them.... I ported everything but the tree in about an hour yesterday... I've hacked at countries.json to get a new one for dijit.Tree but it never works when I modify it :(
Also the alerts werent working and I hadnt attempted the dialog yet, but I had new message and all that working.
-Karl
Not for me
You mean the links fermo111 posted? They work for me. *slowly*, but they work...
--
T.J. Crowder
tj at crowder software dot com
404
I have a dynamic IP and a 256Kbit/sec line upstream and the refresh rate for my IP is 5 minutes. Since my provider rotates IPs frequently, you may have tried in one of those moments. Sorry.
On a second thought this cannot be the reason if you got a 404. Stange.
fermo, you have email
I set you up an acct on my website so you can upload your port there... more reliable speed comparsion than using a home network, and I can see it for sure then ;)
-Karl