We are currently working to improve the usability and information architecture of the web-based admin console. By taking part in a short exercise you will help us better understand how users interpret the information and accomplish their goals.
You do not need to be an expert of the console to participate in this study. The activity shouldn’t take longer than 10 to 15 minutes to complete.
To start participating in the study, click on the link below and follow the instructions.
Circuit provides an uni-directional data flow model for GUI applications. It’s intended to be used with GWT, but can be leveraged in any Java GUI framework.
It resembles the ideas of the Flux Architecture that can be found in the React.js framework, but adds certain semantics to the data flow model.
For a general introduction and problem statement we’d recommend to look at the Flux documentation first. The specifics of the Circuit implementation will be explained in the following sections.
Core Components
Data Flow Model
View components (presenters in this case) dispatch actions through central dispatcher. The dispatcher coordinates the processing of actions across stores. Stores process the data or state change associated with an action and emit change events once they are done. Interested parties (presenters) read the data of the store and update the views accordingly.
Actions
Actions represent behaviour, data and state within an application. They signal state changes to the dispatcher, which in turn coordinates the processing of actions across stores.
Actions are most often initiated from user interaction, but they are not limited to that. It’s also possible that the underlying framework or the service backend creates and dispatches actions.
Dispatcher
The dispatcher acts as a central hub for processing actions. Any action passes through the dispatcher and the dispatcher delegates it to the Stores, that do ultimately process the Action.
The Dispatchers main responsibility is to coordinate the processing of Actions across Stores.
Stores
Stores keep the application state and act as proxies to the data model used by an application. Most often stores interact with service backends to read and modify a persistent data model, which they in turn expose in a read-only fashion to the actual view (or presenter-view tuples in MVP).
Stores are registered with the Dispatcher for Actions they are interested in. They can directly rely on the data passed with an Action, or listen for state changes in other parts of the data model.
Stores do emit Change Events to interested parties that rely on the data or state managed by a particular Store.
Presenter (as in MVP)
The Presenter (or presenter-view tuple as in MVP) creates and dispatches Actions. This happens on behalf of a user interaction, due to framework events or another signal from the service backend.
Presenters listen to Store Change Events and in turn read data from Stores and update the views accordingly.
Presenters do only have read-only access to Stores and the data they maintain. Any modification to the data or state of an application has to be driven by Actions.
Processing Semantics
One of the core problems Circuit addresses are cascading effects of event based applications.
In a typical GUI application an event triggers some business logic, model update or state change, most often as a result of user interaction. Events can trigger other events, which leads to unpredictable data flow, hard to diagnose problems and unclear application semantics.
The guiding principal in Circuit (and Flux) is provide a framework with deterministic behaviour that allows you to hook into the data flow at any point and know exactly what steps will executed next.
The uni-directional data flow described above already provides a good baseline, but Circuit adds some specific semantics to the contract between the core components, which will be described in the next sections.
Action Sequences
Any Action flows through the Dispatcher and the dispatcher coordinates how the Stores process the actions. In Circuit we use a sequencing dispatcher, that ensures only one Action will be processed at a time.
If two Actions are dispatched simultaneously the later one will be queued. All Stores that are registered for a particular Action type will process the Action and once the group completes the next Action will be taken of the queue.
This way Actions don’t create race conditions when updating the state or data of an application.
Store Interdependencies
Typically a single Store maintains a particular segment of the data or domain model in an application and the relevant state associated with it. On most applications Stores don’t exist in isolation, but depend on other model parts to perform their work.
Circuit allows you to express dependencies between Stores on the level of an Action type.
Preparation and Completion phase
The Circuit Dispatcher processes Actions in two phases: a preparation and a completion phase.
During the preparation phase Stores signal interest in a particular Action type and any dependencies they have on other Stores for a particular Action type.
The Dispatcher creates a dependency graph for each action type and invoke the Stores in an ordered way, one at a time.
This way Stores can safely rely on the State of other Stores during the processing of an Action.
Upon completion a Store emits Change Events to signal interested parties that the data or state of the application has changed. Since Stores process the Action in an ordered way, the change notifications follow that pattern.
Action Acknowledgement
Many Store implementations rely on asynchronous invocations to the service backend. Circuit was build to provide support for asynchronous flow control in Stores.
When Stores complete the processing of an Action, they acknowledge the Action they processed. This signals the Dispatcher that the next Store can start processing the Action.
Howdy! This is an example blog post that shows several types of HTML content supported in this theme.
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum. Sed posuere consectetur est at lobortis. Cras mattis consectetur purus sit amet fermentum.
Curabitur blandit tempus porttitor. Nullam quis risus eget urna mollis ornare vel eu leo. Nullam id dolor id nibh ultricies vehicula ut id elit.
Etiam porta sem malesuada magna mollis euismod. Cras mattis consectetur purus sit amet fermentum. Aenean lacinia bibendum nulla sed consectetur.
Inline HTML elements
HTML defines a long list of available inline tags, a complete list of which can be found on the Mozilla Developer Network.
To bold text, use <strong>.
To italicize text, use <em>.
Abbreviations, like HTML should use <abbr>, with an optional title attribute for the full phrase.
Citations, like — Mark otto, should use <cite>.
Deleted text should use <del> and inserted text should use <ins>.
Superscript text uses <sup> and subscript text uses <sub>.
Most of these elements are styled by browsers with few modifications on our part.
Heading
Vivamus sagittis lacus vel augue rutrum faucibus dolor auctor. Duis mollis, est non commodo luctus, nisi erat porttitor ligula, eget lacinia odio sem nec elit. Morbi leo risus, porta ac consectetur ac, vestibulum at eros.
Code
Cum sociis natoque penatibus et magnis dis code element montes, nascetur ridiculus mus.
// Example can be run directly in your JavaScript console// Create a function that takes two arguments and returns the sum of those argumentsvaradder=newFunction("a","b","return a + b");// Call the functionadder(2,6);// > 8
Aenean lacinia bibendum nulla sed consectetur. Etiam porta sem malesuada magna mollis euismod. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa.
Lists
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Aenean lacinia bibendum nulla sed consectetur. Etiam porta sem malesuada magna mollis euismod. Fusce dapibus, tellus ac cursus commodo, tortor mauris condimentum nibh, ut fermentum massa justo sit amet risus.
Praesent commodo cursus magna, vel scelerisque nisl consectetur et.
Donec id elit non mi porta gravida at eget metus.
Nulla vitae elit libero, a pharetra augue.
Donec ullamcorper nulla non metus auctor fringilla. Nulla vitae elit libero, a pharetra augue.
Vestibulum id ligula porta felis euismod semper.
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.
Maecenas sed diam eget risus varius blandit sit amet non magna.
Cras mattis consectetur purus sit amet fermentum. Sed posuere consectetur est at lobortis.
HyperText Markup Language (HTML)
The language used to describe and define the content of a Web page
Cascading Style Sheets (CSS)
Used to describe the appearance of Web content
JavaScript (JS)
The programming language used to build advanced Web sites and applications
Integer posuere erat a ante venenatis dapibus posuere velit aliquet. Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Nullam quis risus eget urna mollis ornare vel eu leo.
Tables
Aenean lacinia bibendum nulla sed consectetur. Lorem ipsum dolor sit amet, consectetur adipiscing elit.
Name
Upvotes
Downvotes
Totals
21
23
Alice
10
11
Bob
4
3
Charlie
7
9
Nullam id dolor id nibh ultricies vehicula ut id elit. Sed posuere consectetur est at lobortis. Nullam quis risus eget urna mollis ornare vel eu leo.
We’ve spend the last three month working on the access control facilities for the wildfly management layer. Brian has created series of introdcutionary videos that explain how to setup and configure your wildfly system to enforce role based across control across all management entry points, including the web console:
Due to my recent interest in scala and FP topics, I decided to collect the most intersting articles that I stumble upon. They are shared as a flipboard magazine. Drop me an email if you want to contribute to it.
