170
I Use This!
Very Low Activity

News

Analyzed about 8 hours ago. based on code collected 1 day ago.
Posted about 16 years ago by liucougar
This is a late introduction of dojox.sketch, which was contributed to dojo foundation by TeamPatent. dojox.sketch allows users to place/manipulate shapes on top of a background image, zoom/pan, and (unlike other open-source Javascript drawing tools) ... [More] supports undo/redo. It's designed for collaboration, encoding changes as diffs to the SVG document (the diffs can be transmitted to collaborators). It's cross-browser, transposing SVG to VML and vice versa on the frontend. It was first implemented by Tom for dojo 0.4 under a contract with TeamPatent and later I ported it to dojo trunk. The code is experimental (alpha quality) and you can try it out here. Placing shapes atop a bitmap makes it similar in concept to the Adobe Acrobat drawing markup toolbar though, at this point, it only supports callouts. dojox.sketch could use easier placement/manipulation of shapes (e.g. group selection and drag/drop off toolbar) and more shapes. A couple of days after it was contributed, a Comet Daily contributor added Comet to dojox.sketch. If your project could use Sketch, please consider extending it and contributing back. On a side note, TeamPatent is also looking to hire a full or part-time software engineer with backend expertise and an interest in collaborative systems (our prototype currently uses Python and PostgreSQL). TeamPatent is funded by a grant from the National Science Foundation which restricts the work to US residents. [Less]
Posted about 16 years ago by alex
We've been blogging about what's coming in Dojo 1.1 for a while now, and today I'm happy to announce that Dojo 1.1 Beta 1 is available. There's so much great new stuff in this release that it's hard for me to know where to begin, so I'll let the ... [More] release notes do most of the talking. The team has closed nearly 500 bugs, and it'll be closer to 700 by the time 1.1 goes final. We've been busy. Of particular note: major overhauls and updates to the Dijit themes thanks to Torrey Rice and Nikolai Onken CSS optimization and multiple versions of Dojo side-by-side, courtesy of the irrepressible James Burke BorderContainer and ExpandoPane layout containers animation support in dojox.gfx new easing functions in dojox.fx and code highlighting in dojox.highlight dojox.dtl is now at feature parity with Django's implementation and has extensions for handling dojo.data results cleanly major updates to dojo.data integration with the grid and tree and new data stores including JsonPath for simple JSON queries and a SnapLogic store to make your lightweight data integration tasks a snap updated accessibility support to track the latest changes in Firefox 3's WAI-ARIA implementation Adobe AIR support (courtesy of Adobe and SitePen) drop-in backwards compatibility with Dojo 1.0 ...and that's keeping it short and sweet. We'll have more updates as we do another beta and a release candidate for 1.1, but you can start playing with it now to see how much faster, smoother, and polished it is. [Less]
Posted about 16 years ago by dylan
Scott recently created a diagram outlining the various pieces currently in the grid (click the title to see the diagram)...
Posted about 16 years ago by bill
This post is out of date... see the new post instead. In version 1.1 I've fixed the Tree architecture to be able to handle DnD correctly. I've had to deprecate (not remove) some version 1.0 APIs because they didn't work with DnD, and I've listed ... [More] them here, along with some general discussion about what it means for a tree to connect to a data store. Hopefully some will find it useful. Tree/data store connection Dijit.Tree's connection to dojo.data gives the tree a lot of power, but it's also complicated the API to something more than if the tree simply displayed a read-only collapsible list, and/or had it's own custom data format. That's why various people have asked for a more direct interface to control the nodes in a tree, but at least for now I've decided not to do that, in order to minimize the surface area of our API. The dijit.Tree widget is a view on a dojo.data store. Tree's job is to display the store data in a hierarchy. This is more complicated then it sounds because a store doesn't represent a tree per-se, but rather it just contains a bunch of items, some of which contain references to other items. For example, an item might have multiple children attributes, each of which points to other items. Multiple parent items could point to the same child item, or there could even be loops. Consider this store: [inline:store.png] If we represented that data in ItemFileWriteStore, it might look like the JSON below, although it's important to realize that Tree can interface to any store, so the internals of the store are irrelevant. {         identifier: 'id',         label: 'name',         items: [                 { id: '0', name: 'Fruits', top: true, children: [ {_reference: 1}, {_reference: 4} ] },                 { id: '1', name: 'Citrus', items: [ {_reference: 2}, {_reference: 3} ] },                 { id: '2', name: 'Orange'},                 { id: '3', name: 'Lemon'},                 { id: '4', name: 'Tomato'},                 { id: '5', name: 'Vegetables', top: true, children: [ {_reference: 4} ] },                 { id: '6', name: 'Lettuce'},         ] } We'd like the dijit.Tree widget to display those items above in a hierarchy, like this: Fruits Citrus Orange Lemon Tomato Vegetables Tomato A few things to note: this is technically a forest, not a tree, since there are multiple top level nodes. there's only one 'Tomato' item, but it's referenced as both a Fruit and a Vegetable. Tree doesn't support multiple-parent items yet but will in the future. The point is to note how a data store represents very general data which we are mapping into a Tree. Dojo 1.0 Tree API In the dojo 1.0 release, dijit.Tree featured an API where you specify a query to get the top-level item or items, and then an attribute to query to get children of those top level items. For this data you would want to display all the elements marked as top:true at the top level, and then get children via the "children" attribute. <div dojoType="dijit.Tree" store="catStore" query="{top: true}" labelAttr="name" childrenAttr="children"></div> Tree also provided an option to create a root level node to tie 'Fruits' and 'Vegetables' together without any such item existing in the data store, by specifying a label to the Tree: <div dojoType="dijit.Tree" store="catStore" query="{top: true}" label="Food" labelAttr="name" childrenAttr="children"></div> which displays a tree like: Food Fruits Citrus Orange Lemon Tomato Vegetables Tomato This is a convenient feature, although it causes some confusion since there's no data store item associated with the top level node in the tree, and thus clicking it will produce an onClick(null) rather than onClick(item). Of course you could add a "Food" item to your data store but it may not be convenient to change your data model just to affect the view (the Tree). The problem with DnD and data store notification Given that a dijit.Tree is just a view onto a dojo.data store, any updates to the tree (ie, moving a node via DnD) have to be reflected to the store, and conversly any updates to the store need to be reflected in the tree. [inline:sync.png] As a matter of fact, dragging-and-dropping (ie, moving) an item in the Tree doesn't update the tree directly, but rather just updates the data store, and then Tree responds to that update just like any update to the store (from an external source). So, there are two issues involved with a tree: notifying the data store about updates responding to changes in the store If you move an item (for example, deciding that a lettuce is a fruit rather than a vegetable), the DnD code tells the data store that Vegetable's children attribute changed from [Tomato, Lettuce] to just [Tomato], and that 'Fruits' children attribute changed from [Citrus, Apple, Banana] to [Citrus, Apple, Banana, Lettuce] (or perhaps a different order). The data store then notifies tree of the updates to 'Fruits' and 'Vegetables' children attributes, and tree updates it's display. If, however, you decided that a 'Tomato' was neither a 'Fruit' nor a 'Vegetable', but rather just a type of food, you would want to somehow make it a top level item in the tree so that myStore.fetch({ query: {top: true} }) returns 'Tomato' in it's query. We have two issues here, namely that: dijit.Tree doesn't know how to mark the element as "top level". In this case, it's simply setting the top attribute to true, but there may be more complicated cases. The data store notifies the Tree that an item has changed (namely that the item's "top" attribute has been set), but there's no way for Tree to know whether that item now matches the "top level items" query specified to Tree without rerunning the query. And even if it new an item was top level, it wouldn't know the order of the new item relative to the other items. This is because Tree can connect to any data store and thus the query format is a black box. ForestDecorator In short, all of these problems are caused by allowing a query which lists a set of top level children, and whose results can change over time. If we assume that there's a single root item, specified when the Tree is constructed, everything is simplified. All changes to/from the tree are specified as changes to some item's children attribute. However, in order to support data stores which don't match this pattern, I've created dijit._tree.ForestStoreDecorator, which wraps another store and just adds a fake root item. var baseStore = new dojo.data.ItemFileWriteStore({                 url: ...});         var decoratedStore = new dijit._tree.ForestStoreDecorator({                 store: baseStore,                 query: {top:true},                 rootId: "food",                 rootLabel: "Foods",                 childrenAttr: "children"         }); The decorated store just has a root item, but is otherwise the same: [inline:decorated.png] Then you simply create the tree off of the decorated store: var tree  new dijit.Tree({                 store: decoratedStore,                 labelAttr: "name",                 childrenAttr: "children"         }); It also has a number of hooks to handle changes to elements when they are added/removed from the root node, such as setting top: true. But the important thing is that it presents a consistent interface to dijit.Tree such that every time an item is moved, it's reflected by changes to two other items' children attributes. Note that the top level item doesn't actually have to be displayed. The showRoot parameter controls whether the tree shows up as a true tree, like: Food Fruits Citrus Orange Lemon Tomato Vegetables Tomato Or just as a forest: Fruits Citrus Orange Lemon Tomato Vegetables Tomato So, in summary, dijit.Tree still takes a query parameter, but that query should only return one item (the root item). And if (as for the case of ForestStoreDecorator) store.fetch() only returns a single item, then no query is needed. Other deprecated APIs getItemChildren() was a convenient abstraction for non-standard ways of mapping parents items to child items, but it doesn't handle updates to the data store. The user can write decorator store like dijit._tree.ForestStoreDecorator. getItemParentIdentity() falls into the same category. Nested ItemFileReadStore problems Let's look at ItemFileWriteStore with nested elements since that's often used. Consider a data file like this: { identifier: 'id', label: 'name', items: [ { id: '0', name: 'Fruits', children: [ { id: '1', name: 'Citrus', items: [ { id: '2', name: 'Orange'} { id: '3', name: 'Lemon'} ... ]}, { id: '4', name: 'Apple'}, { id: '5', name: 'Banana'} ... ]}, { id: '6', name:'Vegetables', children:[ { id: '7', name: 'Tomato'}, { id: '8', name: 'Lettuce'} ... ]}, ... ] } How do we mark 'Tomato' as a "top level" item, so that ItemFileReadStore.fetch() will return that item? Short of actually deleting and recreating the item, which is bad for a number of reasons, there's no way to do that with ItemFileReadStore and nested data. The best we can do is switch to a referenced layout like at the beginning of this article. Although there's a special API to create an item as a child of another item, there's no API to move it to be top level. Actually, the nested ItemFileReadStore has another limitation that you can't multi-parent an item, such as marking 'Tomato' as both a fruit and a vegatable. [Less]
Posted about 16 years ago by alex
A quick tutorial on writing dojo.query() extensions. It's fast, easy, and because we show you how to package it up as a Dojo module, it won't drag down your site performance The awesomeness that is WebKit just won't quit and we've already added ... [More] support for the native code path to what will become Dojo 1.1 (look for it in tonight's build). Of course, because the design of Dojo is layered, your dojo.query() extensions work no matter what selector engine Dojo picks as being fastest for a particular search. [Less]
Posted about 16 years ago by ttrenka
Lots of things have been happening in DojoX lately, both big and small. I'll leave it to Pete and Adam to talk about some of the widget-based improvements that have been making their way into the codebase, but I'll talk real quick about some of the ... [More] other things that have landed recently, and some upcoming things to look for. Speed improvements to Blowfish Thanks to a submission by Peter Wood, Blowfish now performs about 4 times faster than it used to; some clever refactoring and much simpler uint math functions have gone a long ways towards making the algorithm much more useful. On Safari 3, with a 2.4GHz MacBookPro, the unit tests are averaging about 100ms per operation; previously they were somewhere in the range of 500ms or so. Kudos to Mr. Wood for the shout out! Take a look at the unit test. Curved lines now available in DojoX Charting During DDD/IV, I was quietly hacking away on a number of things in the back of the room while a lot of great presentations were going on; one of the things I added (at Eugene's request) was to enable curved lines (based on this article) in the charting engine. So...if you're using the nightlies, all you need to do is add a "tension" property to the keyword arguments object you pass to a plot. The higher the tension, the tighter the curve. A tension of 0 means that you do not want the curve; this is the default setting. In practice, I've found that a tension of 3 yields the nicest curves; not too tight but not too loose. Take a look at the unit tests; charts #3, #11, #12 and #28 all show the tension in place. Note that #11 and #12 are stacked charts; curves have been enabled on stacks as well. DojoX Sketch has landed. A new project called "Sketch" landed in DojoX about a week and a half ago; donated by TeamPatent and ported to Dojo 1.0 by Liu Cougar, it's a general tool for annotating figures with a full undo stack. Take a look at the test and play. You'll notice that the SVG document in the bottom text area updates with every action on the drawing. Color Generator has been finalized. Another small "under-the-radar" set of additions to DojoX include DojoX color, an extension of the dojo.Color constructor. In addition to adding conversion methods to HSL, HSV, CMY and CMYK, there is a Generator that allows you to create a palette of colors based on several well-known generation rules. Included rules are analogous, monochromatic, triadic, complementary, split complementary, compound and shades, all loosely based on the rules at Adobe's Kuler tool. To use the generator, all you need to do is pass it a keyword argument with a base color, and the Generator will do the rest for you. Take a look at the unit test for examples. Upcoming updates and additions Brad Neuberg starting hacking again on his Flash storage solutions during DDD/IV, and in running some performance tests he was pleasantly surprised to find that Adobe has fixed the serialization problems with Flash's ExternalInterface with the latest version of the Flash Player. What this means is that a good portion of the code currently in dojox.flash can be eliminated, and the Flash Storage provider can be vastly simplified and updated. Look for this in the near future, as well as some updates to Dojo Offline. I've also quietly added/begun a new project called DojoX A/V; right now, this consists solely of a pair of base methods to embed both Flash and Quicktime on the fly but will soon include a number of things you can use on your own pages, such as a Jukebox and a Tuner. The bigger news here is that there is the beginnings of a partial port of some of the Dojo base to AS2 (including console pass-throughs, the event system (i.e. connect), and a number of the lang constructs) in order to support some of the A/V stuff well, all compiled using MTASC. All coming soon! There's a lot more exciting news revolving around the entire project, so keep an eye out! [Less]