I want to set up several ui elements based on system information at the time of the application start up (i.e. this is info not known a priori so to set it statically in the css or the fxml file).
Is the controller constructor the best place to do this?
A first consideration was to do that either on the start() or init() methods of the main class that extends Application but it seems the set up is rather preventing programmer from easily accessing ui elements all the way down the node hierarchy. (which on the other hand is extremely easy in the respective controller through the #FXML injection)
It depends on the kind of work you need done. If you need anything that relies on your application's stage, then perform it in the start method. If not, then it can be performed in the constructor, init, or start methods. Bear in mind that the launching mechanism expects Application subclasses to provide a no-arg constructor, so if you incorporate startup logic there, then avoid requiring constructor parameters.
However, if you're going to use a controller (which I would recommend), then this logic should occur in its initialize method, not in your application class.
If you need a reference to the stage from the controller, then you can find many such solutions to passing the reference to the controller here on SO, such as making the stage reference public and static in your application class, or having such a field in your controller that can be set from your application's start method.
Related
VS2015 shows how many references there are to a class.
However if the class is started by WebApplication.Run the references are not shown.
The highlighted code does get executed when the application is run.
Is there any way to get the reference count for the Configure method?
Here are two reasons ;)
The Startup Class is invoked by reflection (it does not implement an interface)
I doubt that code pieces outside of your local source code will influence the reference count. So even if somewhere deep in WebApplication.Run the Configure method is invoked (assuming directly over some magic interface), the reference code will not rise. Make sense, otherwise the counter for string would have overflow ;)
I have a long running data processing application. Depending on the data it sees, I may want to start up a JavaFX application window (or it may never start-up one). How do I pass in my cached data?
e.g. in Swing, I'd have had a constructor that might look:
class MyFrame extends JFrame{
public MyFrame(BlobOfInMemoryCachedData manyMegabytesOfData){
this.data = manyMegabytesOfData;
// create JPanel, etc. using that data
...
}
}
Based on this answer: https://stackoverflow.com/a/24611918/155631, I can imagine non-standard-looking-java workarounds. Before I bake the usage of such workarounds into the application design, I want to verify: Is there really no cleaner way to directly pass the object handle?
Very quick because I haven't got time to write a proper answer with sample code:
In the main for your long running Java application, call the JavaFX application launch method once (and only once for the entire lifetime of your application).
Call Platform.setImplicitExit(false).
In the start method of your JavaFX application don't show a window.
Provide a static accessor on your JavaFX application show(data) which passes your blob data.
The show(data) method displays a JavaFX window for relaying data processing info in a UI.
When necessary call a static hide() method on your application which hides the JavaFX application window.
Continue processing, performing steps 5 and 6 (showing and hiding the window as needed).
When everything is finished call Platform.exit().
Key thing is that the JavaFX application is only launched once and you invoke a static accessor on it as needed to show the window. The set implicit exit false stuff prevents the default behavior of the JavaFX runtime shutting down when the last window of the application is hidden (so it just chugs along in the background waiting for a signal to show something again).
You could simplify things a little bit by having the your data processing application just extend the JavaFX Application class, but you might want to keep them separate for ease of testing or other design reasons.
Your other option is to use JFXPanel, but that adds an unnecessary Swing dependency, so I'd advise against that.
I am working on a very large game project in Symfony, and keep running into variations of the same problem.
I have a service that I need to separate into multiple "sub-services" because there is too much code to be contained within one class. For instance, a custom JSON serializer handler that needs a separate handler service for each method of serialization.
I'm having trouble working out the best practice for passing dependencies between "families of services." I would preferably like to keep all the definitions within services.yml just so things don't break in the future, but am assuming that may not be achievable.
Here's a better example - I have an "ActionQueueService" which takes a rather lengthy queue of actions from the user. What I would like to do is create a separate class to handle each type of action, so -
ActionQueueService // processes action queue JSON and delegates to sub-services
AbstractAction
PurchaseAction extends AbstractAction
SellAction extends AbstractAction
HarvestAction extends AbstractAction
Now if these three "actions" are defined as services they can have their own dependencies. However, they all have to be injected into the ActionQueueService - what happens if there are 38 of them (which there will be one day).
The next logical step for me was to create ActionFactory. Now I'm only passing in one dependency to ActionQueueService, and it can invoke any action service simply by calling -
$this->actionFactory->get('Harvest');
The problem I have is that each child has it's own separate list of dependencies. A Purchase or Sell action would need the Character service and the ShopStock service, a HarvestAction would need the HarvestService. Because I've decided to use a Factory method, I have to instantiate the sub-service within the factory class. I don't want to pass every dependency into the Factory only to have that either a) inject every dependency into every child or b) handle some crazy child constructor logic.
One solution would be to pass the service container into the factory and come up with a naming convention that allows me to create the service on the fly. I've heard that this is fairly bad practice though. Maybe a wrapper around the service container that limits the amount of bad stuff that could be done with it.
If anybody has any ideas on how this could be solved with Symfony I'd appreciate it. There are similar answers out there but unfortunately I don't know any languages other than PHP/Symfony.
In a MVC architecture the model is used to store data used in the application. I create a class and use some static properties to store data so that it can be used throughout the application. For example if there is a datagrid, I use a static arraycollection in model class. Update it whenever a service is called and by using databinding update the dataprovider of the datagrid. I have read that singleton class can also be used to accomplish this task. Is the way I use for model class is better or there exists some other ways too?
As the discussion Tianshen referred to points out, there is hardly any difference between a bunch of static variables and a Singleton. Both can be seen as a form of global variables, with all the accompanying downsides. I'm not going to argue about how Singletons are evil here; plenty has been written about the subject already that you can easily find on the web.
However, I would like to present an alternative: Inversion of Control (IoC), also referred to as Dependency Injection (DI). I'll explain this pattern in short, but you can also find plenty of information for yourself. Take the ArrayCollection from your example; if you'd want to avoid the static variables or the Singleton pattern, you would have to create one instance and pass that instance around from object to object throughout your application and perhaps it would even have to be passed through an object that doesn't really need it, which wouldn't be very clean either.
In comes the IoC container (for a Flex app it would take the form of library you add to your project): with such a library, you can create/configure that ArrayCollection in one place and let the IoC "inject" that single instance in whatever class that needs it.
A concrete example: we might have a configuration file like this
<fx:Object>
<s:ArrayCollection id="myLetters">
<fx:String>A</String>
<fx:String>B</String>
</s:ArrayCollection>
</fx:Object>
and a class like this
public class MyClass {
[Inject(id="myLetters")]
public var letters:IList;
}
The IoC container would then inject the myLetters ArrayCollection instance whenever a MyClass would be instantiated. There are a lot of other injection techniques, but this example is just to give you an idea.
At the time of this writing I belive Parsley to be the most widely used IoC container for Flex.
You may read the this discussion that compares Singleton and Static. Though it is in C#, the similar Object-Oriented philosophies apply.
In short, Singleton gives you better flexibility. If you use Databinding for your Flex application, using Singleton would allow you to inherit EventDispatcher, with which you can dispatch custom change events. Custom change events would give your application better performance.
Ok, so I know that global variables are considered bad, and the singleton pattern is overused. And I have read in many places that a class should do only one task and contain only those variables that allow it to accomplish that one task. However, while working on my latest project, I actually thought about these rules before writing any code and have noticed that I tend to break them at the very beginning of the program.
I'm currently working on an MFC dialog based application, but this question could be applied to any UI driven application. I have separate classes that handle state machines, file reading/writing, and hardware interfacing. All of these objects will need some type of UI control or property display/editing. In the MFC dialog applications, the dialog is the program, so it must exist until the program is closed. I've usually just put the objects in the main dialog class for the application and had the dialog class serve double duty; as both the main UI and the home for all other objects in the application. In other applications, I've created these objects globally and referenced them from wherever they were needed. Neither of these ways seem correct. The first option breaks the one class, one task rule, and the second relies on globals and also creates hidden dependencies. I could institute some type of dependency injection, but where would all these variables that I would inject reside?
I'm just wondering what others do to organize their programs without breaking the rules?
I find that storing singletons as public data attributes of the main dialog class of an MFC dialog application works OK for a quick and dirty program. However, as the program becomes larger and more complex, things begin to get untidy.
The point where storing singletons in the dialog class needs to be refactored is probably when you start passing pointers to the dialog around, so that other classes can access the singletons it contains.
The singletons can be moved into the global namespace. This is still a bit untidy, especially when there are a large number of them. Since you have to write a separate extern for each one in a header file then define each one somewhere, you soon end up with something that looks a lot like an old fashioned C program.
A neat thing to do is to make use of the singleton that the framework has already defined for you.- the application object which is always called theApp, a specialization of CWinApp. If you place your singletons as public data members of this, then any code can get easily get access to them .
Suppose that you called your application “solver”. The dialog application creation wizard will create a class CsolverApp. Now suppose you have a singleton called ‘theData’ an instance of the class ‘cData’.
Place your singleton in the theApp
class CsolverApp : public CWinApp
{
public:
cData theData;
…
Now to access this from anywhere in your code
#include “solver.h”
theApp.theData.somepublicmethod();
It does make sense to look at this from the MVC (Model - View - Controller) viewpoint. (That the naming of MFC is an homage to MVC is another sick joke on Microsoft's part; it is hard and unintuitive (but by no means impossible) to manage the types of abstractions that are necessary in "true" MVC within MFC.)
Specifically, it sounds like you've thought out the basis for MVC design; you have the classes that do the underlying business logic work (the Model), and you know they should be separated from the UI components (the View). The issue that comes in now is the third part of the MVC trinity; the Controller.
MFC makes this stuff tough by apparently purposefully obfuscating the MVC process, by making you start with a Dialog. In your instance, the Dialog that MFC is starting you off with should be the Controller, and NOT the View. What your Dialog (Controller) is doing for you is managing your UI components (View) and allowing them to interact with your "work" classes (Model). What makes this tough again is that your UI components, to be visible, most likely need to be attached to your Dialog to be visible.
To get this sort of thing right, you really have to basically implement your Controller as a high-level object that gets instantiated from your Dialog; your Dialog is where the initial control flow comes in, your Controller gets control flow, and from there, it should treat the Dialog as just another UI component (albeit one with special status).
This allows you to have the proper level of encapsulation; your Controller invokes your business logic (Model) classes, which can communicate with each other or with the Controller as appropriate; they are segregated from the View by the Controller, instead of being embedded in the UI components and (likely) taking the "easy way" of over-privileged access to UI elements ("Hmm, I need this object to get some input from the user; I could refactor, but it'll be so much easier to just throw a dialog box up, since I have the top-level window handle...").
Once your Controller object is the home to all of the business logic objects, things become easier; you can use the Controller to provide cross-object access for any objects that need other objects. Think about which classes need to be Singletons, and use them sparingly. Resources that need contention management (such as hardware resources) are great examples of "natural singletons"; things which lend themselves to a singleton approach. You may also choose to make your Controller a singleton; depending on the requirements for access to it. Specifically, in your Dependency Injection scenario, the Controller is where you'd instantiate the objects and manage the dependencies.
This is the basic MVC approach; but, like I say, MFC makes it unusually hard and unintuitive, because of the fundamental design of MFC. I learned MUCH more about MVC AFTER an initial VERY negative impression about it due to MFC; if you can, I recommend looking into what MVC implementations look like in other languages.
Good luck!
If I am understanding you correctly, it sounds like the lifetime of your dialog objects is too long. Rather than maintaining the dialogs for the duration of your program, you should consider creating and destroying them as they are needed.
Also, global variables (or singletons) are OK so long as the thing that the variable represents is truly a global thing that persists for the lifetime of the program, rather than just a place-holder for an object of lesser duration. Using globals for the wrong things for simplicity sake will come back to bite you eventually, even if the globals are stored on the main dialog.