status and messaging for systems with a large number of classes
Very common dilemma we coders face when creating
systems involving a large number of classes:
Any standard framework to take care of the global status of the whole application and of gui subsystems
for both status handling and report messages to users?
Something light if possible...and not too much threads.
[355 byte] By [
streiker] at [2007-9-27 13:56:20]

Hi,
perhaps I do not understand, what you are looking for as so I do not see, where your problem is. So I will try to give a general answer:
If you design your classes, think of transferring responsibility to them - a class is responsible for a clearly defined job - it does nothing more and nothing less. If you face the problem, that a portion of your classes will generate confusion perhaps, it is time to create a manager class, which is reponsible to manage the instances of these classes in order to get rid of this confusion.
Basically I would think about the design first - perhaps it is something wrong with its structure and it should be redesigned instead of making a manager class responsible for managing not well designed classes.
A well structured application should generate no confusion - the responsibilities are divided to portions which each class, which is responsible for it, can do its job perfectly. The principles of "divide and conquer" are basically the same as in a company - you assign certain task to employees (your classes) and use managers to make them work together. As in companies communication is very important - not noisy chat, information exchange - that is, what listeners are for. To control a big number of employees you will need a well organized information structure, and so it is with building a bigger application.
It is also a good idea to use a designing tool or design patterns for bigger applications - there are several tools out there, which can help you keep control over your application - BlueJ is also a good one to visualize things in this manner - especially to support team work - as so it is a teaching tool.
Hope, this helps - even so I am not sure, that this is the information, you wanted
greetings Marsian
Yes,
you guessed mostly.
What I need is a framework that keeps track of
1) what is the status at a certain moment in the application composed of say 11 big GUI areas each with its say 20 swing/awt buttons, containers, subcomponents
2)more the events they start and handle and which are completed or under execution.
3)And to know each moment which user and system activities are consented and which are forbidden,
4)and to know and ev. show the results to user...
Ah, I see,
I found JPanel with CardLayout or a JTabbedPane very good for control of several GUI in an application - as alternative organization tool I use a JTree, which is used for both, selecting and organizing certain tasks or data in the application - tasks are normally done with data associated with them (that is, what an object is for), so basically a click onto a node in this JTree invokes an interface method of that object (the userObject), which is associated with this node.
Event handling should be done by the event-handling-thread only as far as possible - it is responsible for it so leave this job to it. This will give you control over the order in which the events are handled. Sometimes it needs a bit more work to obey this rule - for example communication coming from the outside (think of a chat channel for example) must be converted to an event source driven by a thread normally. As soon as it is an event source, you can leave it's event handling to the event handling thread again and problems with concurrent programming are minimized again.
It is the same with manipulating components or models of components - leave it to the event handling thread using a Runnable and SwingUtilities.invokeLater(Runnable). This way you can be sure that each manipulation is done after the other in the order you have transferred it to the event handling thread.
When you do this consequently most of your threads will idle most of the time - so give them a break using Thread.sleep(...) - not all platforms provide preemptive multitasking and this way it is garanteed, that the event handling thread will get a chance to run most of the time - which results in fast GUI update and fast event handling.
Another thing is, that you should use "divide and conquer" also within a single GUI panel - place components in subpanels and transfer the responsibility for the components in this panel to exactly these subpanels - think of a team manager which makes his employees work together. He reports up to his super manager and transfers global order from his boss into specific tasks by delegation to the components, he is managing. If you have this in mind, when you design classes, you will have less problem - each class is responsible for a certain task - define it clearly and define to whom it is reporting (its listeners) and what these listeners may be interested in.
When you design the communication structure within your hierarchy of classes (directors, managers, team managers and workers) have in mind, that the communication structure should not break the management hierarchy. A director gives global orders to a manager, which delegates several tasks to the team managers, which make their workers do what is needed. This structure makes a big company controlable by directors - the same principles can also keep control within an application.
greetings Marsian
Thank you Marsian.invokelater() can be useful some time.But in general what I want to do is something like you describe in the second part of your reply.greetingsstreiker
if you are using an applet can anyone view it? If so how do you make sure of this?
> Thank you Marsian.
>
> invokelater() can be useful some time.
> But in general what I want to do is something like you
> describe in the second part of your reply.
Hm ... I mentioned that with invokeLater(...) not because it CAN be usefull - I mentioned it, because if you NOT use it, you will have to struggle with much more concurrent programming things as needed - transferring all actions, which should be done by the event-handling-thread to it, is a kind of synchronization on this thread and you will have to synchronize less methods this way and make your applciation less error prone. Also in terms of "responsibility" you should leave all things a class is responsible for to it - as far as possible. So when a problem occurs, you can think of "who is responsible for this?" and can find an error much faster and know, where to fix it.
How can I help you now?- Where is your concrete problem?-
greetings Marsian