I don't care if it can be optomized if it introduces more complexity. How often are people drag/dropping objects on webpages anyways? There isn't a need to support 100,000 operations per second for this kind of operation. Looping over components in a page is blazing fast unless you have *thousands* of components on your page.
If there's an easy way to grab the component path for both Draggable objects *AND* the SortableListView, I'd be interested to see it *and* see benchmarks for it. So far, I have only been able to get both the SortableListView and the DraggableBehavior to use markup id's, and i'm very pleased with how easy *and clean* it is to do this. any other solution will have a tough time swaying my opinion unless it's very simple to do. On Jan 10, 2008 10:21 PM, Edward Yakop <[EMAIL PROTECTED]> wrote: > I forgot to mention about the usage of markup id. > > I think this is a less optimize way to find the drag source component, > especially if the page object graph is large. > > For example, > If we have the following Page component structure. > > Page > - Container1 > - Table with a lot of rows > - other component > - Container2 > - Table > - rows > - "dragSource" > > If we search based on output markup id for drag source, it will have > to visit Container 1 and all its children, before visiting container > 2. > > By using path (sample path "0:container2:....:dragSource" ), instead > of visitor, > the search will be a matter on how many hop to get to the drag source. > > > Regards, > Edward Yakop > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
