According to the XForms specification most events are said to "bubble".
As per the DOM Level 2 Event Specification an event that "bubbles" means that the handlers for this event associated with ancestor elements of the event dispatch target will also receive this event.
For an event to be specified as "bubbles" it means the xf:dispatch action cannot modify the bubble behavior to limit it to the target.
I don't understand what the benefit is of so many xforms events to bubble. For example, xforms-select and xforms-deselect. They apply to xf:item (of xf:select*) and xf:case (of xf:switch, i.e., used in a form with tabs).
Let's say I have an xf:case with an xforms-select handler that will cause a refresh on an expensive rendering widget, just when the tab is actually selected rather than every time the model is updated. Now I also have an xf:select in that same tab. Now whenever the user selects another item in that selection, the xf:case would receive the xforms-select at the bubble phase, doing the costly update operation every time.
This doesn't seem to make sense.
In fact xforms-node-attached has it right: we really want to be specific as to which form element gets the node attached. But apart from that, most events are said to bubble.
I could conform myself better with this issue if I understood the reason for this. Otherwise I am tempted to change my XForms engine to change the definition of xforms-select and xforms-deselect not to bubble.
This is to allow what is known as event delegation:
"Event delegation refers to the process of using event propagation (bubbling) to handle events at a higher level in the DOM than the element on which the event originated. It allows us to attach a single event listener for elements that exist now or in the future." (from an older version of this jQuery doc page)
In general, this is a good thing:
You use less event listeners.
A listener can listen on multiple targets.
You don't need to remove/add listeners as DOM elements are added/removed.
It seems that, in the HTML world, things have moved towards letting everything bubble. For example, the old focus event didn't bubble, and the newer focusin event bubbles.
If you have an event handler which gets activated by events dispatched to multiple targets, in some cases you need the ability to discriminate. This is where event context information is useful. Libraries like jQuery also allow you to associate an event handler filtered by CSS selector, which is neat.
Now in the case of xforms-select specifically, your issue is that you cannot discriminate between this event dispatched to an xf:case vs. an xf:select. This might mean XForms shouldn't have a single event for these two scenarios, or it should have enough event context information to discriminate between the two. I don't think that this is making a case for not letting the event bubble.
Related
I would like to stop the propagation of any taghelpers linked to a tag. I have a attribute based taghelper that I use to check whether the user can see or use a tag, and based on that I would like to stop any further processing to happen.
output.SuppressOutput();
does not work in this regard.
Some more detail.
I have a grid that has rows and actions per row ( actually there are other types of actions, ie on the grid etc) the rendering of the actions happens using a grid renderer.
The actions are added to a context that is provided to the grid via the items property.
I have another taghelper that can be placed on any tag element which determines whether the user has rights to see the element or whether it is disabled. This taghelper is first in the hierarchy.
Now since the actual action taghelper doesn't render itself, the grid renders it, I can't suppress the output of the action, as it continues to the next taghelper in the hierarchy and adds it to the context.
I would like it stop executing the taghelper hierarchy and not add it to the context, without being able to stop the execution I have to now pass whether the action should be displayed or disabled along in the context and update all my various renderers code to handle this. Stopping the exectution is much simpler and touches a lot less code.
I'm building a GWT application with a Tree.
Every tree items represent an object which has a boolean attribute that we can set through a checkbox displayed in the tree item itself.
I have a selection handler to do some stuff on my tree which gets called on click on every tree items.
What I want to do, is to prevent selection event to firing up when I'm clicking on the checkboxes ...
However, checkboxes don't have a SelectionHandler, so I tried to put a ClickEventHandler with event.stopPropagation(), but SelectionHandler is still getting called ...
EDIT: actually SelectionHandler is getting fired before ClickEventHandler anyway ...
Thanks in advance
You might consider following this method provided in the GWT documentation here. That should do the bit what you are interested in.
Try using the separate click handler for the checkbox and use the event.StopProgation() there after inorder to prevent the event bubbling.
For stop propagation from child's event to parent in GWT you need to use
event.stopPropagation();
What is a trigger function with respect to event driven programming? And especially with regard to vb6.
I have searched microsoft documentation as thoroughly as I can and come up with a blank.
Triggers are common in DB environment (SQL Server, etc). As far as I know, there are no triggers in VB6 per se.
You can apply a trigger on a table to perform a certain task when data in that table changes (a new record inserted, etc).
More info on SQL Server triggers
There is no such thing as a "trigger function" in VB6. I think you have misunderstood the wording a bit.
An Event is the concept of something that happens in the application, like a button click, mouse move, form load, etc.
Each Event may be handled by an Event Handler, which is a function that is executed when a given event occurs on a given object, e.g. Button1_Click for handling the Click event on a button named Button1. Note: This function is called Handler function, not Trigger function.
An Event may be Triggered (more often called Raised), which means that an object indicates to the environment that the event has occurred. In the above example, the button named Button1 Triggers/Raises the Click Event.
My project is using Wicket's AjaxFormValidatingBehavior to auto-save form content to Session on sort of a multi-tab form with a tree menu (there is no save button on individual tabs, though there is a "Save" button that actually submits the form, runs the validations and saves contents to database). I am facing few issues:
Since the behavior is added to all form components' onChange event, there is a server-trip every time user moves from one field to another. I know that a throttle duration can be specified to prevent this, but its not possible to set in my case as my forms are of different lengths/complexity, many components dynamically generated (including the tree menu). But is there a more elegant solution to auto-save form content (that doesn't have a submit button) rather than this annoying solution.
Another issue I am facing is that post onChange event, on Firefox the component loses its focus after the "server trip" ends. While on IE7 it works fine.
For the first question I think you need to add a pipelining facility, on your components' onchange call a javascript function of your which calls your webapp. You can include a feature similar to the one provided with the throttle duration but page-wide (delay each calls and only trigger the last if it is older than x milliseconds for example).
For the second one, I think you have to use the AjaxRequestTarget#focusComponent in your behaviors, or handle this thing in your "wrapper" as described in the first answer.
When writing GUIs, I've frequently come over the following problem: Assume you have a model and a controller. The controller has a widget W that is used to show a property X of the model.
Because the model might be changed from outside the controller (there might be other controllers using the same model, undo operations etc), the controller listens to changes on the model. The controller also listens to events on the widget W and updates the property X accordingly.
Now, the following happens:
the value in W is changed
an event is generated, the handler in the controller is invoked
the controller sets the new value for X in the model
the model emits events because it has been changed
the controller receives a change event from the model
the controller gets the value of X and sets it in the widget
goto 1.
There are several possible solutions for that:
Modify the controller to set a flag when the model is updated, and not react to any events from the model if this flag is set.
Disconnect the controller temporarily (or tell the model not to send any events for some time)
Freeze any updates from the widget
In the past, I usually went for option 1., because it's the simplest thing. It has the drawback of cluttering your classes with flags, but the other methods have their drawbacks, too.
Just for the record, I've had this problem with several GUI toolkits, including GTK+, Qt and SWT, so I think it's pretty toolkit-agnostic.
Any best practices? Or is the architecture I use simply wrong?
#Shy: That's a solution for some cases, but you still get a round of superfluous events if X is changed from outside the controller (for instance, when using the command pattern for undo/redo), because then the value has changed, W is updated and fires an event. In order to prevent another (useless) update to the model, the event generated by the widget has to be swallowed.
In other cases, the model might be more complex and a simple check on what exactly has changed might not be feasible, e.g. a complex tree view.
The standard QT way of dealing with this and also the one suggested in their very useful tutorial is to make the change to the value in the controller only if the new value is different from the current value.
This is way signals have the semantics of valueChanged()
see this tutorial
Usually you should respond to input events in the widget and not to change events. This prevents this type of loop from occuring.
User changes input in the widget
Widget emits change event (scroll done / enter clicked / mouse leave, etc.)
Controller responds, translates to change in the model
Model emits event
Controller responds, changes value in widget
Value change event emitted, but not listened to by controller
Flags to indicate updaing work. You can wrap them in methods like BeginUpdate and EndUpdate.