High all, I was wondering if it was possible to select an on page element via its coordinates?
reason being i'm trying to make an editable page where you can right click on highlighted elements, menu appears and then select from the options give. using the only method i could find that worked to select the element via hover it uses (event.target) which if having lots of parents combined with other code, it loops through and looses other data along the way. If i can find another method for highlighting the elements that would be of course better.
This is a terrible way to go about doing what you are trying to do, and I speak from experience: I inherited a calendar tool that figures out what day of the month you clicked on based on your mouse co-ordinates. The stupid thing certainly works, but it's a giant PITA to maintain/modify/add to in any way.
The much, much better way to go about it (unless you want a maintenance nightmare in your future) is to use the event object. If you hook up your events to the correct objects and use e.target (or, if you use jQUery, "this") you should be able to very easily route the correct actions based on the where the user clicked, without any coordinate nonsense.
Related
It is possible to customise nodes on a ThreeForceGraph, using APIs provided at https://github.com/vasturiano/three-forcegraph, using the method ThreeForceGraph.nodeThreeObject(...). The ... here can be a THREE.Sprite instance, and we can render any svg picture to THREE.Sprite.
However, I wish to have something more than a picture. I wish to add two clickable buttons to each node of the graph. I can do Sprite.addEventListener(...) to detect mouse click, but this is not quite the same as a button. It would be really nice if I can make each node on the graph into a React component (that would be the ideal situation).
After looking around, I haven't found any ways to implement this. Is there any ways to achieve what I described? (Of course, it does not need to be a method of Three.js.) Any examples/references are greatly appreciated.
Background
I am building an application in D3/Javascript, although this may also be broader question about data/view modelling design. D3 has some useful data modelling capability so may be relevant to this. I am new to D3 and Javascript though!
The application:
Plots a relatively large dataset (>5000) of events over time
Should allow selected events to be hidden and re-shown by the user
Should draw a line between events of a similar type, but only those that are still visible
Problem
I am unsure how to best model this, particularly how to manage those nodes which are hidden, should still remain in the data model, but not taken into account when building the line through similar event types.
For the "Hide nodes" use case, I set each component's style to 'visibility: hidden'. These could be re-added later, so I don't want to remove them from the underlying data model.
I am unsure how to go about managing the "Line through similar event types" use case - only using data from visible events.
I think the key question is how do I build a list of events with a common attribute and that are still visible. Can I use D3's select mechanism? If so, I don't necessarily want to append the common attribute to the SVG element due to the large data set. Is there another way?
I could have probably asked this question in one line, but I hope the context helps describes what I'm after!
Many thanks for your help.
If I used:
parentNode.removeChild( divHere );
It does work and the scroll bar for the overflow updates accordingly. If I use JS to 'divHere.style.visibily = "hidden";' well that doesn't work anymore. What I've done pretty much is create 115 divs that are in a container div and the user can select filters to show only the images they want, all the divs have a background image and are essentially just an image with a name under it.
So I have 2 questions:
1) Is there a way to update the overflow and make it not take hidden elements into consideration?
2) If 1) isn't possible than when I use removeChild to remove a div from the container, it does indeed disappear but what exactly happens to it? Does it disappear off the page because it's not added to any element on the page? So it essentially works like it's hidden? I don't have to worry about people seeing the images in some completely weird spot in some lesser used browser?
and well 3) If you have a better method of doing this it would be greatly appreciated
Thanks in advance for any help
The removeChild() method removes a specified child node of the specified element and returns the removed node as a Node object, or null if the node does not exist.
That null means that the element is now removed from your mark-up.
You should use it to not let the browser take that into consideration, as the browser will not find that element in the mark-up.
You can do it in this way as well:
$(document).remove(object_to_remove);
FInd more about it: http://api.jquery.com/remove/
I believe I may have a response for the third part of your question. That large number of divs in your containing div and the usage of filtering make me think you might want to look into using the DataTables plugin for jQuery (http://www.datatables.net/). It has some very nice features for sorting/filtering/etc. a large number of data elements and supports a variety of data sources. There are also some plugins for the plugin if the basic functionality isn't enough for you.
There is a bit of a learning curve if you want to do more complex stuff with it, and it might be tricky to get used to if you haven't worked with jQuery much (though being someone who hasn't worked with jQuery all that much due to not doing much web development, I can say that I quite like using it whenever I get the chance, although that may just be due to me enjoying learning how to do new things in programming), but I feel that if you're willing to spend the time on it you will have something much more maintainable than what you currently have.
I'm working on a javascript framework for creating simple animations on an html canvas with nested sprites using a basic composite pattern.
I've been modeling my work on Clutter and Flash (very similar structure). A "Stage" holds all of the items on screen, which are "DisplayObjects". These can be aggregated in a "DisplayObjectContainer", which inherits from "DisplayObject". The "Stage" itself is also a "DisplayObjectContainer". All of these inherit from an "EventDispatcher".
I've spent the better part of the last few days reading about the event flow of these systems and searching for examples in various open source projects.
From what I understand, when an event is dispatched, it should follow a certain propagation path: it flows from the stage, into the display object hierarchy (the "capture" phase) until it reaches the "target" of that event, and then "bubbles" back up the display hierarchy. If this isn't clear enough, the images located here should help explain:
http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e4f.html
http://docs.clutter-project.org/docs/clutter/1.4/event-flow.png
There is an aspect of this that I'm failing to understand, and I can't tell if it's just me or if this is as unclear as I think it is:
Suppose I'm dealing with clicks. I click on the display and use the browser's native event handling to retrieve the x/y coordinates of the click, and then send that down the display hierarchy to determine which object I've clicked.
Until now, this WAS the "capture" phase in my code. But this is completely at odds with the documentation which says the target should already be attached to the event by the time it enters the event flow.
Am I really supposed to traverse my graph of display items twice?
Any advice or expertise on the issue would be highly appreciated.
Interesting question! Yes, I believe you would need to traverse your DisplayList first to calculate the event target before beginning the capture phase of your event-flow. Never having designed an event system, I'm not completely sure about this, but perhaps when you calculate the target object you could cache the hierarchical route and use that as the basis of your event-flow rather than traversing the DisplayList again.
The bit that you're unclear on, I think, is more obvious if you consider it in terms of implementation rather than in the abstract of designing an event system (and the terminology of existing event systems). Imagine, a widget consisting of a parent object, and a number of child items which need to react to mouse clicks. You might decide you want to listen for events on the parent object only, but react according to the target object from which the event originated. In ActionScript, if you're using the capture phase of the event-flow, your handler would fire before the target of the event is reached but, in this case, the target is an essential property of the event object.
As suggested in the comments, it might be worth looking at the source code for easeljs since it claims to provide an API "that is familiar to Flash developers". However, note that easeljs does not currently support a full-featured event flow for performance reasons (see here).
My two pennies; event-flow is tricky enough to understand (let alone design) and implementing a full-featured event system may be at odds with your goal of creating a light-weight library. I would suggest you keep it simple at this stage and only add features such as event bubbling if you find you need them.
So for example if we have a flash video already buffered and playing, or an autocomplete active with input, focus, and a dropdown visible (and maybe even loading something) but only have HTML of the full document and a copy of the HTML earlier, how can we merge them into the live DOM without the user's state being interrupted?
Ordinarily I'd just program a specific fix, specifying the right area to change given it's div name, manually but that is not a known variable for the situation at hand (I'm programming a Pythonic MVC framework with AJAX).
I want to change the smallest amount of nodes, and probably the deepest nodes that I can get away with.
It's ok to require ID's for some of the nodes (e.g: flash or autocomplete widget) but not possible to expect this for all nodes - so in some situations perhaps node position and types will be available to compare documents.
I understand this will not be a complete solution but in some cases it will be all that is required.