Beatports new interface has solved a major problem I was looking for the solution too.
Namely, it keeps a "player" interface at the moment and you can browser to different parts of the site (also changing the url) without reloading or interrupting the player.
I cannot for the life of me understand how they have done this, can any of you guys figure it out?!
Many thanks for any replies I get
Looks like they are just using AJAX to load new content but have taken care to make it work and look pretty seamless. You can get better insight into what events are attached to what elements via the Visual Events bookmarklet. Once you find the code that triggers the event, you can run the obfuscated javascript through JSBeautifier to examine it more closely.
Specifically, it looks like they're adding click handlers to all anchor tags, passing off the event if it was triggered with a middle click or modified with a keyboard key, otherwise passing it to a dynamic loader which handles state and other specific conditions like multiple clicks. The seamlessness of it comes from the way they deal with URLs making every page bookmarkable and the browser history so the back and forward buttons work as you would expect on a "normal" site.
Related
We are using ZIGGEO to record video interviews in our new platform. I have noticed that sometimes it seems that the submitted event is fired more than once when the user submit the video. It doesn't happen all the time. Is it something that we can control?
ziggeo.ZiggeoApi.Events.on("submitted", (data: any) => {
this.addAnswer(data);
});
The addAnswer method is called multiple times, sometimes.
I saw that you send us a message to support as well Jordi, as mentioned there happy to help you with this here or there :)
For those that do not know I work at Ziggeo :)
In regards to the submitted event it would usually be called as:
ZiggeoApi.Events.on("submitted", function ( data ) {
//Your code goes here
});
I am not sure if the way you are using it currently could cause any issues, however what I presume to be happening is that there might be 2 embeddings on the page.
The reason why I say that is because v1's submitted event will fire each time some (any) Ziggeo embedding on your page raises the same.
If you want to make sure that events fire in more private manner, I would actually suggest using v2.
I consider v2 much better than v1 in a lot of different aspects, while both are great on its own (good to point out that these are 2 different systems if you will, v2 is not built on top of v1).
While v2 does not have submitted event it has a better one called verified which fires once the video is uploaded and before processing, requiring less time to tell you if the video would for some reason fail to be processed or not - you can read more about that on our forum
This would make it fire for specific video only, and could not be affected by multiple embeddings so I would suggest trying that one out.
You can see how to set it up:
The embedding
codes
Available
parameters
Events
on all of those pages you can change the version (v1 / v2) and on some even the revision to show you only relevant details for revision you are using.
PS: Might be good to see if this is specific to any browser maybe as well, causing the event to be called again for some reason.
I've encountered an annoying issue while working on YUI.
I have a main area and a navigation block. The elements in the main area can be activated with a direct click or by clicking an element in the navigation block that triggers the appropriate element in the main area.
As it turns out, triggering a click event programmatically in YUI isn't as simple as I thought it might be. Looking at the documentation I found pleanty of information on how to attach and delegate events but not how to call one.
I found this question, but it deals with creating a new custom event and not calling an existing one.
All other similar questions are answered with using .simulate(), but this is actually not the best option for compatability reasons and it's also not recommended by YAHOO itself for client-side use http://yuilibrary.com/yui/docs/event/simulate.html#faking. EDIT: After re-reading the section I realized the warning is irrelevant for the subject of this question.
I found a solution by calling the click() command in the node's DOM element, but this is really a last resort and I would like to know if there's a more "clean" way to do it through YUI.
Here is an example of what I'm doing now: http://jsfiddle.net/3fso2dg8/
In the example, the second button is triggering the click event of the first button by using the DOM element
Y.one('#clickme')._node.click();
CONCLUSIONS
After more fiddling with the code I came to realize simulate() is the preferred option in most cases, but not all.
The YUI vesrion I'm required to work with (3.14) has a known issue on simulating a click event in IE9 and above. Since - for other technical reasons - I cannot upgrade to whatever version this issue was fixed and I need to keep a multi-platform compatibility, my original solution is still the best option. Anyone else that uses YUI components that don't respond well on IE, maybe you stumbled upon the same issue so this is one way to solve it.
After looking for exactly the same functionality I just used simulate in user-facing code - where It would just mimic clicking with no return method etc. (simple submit button or choose fil trigger).
When I would needed "complex" functionality I would just add a class or new ID and add new delegate or "on" method in my code - following the: "If a function needs to respond to user action or be called programmatically, it should be written accordingly and called directly in the latter case." prinsipp.
So to summarize - I use simulate for very simple effects with no callbacks or other "advanced" stuff and (sadly) duplicate other delegate/on elements where simulating would be tricky...
Had also looked into your method (._node.click();) and I can't see no obvious difference comparing to simulate()...
So I have been making stuff in Unity3D and decided to try an extension called Playmaker. Basically is uses a FSM (Finite State Machine) to design the flow of states and events. You can drag an event to a different state to trigger another state of events, etc. (Reference : http://www.hutonggames.com/features.html)
NOTE : The actual product I linked has nothing to do with the idea I want to try and build. Just a reference.
Well I would love to be able to do something simliar in Javascript. I think I have some of the logic down but I'm thinking more about User Experience. I want a user to be able to create an FSM with my logic in the browser using Javascript.
I'm not asking for anyone to code this for me or anything as I am experienced enough in javascript to do the bulk of it. I was thinking more about the way you can drag one event to another and it creates a visual arrow showing the user what events are connected. If you look at the first tutorial on the referenced link I provided you will understand what I mean. The arrow length and curves would be dynamic. Possibly be able to drag around states to re organize the layout of the states. This would obviously change the way the arrows pointed as well.
I hope that all made sense.
Ideas? Pointers? Maybe someone has done something like this already? I did find one Javascript State Machine but it generates once, doesn't allow users to move anything, the event dragging to another state is very important.
So I have looked through most of the facebook questions here and it has absolutely confirmed my thoughts. Facebook development may be among some of the worst I've ever used. I'll avoid my rant for now, but as a note to where I'm coming from: tried php sdk, worked decently out of the box, found out I need to put the functionality on a pages tab, can't iframe on pages tab, have to use FBML (which they are retiring in two months, yet I can't start testing the iframe approach yet)
Anyway, I run into FBJS at this point. It works "good enough" for most things, but for some reason I can't get an event registered to an object (a select box in particular interest) by adding a listener (as per FBJS documentation). I am able to add it directly to the html object and have it work, but this is not desirable and I would really like to know what I consider the proper way to do it, which involves seperation of logic and display.
What I want to happen: click on the select box, make a selection, display the text of the selection in an empty div (later on adding Ajax but one step at a time here)
Code:
<script>
var obj = document.getElementById('select-id');
obj.addEventListener('onchange',my_func);
function my_func(evt){
var inner = document.getElementById('div-id');
inner.setTextValue('hey'); // for testing purposes
}
</script>
The above code doesn't do anything when I make a change to the select box. However, this behaves as planned:
<select name="find_state" id="find_state" onchange="my_func();">
I will be grudgingly using this method as I develop, but would really love to know what I might be doing wrong or if anyone else has this issue? And if anyone has any opinions on the matter I would love to know of some form of facebook development recommendations as applications, pages, and tabs all appear to behave totally different from eachother, yet it seems that they all should be doing the same thing to me? Is there any unified way to develop across all three of these things, or am I missing something?
Thanks in advance, as well as for the past help!
I think it should be:
obj.addEventListener('change',my_func);
(instead of onchange)
Straight from Facebook documentation:
The third parameter [to addEventListener], boolean useCapture is required (it does not have a default value)
That means that you should have:
obj.addEventListener('change', my_func, false);
Use the following html and your events attached with .addEventListener() start to work. This seems to be undocumented "feature".
<select name="find_state" id="find_state" onmousedown="return true;">
This also enables the event to fire first time the user changes the value of select. Otherwise it would fire only on second onchange event.
I'm having trouble understanding conceptually what I should do while trying to make my first large Javascript web application.
Depending on which tab a user has selected, I show different content inside a container. The content is more than just text and uses different Javascript functions and events. I am using the Yahoo! UI Library's "TabView" implementation, but the way that this issue should be handled would probably apply to other Tab approaches.
What I was thinking of doing was basically the following:
Create separate modules for each tab (e.g. MYAPP.modules.tabCalendar and MYAPP.modules.tabJournal). When the user clicks on a different tab (or navigates with browser buttons to a previous tab state), I could call MYAPP.modules[oldModule].disable() and MYAPP.modules[newModules].enable(). These functions would subscribe or unsubscribe their custom events (for example, a general click handler attached to the container).
An alternate approach to dealing with events might be to have a single global click handler. If the click is inside the container, then determine which tab is currently selected and send the click event to MYAPP.modules[currentTab].onClick().
Or, the global click handler could fire a Custom Event to which the modules have subscribed since page load, and each module's onClick events will run and determine whether or not they should do anything.
There seem to be a lot of options, but I've been having trouble finding resources that talk about the best ways to do things like this. Am I on the right path? How should I handle this?
Use the events already built into TabView to queue your JS to do things.
http://developer.yahoo.com/yui/tabview/#handlingevents
For tab changes you'll be told the previous/next tabs selected and such which should be more than enough for your JS to figure out what it should do. If you want to write a translation layer that'll look at the events and do something based on it that's fine but it's not strictly necessary.
I'm a bit fuzzy on the problem.
Yes, you should modularize your code.
Have each module setup event handlers on the elements in their respective container.
That's it. YUI TabView handles the tab switching so you don't need to enable/disable anything.