Firstly, apologies for the long post.
My post relates to the tree widget but does not really belong in the dijit forum as my concerns are with the dojo project in general.
Secondly, this is not meant as a rant, but rather as a 'Voice of the customer' experience with porting to 0.9; I raise concerns because I use dojo everyday and I need to see dojo succeed. Insert whatever "thanks for all the hard work but..." comment you like here so that nobody's feelings get hurt :-)
On http://dojotoolkit.org/book/dojo-porting-guide-0-4-x-0-9/widgets/tree
the following comment concerns me:
"Tree has essentially been rewritten for Dijit. It only supports a small subset of the functionality in the original TreeV3 code."
Whilst I think that the majority of 0.9 has been undertaken with noble aims (speed, size, common api, a11y...) it would appear that some refactoring has been undertaken without due consideration as to how 0.4 dojo was used by the community.
Did I miss a meeting and there was widespread consultation with the users of dojo, or was this a unilateral decision by the dojo commiters ;-)
Thinking about 'web applications' as single page feature rich RIA buzzword compliant things, I bet that the most commonly used UI components are:
tabs
tree
split panes
form elements
layouts
Whilst I can see definite improvements in all of these widgets in 0.9, the exception would seem to be the tree, and this is borne out in the comments I mention above.
It seems a deliberate decision to 'cobble' the tree in 0.9, however how are users of dojo meant to cope with this if they have invested large amounts of time and effort in to tree functionality that has be deemed to be unwanted in 0.9?
To give a specific example:
My question is, how do you interact with the tree once it has been created if using json data since the FileItemWriteStore's onNew() function is not linked to by the Tree for updates?
I personally like the clean separation of concerns that basing the tree on dojo.data has brought about. However, given the large number of 'How do I' forum postings about the tree, changing the act of adding a child tree node from:
0.4
var myNewChildNode = { widgetName:'dojo:TreeNodeV3', widgetId: "Child_" + child.name, nodeDocType: "Child", title: child.name, isFolder: true };
myTreeController.createChild( parentNode, 0, myNewChildNode );to the following in 0.9:
var jsonData = { identifier: "name", items: [], label: "name" }; //items are unique by name, displayed as name
var root = { name: 'Parent', type: 'normal' };
root.children = [ {name: "child1", type: "normal"} ];
jsonData.items.push( root );
var jsonstore = new dojo.data.JsonItemStore( { data: jsonData } ); //create store from jsonData
var params = { id: "myTree", store: jsonstore, typeAttr: "type", query: { type: "normal" } };
this.myTree = new dijit.Tree( params, this.treeContainerNode ); //create Tree
with no obvious way to subsequently interact with the tree is a recipe for user frustration, especially when the scant examples of 0.9 usage all use JsonItemStore.
So the tree is effectively static. Are we meant to re-create the tree every time we want to alter the tree content, because I can find no obvious way of rebinding a tree to a new store because this binding only seems to happen at creation with the following sequence of events:
Create tree
Post Create creates a DataController
DataController does a fetch on the tree store using the data query passed in the tree create
DataController calls Tree.setChildren to turn store items into tree nodes
If there is an easy way to interact with the tree using FileItemWriteStore then my apologies and I would be grateful for any help.
Well-intended-mini-rant
Given that every other tree widget from VB to C++ to Java has content altering semantics, can someone explain why these simple addNode, removeNode functions have been left out of the tree specifications for 0.9?
A pure separation of concerns and the use of callbacks when querying stores for items is probably technically the best way to proceed - however if your end product is a tree control that is only usable by a JS genius because it lacks the obvious features of less architecturally pure tree controls, then dojo's aim to have widespread adoption will be (however slightly) curtailed.
History has shown that it is not usually the best technology that becomes dominant, but rather the most accessible.
Dojo has always suffered from a lack of documentation, but this was accepted by most users due to the helpfulness of dojo people in the forum and the functionality offered by the toolkit.
0.9 is a big change and big thanks must go to the hard work of many people who made it happen. However, as a 'long time' dojo user (since 0.2) I fear that 0.9 may be a step to far as you are asking everyone to re-write existing applications with little or no doco and examples and with large parts of functionality removed.
I love dojo and want to see it rule the world. My team has devoted alot of time to using dojo, but as of right now, a full port to ext is looking like the best way to progress in the future. The reasons for this are that other JS libs build on their existing functionality, whereas dojo has undergone changes that have removed functionality, without even a thought to how existing users would cope or any real consultation or suggested workarounds.
Whilst we (users) should allow free reign to 'how' dojo works, I think that there should be some consultation on 'what' dojo offers, not just in the future, but more importantly, what will cease to be supported in the future, if only to give the community time to prepare.
I could of course just stop whining and commit my wanted enhancements to dojox, but this invalidates the commercial decision we took in using dojo over a year ago.
I agree
I can add a few considerations.
Usually during the life of a software project, features are *added* not removed. This is not necessary a good thing because new releases tend also to be slower. But when at some point you have provided a functionality and people has come to rely on it, and developed code that use it, just removing it is not an option.
Refactoring does not mean deleting functionalities, it means reorganizing code so that it meets better criteria: make it more readable, more maintainable, easier to debug, etc. The explanation most used by v0.9 supporters, is that the new version will improve speed. Well, if you delete *all* the code and reduce it to 1 line, the speed gain would be huge. It is not just a joke, its a paraphrase of a story told in the book "The Psychology of Computer Programming" by Gerald M. Weinberg about a consultant who was called to solve a problem that a programming team was having. He solved it but the project leader of the team got annoyed by the outsider's success, and during a meeting argued that his program was much faster. The consultant replied that, yes it was faster, but had just a little problem: it didn't work. In other words, if you want to make your code faster, you don't delete, more or less arbitrarily, pieces of it, but restructure it in a better fashion. For instance you can provide classes with basic functionalities and derived classes with more advanced functionalities that maintain all the features of the previous version. You can even change everything inside, but do not touch, or touch very little, the interface. Or you may add a new interface to the old one. You simply don't say: this widget will not be ported. And the list is pretty long:
AnimatedPng: not ported
SvgButton: not ported
Clock: not ported
HslColorPicker: not ported
ComboBox: stripped down?
ContentPane: stripped down
DebugConsole: not ported
Dialog: stripped down?
Editor2, Editor2Toolbar, RichText: don't know (documentation is missing)
FilteringTable: maybe in the future
FisheyeList: not ported
FloatingPane: not ported
TaskBar: not ported
Form, Repeater: maybe a stripped version in the future
GoogleMap, YahooMap: not ported
MonthlyCalendar: not ported
ProgressBar: stripped down?
RadioGroup: not ported
ResizeHandle (and resizable panes in general) are not supported in Dijit.
Slider: stripped down
SpanSelect: not ported
Tooltip: stripped down
Tree: stripped down
Wizard: not ported
You have at least to provide a sound migration path. If you delete a method or a property, say at least how to obtain the same result with the new API. If you delete a class is either because *nobody* uses it, or because there is a better way to do the same thing with the new API. Just tell us.
Don't forget one thing: people have, me included, chosen Dojo because it had functionalities that other similar toolkits did not have. But Dojo is not the only one: there is YUI, Rialto, qooxdoo, Ext IS, just to name a few, and I must say that Dojo 0.9 does not look so favourably in comparison to them right now. It did before, not now. Well, to be certain I have started a little project of mine: I am writing a somewhat complex application in all of these widgets and see how they compare. I don't know if I'll have the time to do it but today it seemed a good idea. :)
hmm
I don't want to go into a long winded debate about dojo functionality myself, but i will address some of your concerns, or at least stab at the list you made of 0.4 widgets: (these are just my opinions, btw, nothing difinitive here) but nothing is tagged as "absolutely won't be ported" ... stuff may "absolutely be useless in dijit", but dojox will provide a home to most any well-thought-out project you can imagine.
AnimatedPng: not ported - seems like a toy project? it's almost as much work to create the image with it's offsets as it is to make a layered animated gif ... is it useful? did anyone actually use it? you are the first to cry 'foul' over this one ;)
SvgButton: not ported - you can connect an onclick to about anything, including an svg surface or path. do we _need_ (to support) a whole button class for svg? what about vml? dojox.gfx is being worked on, so by definition it's not stable enough to be used by dijit for anything.
Clock: not ported - more of a fun app than anything 'useful' ... could be ported to dojox.widget without problem, but again, i believe it was svg-based ...
HslColorPicker: not ported - not sure.
ComboBox: stripped down? - ContentPane: stripped down - faster/more fault tolerant. the only thing really pulled from it was executeScripts, and the example alex/I gave you to remedy that works for me. took 5 minutes to do:
executeScripts: true,
postCreate: function() {
if (this.parseOnload) { this.parseOnLoad = false; this._parseOnLoad = true; }
if (this.executeScripts) {
dojo.connect(this,"onLoad",this,"_executeScripts");
}
},
_executeScripts: function() {
dojo.query("script",this.domNode).forEach(function(n){
eval(n.innerHTML);
},this);
if (this._parseOnLoad) { dojo.parser.parse(this.domNode); }
}
});
DebugConsole: not ported - though it would be fun to have a debug class available, its un-necessary. firebug lite works on all browsers, and firebug is the most robust solution to debugging available [imho] .. it is in a hide-able console in your status bar. what more could you want? :)
Dialog: stripped down? - if you mean blocking features and colored backgrounds, i agree with you. (hehe, i ported it, as-is from 0.4 and fixed some bugs along the way, and it was chopped down to it's current state, but it prompted me to make dojox.layout.FLoatingPane) But on the other hand, it just "works" now, and you are free to use [the soon frozen-api] to extend to your heart's content ... minimal understanding of widgets is required to successfully extend a widget. (see executeScripts example above)
Editor2, Editor2Toolbar, RichText: don't know (documentation is missing) - RichText powers the Editor. Toolbar is a cleaned up version of the old one. Easier to use, easier to make custom controls, etc, etc ...
FilteringTable: maybe in the future - definately in the future, probably named 'Grid' ...
FisheyeList: not ported - wants a home in dojox, for sure. it was a great little bug-ridden widget that had serious performance issues on linux/ff ..
FloatingPane: not ported - dojox.layout.FloatingPane (experimental, but works, and would love some commuity attention to get it working up to par ... )
TaskBar: not ported - will be part of what i call a ui class ... to go with FloatingPane, Pager, Desktop, and a few other new -os-like widgets i have planned in my mind ...
Form, Repeater: maybe a stripped version in the future - not sure where you get that?
GoogleMap, YahooMap: not ported - maybe it will be i think.
MonthlyCalendar: not ported - again, more of an App than a widget.
ProgressBar: stripped down? howso?
RadioGroup: not ported - as in the tab-container-wannabe? or am i missing something, and RadioGroup did stuff TabContainer didn't, or can't?
ResizeHandle (and resizable panes in general) are not supported in Dijit. - every layout based dijit has a .resize({ x: y: }) method. attach a dojox.layout.ResizeHandle, and it just calls that for you, or just attach it to a normal node and resize from there. dojox resize handle works better than the old one (yes, chopped of some code) and added features (adding back less than was chopped) like virtualsizing/activesizing, animated sizeTo, limit size to X or Y or XY ... etc.
Slider: stripped down - muuuuch prettier imho. i do miss the XY free-slider, but the current one in dijit is muuuuuch more robust and pretty.
SpanSelect: not ported - not sure what SpanSelect did before?
Tooltip: stripped down - again, how? aesthetically it is better, the fact you can customize every aspect from CSS classes is helpful, and all the things in considering screen-readers and high-contrast mode have been taking into account.
Tree: stripped down - and getting new code frequently. but yes, it needs some love.
Wizard: not ported - yet. when presentation class is complete, a wizard could easily be derrived from that.
Additionally, we are trying to "just tell you" via the porting guide, the book, on IRC (have you been there to ask anyone? #dojo irc.freenode.org/net? ) enhancement requests can be put into http://trac.dojotoolkit.org (which is where bug reports go too, btw) ... and most importantly, before anyone screams "documentation" i will mention again that FULL documentation of dojo/dijit is REQUIRED before 1.0 goes out the door. the codebase you are working with says "beta" atm, working towards a 0.9production release, at which point the API will freeze, and only new methods/code will be considered, and Dojo will resume backwards compatibility.
And Bill is actually fairly accommodating about putting old stuff back in Dijit. It goes smoother when you make a patch (and sign a CLA) and submit it with you enhancement request. There are several places in the porting guide where he says "removed, but will put back if lots of people want it" ... The point of the chopping block w/r/t dijit was to eliminate redundancy (lots of widgets re-invented wheels to do what they want, not trying to step on other namespaces, so now everything has a unified API, and builds upon that) and to provide a unified API to build upon.
... It _IS_ faster, when you consider the comparable sizes and response speeds from a 0.4 build to a 0.9 build ... even uncompressed, the limited number of xhr calls makes testing/debugging apps a whole lot faster. (no css for each widget, lot of templates are already inline, etc)
a couple important things to remember a) Dojo is free b) Dojo is community supported. If you feel dojo is lacking somewhere, help fix it, or at least point it out. c) the devs are volunteers, limited time and resources are selflessly dumped into make the toolkit from people all across the globe. d) no one is profiting from doing this, unless you consider the licensing of dojo allows you to use it in commercial apps for free.
please, sign a CLA and jump in helping form this beta release into a solid production release, rather than, will all due respect, complaining about what it is not.
Don't get me wrong
Wow! I didn't want to start another flame :-)
Don't get me wrong. That was only a list of widgets that have deleted or simplified as by documentation. I did not want to imply that all of them should be kept in the core API. I agree with you that many of them are either applets or have better replacement and must not belong to the API. In fact I suggested two things: 1) that the reason why a widget was removed or simplified should be given in the manual (just saying "it will not be ported" seems a little to crude) and 2) that an explanation on how to have the same funcionalities in the new Dojo should be given as well. More or less what you have done in your previous post.
For the time being, my practical concerns are with the tree event model (as it was pointed out by the first post) and the executeScripts attribute (I have still to test if your solution works in all the cases that I have). Maybe all the rest will flow seamlessly from here ahead, but at first sight the list of deleted stuff looks a little scary.
i wasn't flaming :)
i was just addressing your list of widgets.
it just that it's "beta" right now, and these issues need to be addressed. I agree tree is lacking, but I don't personally use it, nor am I familiar with it to the point with which i could provide any alternatives.
as an aside, i did the 'parseOnLoad' borking in my example because if you dojo.require() something in a script tag in a remote ContentPane, it tries to parse the body first, then execute the scripts. that workaround parses if you wanted to parse, after it loads stuff in via script tags.
It also seems to break in IE6 for some reason (i suspect async dojo.require() and IE not being fast enough to pull in a bunch of stuff before the code get's executed)
Your script
I made a little test:
Caller:
fragWithScript.html:
Hallo
fragWithScript.js:
alert(1) and alert(3) work. alert(2) doesn't.
UPDATE
and also the inline script is executed in the global context
fixing the third case would
fixing the third case would be a simple matter of:
function(n){
// not sure if n.src is right way, but you get the point
if (n.src) { eval(n.srcContentsFromXhrSomehow); }
else { eval(n.innerHTML); }
}
it was only designed to quickly parse the innerHTML of script tags. scripts with src attribs would have to be called into some varaible somehow and then eval()'d ...
I have tried this
_executeScripts: function() { dojo.query ("script",this.domNode).forEach(function(n) { var self = this; if (n.getAttribute ("src")) { dojo.xhrGet ({ url: n.getAttribute ("src"), sync: true, handle: function (response, ioArgs) { if (response instanceof Error) { console.error (response); } else { self.scr = response; } } }); } else self.scr = n.innerHTML; eval (self.scr); },this); if (this._parseOnLoad) { dojo.parser.parse(this.domNode); } }but I think the whole old _executeScripts() could be used, just changing the little bit that is needed to make it run on 0.9
Dojox.ContentPane
You guys realize that we are planning to support the old ContentPane functionality (including executeScripts) in DojoX, right? It's listed on the porting guide as well as the bug database.
Let me further elucidate.
SvgButton, HslColorPicker:
Both were proof of concepts dealing with pure SVG environments. What happened is that during the course of my research to create the first iteration of the charting engine, I discovered that it is almost *never* that someone will work solely in an SVG environment, particularly in this day and age of browsers supporting mixed XML namespaces. It took a lot of convincing, but eventually we decided to change the original rendering structure of Dojo (from 0.4 to 0.9), and we were able to remove a lot of cruft that we'd had there trying to support those pure environments.
It's one of the main reasons the widget system has been paired down, to be honest. As soon as we could make the assumption that widgets will always be used in an environment with HTML available, a lot of the base structure for the widget system could be merged and eliminated.
The other reality is that most people simply don't care what rendering system is being used. If I show you a button, it doesn't matter if it was done with HTML, SVG or VML; all that really matters that you can click on it, and something will happen.
Clock:
This was entirely a proof of concept that I wrote very quickly, based entirely on the dojox.gfx Clock demo that Eugene wrote, to show how you can use dojo(x).gfx with the widget system. It was never really intended to be used (and unfortunately that goes for a lot of the rest of the widgets not being ported).
DebugConsole:
It's pretty much incorporated directly into the Dojo Base via Firebug and Firebug Lite. Because of that, it's no longer necessary as a standalone widget.
Editor2:
It's being stripped down and rewritten as the Dijit Editor. Editor2 was a nice piece of code but the way it was written made it *very* difficult to incorporate and modify.
FilteringTable:
Will be replaced with a Grid widget. Parts of Filtering have already made its way into other parts of Dojo, particularly in Dojo Data (they lifted the sorting code almost verbatum, IIRC).
The problem with Filtering is that it anticipated many of the things that are being more fully fleshed out in other parts of the Toolkit, such as data binding mechanisms, data stores, and more. What it really was was a widget I'd written for other projects which we slammed into Dojo because so many people were screaming for a grid. I never really wanted to add it, but there you have it.
We do recognize that a Grid is ridiculously important. I was on deck to write it but I simply don't have the time, and it's better if others who are more involved with the Dijit project take it on (I don't have anything to do with this project other than advice about rendering and layout).
GoogleMap, YahooMap:
Again, I wrote both of these widgets as proof of concept in about a day. I have a plan in the works for a much more extensive geo project in DojoX (probably called DojoX Geo) that will incorporate the functionality of both of these widgets and more (probably do one on the new MapQuest API, maybe Live Earth as well). In fact, as soon as I come up for air after the rewrite of DojoX Charting, I'm going to start soliciting wants and needs for that project--so if you have any ideas, feel free to post them in the DojoX Discussion forum.
Monthly Calendar
I don't know what is going to happen with this, but I know Dustin wrote it as part of an effort to be able to create and manipulate iCal data within a client--and frankly I think this will end up as part of a more extensive DojoX project as well.
RadioGroup
This widget is the sole result of me being very frustrated at the way the older TabPane widget was written, and was written by Jesse Kuhnert under my direction as a proof of concept to show some of the other widget developers exactly what we meant by a very light-weight widget. Because of that lineage, we decided to drop it. Maybe it will show up in DojoX, I don't know. It should be very easy to port.
It's called RadioGroup because that's really what it is: it takes an HTML list and adds radio button functionality to it. It could be used for that or for tabs--or for anything else that might need a single selection out of a group of things. But it's really aimed more at the JQuery/Prototype-like crowd--people who are looking for very lightweight things they can layer on top of straight up HTML.
Tree
The Tree3 widget, while very extensive, tried to do waaaaaaaaaaaaaaaaay too much. Have you looked at the code for that in 0.4 at all? The files supporting it is almost as extensive as the rest of the widgets themselves.
I think the Dijit group decided that certain parts of that functionality should be supported, and others dropped. What's in the 0.9 beta is the beginnings of the widget; I'm almost positive if you ask for some specific functionality, and it's a common use case, they'll consider adding it.
A piece of manual
You two have written some good stuff for the porting guide! Don't keep it buried here. I am definitely in favor of a data bound Grid widget.
the buck stops here :-)
Hi all. I'm in charge of Dijit and I made the ultimate decisions about what we support and what we don't, so you can blame me :-). On the other hand, I've made it clear that Dijit is just meant to be a home to the most commonly used widgets. All the really cool esoteric stuff (like GoogleMaps or Fisheye or Show) is in dojox by design. The decisions were made after consultation with many people, but admittedly mainly the committers. There were many meetings about it, both online and dojo developer conferences.
I think Dante and Tom explained the rationale for the decisions pretty well, so I don't have much to add.
As for Tree, TreeV3 in 0.4 is 75 pages long, with lots of good stuff, but we just don't have the resources to port it all to 0.9. So it wasn't a decision per se to "hobble" the tree. Just a limitation on what I could get done in time for the release. Since it's based on dojo.data now, we have to rethink a lot of the stuff from the ground up.
I'd like to get DnD working eventually, in addition to getting tree to automatically reflect changes in the underlying data. I agree that a more full featured Tree (and of course the Table widget) are essential.
Ta
Thanks Dante, Tom and Bill for the replies.
I was not aware that the previous Tree widget was quite so expansive and I can see why a whole-scale rewrite was the best course of action.
I think that the current dojo/dijit/dojox separation is pretty spot on and the benefits of a fast and robust core with simplified widgets will be appreciated by the community.
I was not meaning to start a 'whats wrong with 0.9' debate, and so should have probably said that 0.9 seems to be a real step forward, except for the tree widget. I know that you cannot please all the people all of the time and that everyone will have some pet gripe about something that has changed or something that has not been ported yet and so congrats that this has been kept to a minimum so far.
One thing I wanted to get across is that when porting to dijit, I think that it would have been prudent to ask the community what widgets were the most used and what feature were relied upon, then the most used widgets could receive the most love from the committers. This is a simple focusing of efforts exercise so that 0.9 would be a well received as possible and the community would have felt involved in the process. Maybe dojo was not fully aware how widely used 0.4 was and the number of people writing large commercial apps with it ;-)
I'll have a play with the tree code and if I think my efforts to replace some of the missing functionality are worth your consideration then will submit for review.
Me too, to the pile.
Hi,
First, respect to Dojo Toolkit, I appreciate everything being done, so thank you and sorry if all I write sounds like complaints and grievances… Such is the unfortunate result of a forum supporting a product of this type.
0.9 Dijits have introduced rigidity and an assumed use in an otherwise previously flexible paradigm. Comments like “that’s weird and shouldn’t be used like that” followed by “write your own widget!” are unrealistic. All the stuff I could freely do with 0.4.3 widgets now introduce staunch usage archetypes and reduced functionality.
As a server side programmer that could tie these things together with previous versions, I’m now expected to churn out javascript code to fill in all the gaps, or use vanilla widgets based on some perceived generic use.
I have to agree with fermo111. “If you delete a method or a property, say at least how to obtain the same result with the new API. If you delete a class is either because *nobody* uses it, or because there is a better way to do the same thing with the new API. Just tell us.”
If my question is “How do I get wipe functionality in and remove the toolbar in Dialog like in 0.4.3”, and the answer “use dojo.fx and subclass dialog” - that’s really not sufficient in any shape way or form. It’s the equivalent of telling a PHP programmer who wants to know how to do something in PHP to “use C or Assembly and write a PECL module and compile it into Apache” . If that really is the only way, then some concrete working examples are needed as starting points.
Sooner than later. Please.
If my question is “How do
is that really your question? i could answer it, but I've not see it become a question to be answered in these forums, and i just happened to read it here though it is entirely off-topic if it really IS a question.
"subclassing dialog and use dojo.fx" isn't anything like telling a PHP programmer to learn a whole new language (C or asm?). This is javascript, and subclassing Dialog uses pure Javascript (as does dojo.fx) ... and there are a million ways to do any particular task, some more effective than others. you can dojo.addClass(dijit.byId('myDialog').domNode,"hiddenTitle"); and have a CSS definition something like .hiddenTitle .dijitDialogTitle { display:none; } or you can just add a class to the markup [div dojoType="dijit.layout.Dialog" class="tundra hiddenTitle"][/div] or any number of things. or (subclassing) extending Dialog.js is as easy as:
// postCreate: function() {
// i would put this.titleNode.style.display:none somewhere in postCreate function
// in here.
// over-ride the show() function to use dojo.fx.wipeIn instead of dojo.wipeIn and
// remember to dojo.require('dojo.fx') before this dojo.declare() block
// }
});
specific questions about things are answered mostly as best as we can. Saying something "shouldn't be done that way" i would guess mostly relates to using the stock widgets, eg: not it's intended behavior.
i personally think the ease in which you can extend the robust widget set in dijit is what makes 0.9 even more powerful for both PHP-server-side devs, and javascript hackers alike, and what makes Dojox such a desirable place to muck about. Doing what can be done, a number of post-beta-release widgets have been ported over into the developmental world that is Dojox (which is at least as stable as 0.4.3 in most places, and typically much faster because of the lighter load/footprint of dojo.core functions).
karl ported FisheyeList to 0.9 in a day, against 0.9beta (due to lack of SVN head access that day) and porting it to work against head took an additional 5 minutes.
The point is: bear with us/them/they/dojo. It's clearly marked beta, new stuff lands daily, pushing to get 0.9production 'production ready', we know you (as in the global YOU) want a Grid, I do too, etc etc. >0.9production will allegedly have backwards-compatibilty back in place, documentation is a major goal/requirement pre-1.0 release, and please remember we're all volunteers. phew. that was a mouthful. Your comments [nor most other 0.9 grevience comments] don't sound like complaints, and they aren't falling on deaf ears I assure you. Taking an aggressive position on a subject isn't going to help convince anyone to work faster, but offering assistance and constructive feedback most certainly will.
Appreciated
I've been a user of Dojo for almost 2 years and my pet projects and pet peeves are not full representations of what kind of giant corporate intranet mutations i've seen teams of people turn Dojo into. The previous post was just one recent problem that I came across...
My point here was to add to the chorus of 0.9 users who need the functionality previously available in WIDGETS, i.e. the idiot layer of Dojo, who may have used this precious cargo and lack of Javascript knowhow, built Perl/PHP wrappers around the HTML parsable stuff (not the programatic javascript stuff), come up with other uses for widgets that are not immediately evident, and dearly depend on all the extra functionality being chopped away.
As stated in this thread, there are other toolkits available. Many like me chose Dojo because the WIDGETS did not require vast Javascript skills. If we knew javascript the other toolkits would have been very appealing... In fact, in the last month, I keep looking at them every other day. The documentation is superior in many of these alternative toolkits, but I am turned off because of my dependency on Widgets (again, the dummies version of javascript).
I'd love to help out, hack away at dojox, be an active contributing member to Dojo. I hope to one day become an adequate Javascript coder, but for now I add to the chorus. If I am to hack away, I need docs and working examples, not pseudo code with way too many blanks and narratives. Again, respect to Dojo. Sorry if i sound aggressive. I am a big fan of Dojo, a supporter when talking about it to my peers, etc. But I just need to get this off my chest. It will be the last time I bring it up.
Thank you for your time.
no worries, and remember:
no worries, and remember: dijit isn't against enhancements. bill just wants to keep 'esoteric' (read: stuff that adds bloat) stuff out, like one-off cases that can easily be accomplished with trivial javascript skills. (i admittedly am a much better pl/php dev than a javascript dev, and i personally find it very difficult to flip-flop between the two but dojo almost makes that easy too ... (imho) so if you want something, file a trac ticket requesting the enhancement, and if it makes sense to the powers that be, and "more than one person wants it too", it could make it in.
and wrt to documentation: like i said, it's a key goal for 1.0 to have full documentation (inline code docs that are clear and accurate, that can be parsed into the new api tool (which could use a spare set of quality-php-coder eyes, too, afaik) at http://redesign.dojotoolkit.org) which will eventually support user-contributed notes (much like the wonderful php-web-api) for more specific hacks. allowing comments on the bookpages here is the interim solution to a beta api tool ...
tree stripped
While trying to port from 0.4 to 0.9 I also stumbled over the fact that the tree functionality has been stripped. I also thought that widgets have been improved or at least kept their functionality.
(Especially multiselection is important to us.)
I suggest that you put a notice at the beginning of the porting guide.
"Be aware that not all widgets and functionality have been ported to 0.9. Check this guide if the widgets you use are still supported with all the functionality you need."
Then I would have been warned and checked on Tree before devling into porting attempts .
(I guess it is hardly possible to use old TreeV3 with dojo0.9, or is it?)
in blog but
I already wrote that in my blog but ok I'll add it to the porting guide too...