Re: [Wt-interest] New signal and slots implementation
Abdiel,
This looks really good !
> My problem now is that I can't seem to find a way to
> prevent event signals from firing away every time
> there is an event from the mouse/kb. Currently, Wt's
> behaviour is starting to become as real-time as
> Desktop toolkits. Now this is bad for web apps! I
> noticed that Wt is now generating lots of signals (see
> attached HTML source for Hello World).
> Basically, what I did was derive from my Signal and
> Slots classes and re-implemented the rest of the
> methods in your WSignalInstance/WSLotInstance
>
> Perhaps, was it because the static slot functionality
> was gone? What are your thoughts on these?
No, what basically went wrong is that the code that
protects the signal from being 'implemented' as an event
handler is apparently broken. For example,
see WWebWidget.C : updateSignalConnection(...):
if (isConnected(s))
element.setEventSignal(eventName, *s, argName, condition);
else
element.removeEventSignal(eventName);
where isConnected(s) is implemented as s->isConnected();
Have you implemented this method ? It should keep track of the
fact that at least one slot has been connected to the signal.
> I also have some questions. (1)Does
> WebSession::handleRequestData() read in/convert to
> pointers all signals embedded in the HTML page or only
> event signals (i.e, exposable set to true)? (2) What's
> the purpose of the std::set exposedSignal on
> WApplication other than determing if a signal
> isExposedSignal()?
The idea of isExposedSignal() is a basic security check: it
is to filter invalid from valid signals, to make sure a hacker cannot
just execute arbitrary slots which are internal to your application.
Other than that, it does not add any functionality. You should expect
that signals that are exposed get really exposed. This code is
irrelevant except in the light of security.
> (3) What actually determines when a signal declared on
> C++ code gets to embed (as s0xdeadbeef HEX) in the
> HTML page and fired by the user?
The signal->isConnected().
> About that static slot thing, I'm thinking about
> replacing the idea with dynamic caching of the
> JavaScript code. This way, users would no longer have
> to manually specify an 'undo' method evyerytime they
> want a good-performing slot.
That is true. Still, the first call will still be slow. I am not sure
how good I can judge whether this would feel 'bad' or 'good',
unless we try the implementation. I thought of going for three
options:
1) dynamic slot, default
2) static slot, auto-learn
3) static slot, pre-learn, with undoMethod() provided.
> I really would like to hear your insights on how the
> internals of Wt works. I have traced your code but I
> think it would still be best to here from you. I hope
> to release code as soon as the kinks get ironed out!
In fact, if you feel that way, I am happy to finish the code
where it delves more into Wt internals...
Great work, I must say. I am sure it was harder than expected
since Wt was a bit too much interwoven with the
current signal/slot implementation !
Regards,
koen