Does the framework provide enough information to determine how long it took to load a page?
In order to do so, one would need to know two timestamps:
The request to load content.
Content loaded.
Is there is a way to register a callback for both/one-or-the-other?
Another option, however inaccurate, is to poll for a DOM element to be added. Is there a specific one that can be used reliably for this?
My current reason for wanting this information is quite silly. I want my splash screen to show for an extra second if the loading time was very short. But, I can see this playing a part in performance testing.
The client engine is written using GWT, so it’s not even possible to use the resulting code from outside.
We made some JS internal API to be able to call some functionality from pure JS but this is quite limited.
I don’t see any possibility to get such notifications even via GWT code and as I mentioned there is no JS entry points for
anything like that.
Content loaded
This I don’t even understand in fact. There can be one request to do some changes on the client side and that may cause a number of subsequent requests.
E.g. Grid is not loaded via just only one request. There is one initial request to add Grid element and then there are a number of service requests to fetch data for it.
Technically it’s possible to say about : request and the end of its processing in the client engine.
But as I said it doesn’t mean that the content is in fact loaded in the end of the request processing.
So may be it’s soemthing that doesn’t make sene logically.
Denis Anisimov:
I believe you are talking about the client side.
The client engine is written using GWT, so it’s not even possible to use the resulting code from outside.
We made some JS internal API to be able to call some functionality from pure JS but this is quite limited.
I don’t see any possibility to get such notifications even via GWT code and as I mentioned there is no JS entry points for
anything like that.
Content loaded
This I don’t even understand in fact. There can be one request to do some changes on the client side and that may cause a number of subsequent requests.
E.g. Grid is not loaded via just only one request. There is one initial request to add Grid element and then there are a number of service requests to fetch data for it.
Technically it’s possible to say about : request and the end of its processing in the client engine.
But as I said it doesn’t mean that the content is in fact loaded in the end of the request processing.
So may be it’s soemthing that doesn’t make sene logically.
I understand that the rendering details would be known to the client. Are they not sent to the server at any point?
Server sends the commands to the client what to do: create an element inside this element and set attributes/properties to it.
Client doesn’t send anything to the server rendering related. It just sends the property updates and results of requested JS execution (if any) including registered listeners for actions (like button click).
Nothing else is sent.
Denis Anisimov:
Server sends the commands to the client what to do: create an element inside this element and set attributes/properties to it.
Client doesn’t send anything to the server rendering related. It just sends the property updates and results of requested JS execution (if any) including registered listeners for actions (like button click).
Nothing else is sent.
That makes sense. I suppose the information I am asking about does not NEED to be sent to the server.
Can the client engine be extended in some form without modifying the Vaadin source? I suppose the server would also need to be extended to receive new information sent by the client.
But shouldn’t the client inform the server that it has began listening for events, so that the server can be ready to accept events from the client?
There is no way to extend client engine code without modifying the source code.
It’s written using GWT and I cannot even say how you may call this generated JS from pure JS without hacks.
Theoretically you may replace methods in objects with your own and then delegate to the original methods.
So that could have been hooks.
But as I said: it’s GWT generated code. So I cannot say even whether you may get any references to the objects.
Server is ready to accept messages with given type once you register a listener with this type on the server side.
The server side sends the command to the client side to register a listener on the client side and stores some information which allows accept messages with the given type.
There are quite limited predefined meta-types of messages which server may accepts.
E.g. it accepts the messages about even listeners registered on the client side: this is the meta-type. And the type here (which is dynamic) is the client side even type.
You may not ask the client side to send enything you need to the server side and the server side will not accept any kind of message. Every time every meta-type requires new code on the server side for RPC handler and code on the client side.