Add JavaDoc mainly to SessionContext#64
Conversation
ChrisChros123
changed the title
| import java.util.function.Supplier; | ||
|
|
||
| /** | ||
| * Interface for handling any type of data source that can be represented as an InputStream. |
There was a problem hiding this comment.
This is true. However, the main idea is that Resources are meant to be downloaded by the client using HTTP. Therefore, they provide all the necessary HTTP header information in addition to the data.
|
|
||
| /** | ||
| * Provides access to several aspects of a Ui-Session and allows sending commands and updates to the client. | ||
| * A UI-session starts upon opening the website and ends when leaving or reloading it. The Communication between client |
There was a problem hiding this comment.
Nitpicking: Please use spaces for compound words like UI session.
| import static org.teamapps.common.util.ExceptionUtil.softenExceptions; | ||
|
|
||
| /** | ||
| * Provides access to several aspects of a Ui-Session and allows sending commands and updates to the client. |
There was a problem hiding this comment.
Represents a UI session and thereby ...
| * A UI-session starts upon opening the website and ends when leaving or reloading it. The Communication between client | ||
| * and server happens via websocket. | ||
| * Only one thread can interact with a Ui-Session at a time. Therefore, all interactions with the session context from | ||
| * outside must be done using the {@link #runWithContext(Runnable)} method. |
There was a problem hiding this comment.
You might also mention that
- events coming from the client are generally handled in a thread bound to the UI Session.
| * Provides access to several aspects of a Ui-Session and allows sending commands and updates to the client. | ||
| * A UI-session starts upon opening the website and ends when leaving or reloading it. The Communication between client | ||
| * and server happens via websocket. | ||
| * Only one thread can interact with a Ui-Session at a time. Therefore, all interactions with the session context from |
There was a problem hiding this comment.
Single thread access is important for mainly two reasons:
- to guarantee a certain order of events on the client and server side (most important: both process changes in the same order)
- because none of the UI Components is thread-safe
| } | ||
|
|
||
| /** | ||
| * @return the SessionContext which the thread, where this method is executed in, is bound to |
There was a problem hiding this comment.
... which the current thread is bound to
| /** | ||
| * @param runnable | ||
| * Executes the runnable within a thread that is bound to the SessionContext. | ||
| * This ensures thread safety by letting only one thread interact with a UI-session at a time. |
There was a problem hiding this comment.
Please also mention that the Runnable/Callable is not necessarily executed asynchronously but might actually be executed synchronously if the thread happens to be already bound to this SessionContext.
I also think that it makes sense to add the JavaDoc comment to runWithContext(Callable<R> runnable, boolean forceEnqueue).
| * in the <b>same</b> order)</li> | ||
| * <li>because none of the UI components is thread-safe</li> | ||
| * </ul> | ||
| * Therefore, all interactions with the session context from outside must be done using the |
There was a problem hiding this comment.
with the session context and any UI components
|
|
||
| /** | ||
| * @return the SessionContext which the thread, where this method is executed in, is bound to | ||
| * @return the SessionContext which the thread is bound to where this method is executed in |
There was a problem hiding this comment.
@return the SessionContext which the current thread is bound to
The rest of the sentence is redundant
2 participants
createResourceLInk was only moved to be next to createFileLink