[dojo-contributors] response to Tom's proposal

[Owen Williams]

Responses to Tom's full-on-proposal:
	http://dojo.jot.com/WikiHome/Widgets2.0/The%20full-on%20TRT% 
20proposal%20%28a%20bit%20more%20than%20you%20probably%20expected%29

Firstly, Tom, thank for taking the time to write such a coherent  
proposal.  I agree with much of it, particularly the parts about  
needing to improve the build process and communication.


Some questions/thoughts:

1) It seems to me that many if not all of the widgets in the "current  
widgets" (1.0) will be necessary when developing in the "new  
style" (2.0).  Web 2.0 applications still have trees, lists, grids,  
etc.  I can see what you talk about with the different audiences, but  
it seems like having two completely different widget systems will  
result in a lot of overlap and duplication of code.  And what if I'm  
using the "2.0" system, but I need something that's only in the "1.0"  
set?   I'll have to pull a lot of "1.0" infrastructure in just to  
handle that one widget -- Yuck!  Or build it myself, when it's right  
there on the other side of the wall -- double Yuck!

2) I'm not sure that the "1.0" widget users are more concerned about  
speed of development than runtime performance.  Especially if folks  
are coming from the Java world, they are used to writing lots of  
code.  I see this all the time at Zimbra -- I've been trying to lead  
that team into a more declarative style of programming, and the  
answer I keep hearing is that they understand the (very Java-ish) way  
of programming they're doing now, that it's fast enough, that they'd  
rather have things be done more explicitly (meaning more code) than  
have a system that dots the i's and crosses the t's for them  
automatically that they don't understand.

3) I'm not sure that splitting things up into separate sub-projects  
will help make things less confusing overall.  I see the benefits for  
discouraging cross-contamination and build sickness that you  
mention.  However, with things like data binding for widgets (whether  
in the 1.0 or 2.0, and I think it applies in both) -- how would you  
structure this as two separate sub-projects?  Does pulling in the  
data binding stuff also add functionality to the 1.0 widget set?

4)  When I think of a "toolkit" in the real world, I definitely think  
of discrete components (wrenches, saws, etc).  It seems like Dojo in  
this sense is the "brand" (like DeWalt or Black & Decker).  I would  
hope that in whatever structure we end up with, we stay with the Dojo  
"brand" over all the projects.   I think one of the biggest  
disadvantages of the Prototype-based system of development that I can  
see is that to use it, I have to go to at least three different  
development sites and learn how they do things, how their  
documentation works, etc.



About the docs and API ref -- I'd love to have your opinions on the  
following.  I'm genuinely curious and am not taking this  
personally.  :-)

a) One thing that may not be apparent is that the entire Api  
application is itself completely usable offline if you have a dojo  
install.  You can hit  file://your/dojo/install/api/index.html and it  
will present all of the info in exactly the same way as it does  
online.  One thing that we're not currently doing (but could pretty  
easily be done) is making sure that the /docscripts/local/json/*  
files are updated when the builds are done -- this just involves  
running the docscripts and checking in the output before the builds  
are cut.  This, IMO, is one of the main reasons why a hybrid  
generated/wiki'd docs would not work -- there would be no way to work  
on it offline.

b) You call for an indexed PDF as doc -- how would this be structured  
in your mind?  Is this the API ref, or the Book, or both?  What  
benefits (other than printing, see below) would this have over the  
current API ref?  Would you see this being built off of the parsed  
comments, some other means, ???

c) Printing is definitely not facilitated now, but could easily be  
done -- it's mostly just a matter of expanding all of the visible  
sections and opening in a new window optimized for printing.

d) You said "The current API tool is OK for what it does but may need  
to be reassessed at some point."  What are you thinking it should  
do?  How would you change it?  What would you add or take away?

Frankly, I'm running out of steam on the entire doc portion of the  
house -- I've really only been working on this because Alex asked me  
to step in last August to get something done in the 0.4 timeframe.  I  
could use help in bringing some of the features that we've been  
discussing to term.  I'd love to turn the "ownership" of the docs  
portion of the code over to someone else so I can concentrate on  
parts of the system that are more fun for me.

cheers
Owen
-------------------------
Whenever I despair, I remember that the way of truth and love has  
always won. There may be tyrants and murderers, and for a time, they  
may seem invincible, but in the end, they always fail. Think of it:  
always.  -- Mohandas K. Ghandi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20061210/7be5dc05/attachment.htm