Jump to content

10 general design questions...


chefdackel

Recommended Posts

Starting a new project with UniGui I want to be sure to understand the main aspects of GUI design with UniGUI. Please correct me if there is something wrong with these statements or if there is general better design of some facts. Thank you!

 

==========================

1. If possible avoid the use of free forms - because they are not framework controlled and the use of variables, (unigui-)controls etc. in these forms are not thread safe.

==========================

2. When using an unigui wizzard created application form, the framework controls the thread safe use of variables, (unigui-)controls etc which are part of this application form. So when defining a "myvar"variable in the public part of the application form class, this variable can be accessed around the session which creates the application form, and no further attention has to be turned on shielding it from other sessions.   

=========================

3. Not every third party control which is used in application forms is automatically thread safe - if the control itself is not designed in this matter, there may be problems when using them in an internet application. An example may be printing tools/controls.
 

==========================

4. Because application forms are instances of UniMainModule, every session which creates this form has its own instance of the form, f.e.:   

function Form_Upload1: TForm_Upload1;
begin
  Result := TForm_Upload1(UniMainModule.GetFormInstance(TForm_Upload1));
end;
 

==========================

5. Data access components are to be placed in UniMainModule or a Datamodule which is created with the UniGui wizzard, so this Datamodule has also to be an instance of UniMainModule.
 

==========================

6. For data access its ok to put the grid, the query and the datasource on an application form, only the database connection component itself has to placed on the UniMainModule or UniMainmodule controlled Datamodule.
 

==========================

7. Application forms never have to be created manually. As soon as something on the application form is accessed UniGui will create the form. So when I want to init some data access on the application form its ok to build a procedure "OpenData" in the application form (assuming query and datsource are on the application form). When calling myAppForm.OpenData f.e. from the MainForm the application form will be created from UniGui and can be shown with myAppForm.show:

procedure TmyAppForm.OpenData
begin
  Query1.open;
  Query2.open;
  Query3.open;
end;

The best place to clean up data access then is in the OnClose event of the application form:

procedure TmyAppForm.OnClose
begin
  Query1.close;
  Query2.close;
  Query3.close;
end;
 

==========================

8. When closing the application form with myAppForm.close the form and the ressources are freed UniGui controlled.
 

==========================

9. It is ok to use some kind of "global variables" as long they are defined in the UniMainModule. So every session has its own set of these (session-)global variables.   
==========================

10. I have a GUI model where in the mainform there are the buttons "customer" and "product". When I click on the "customer"-button, an application form is created. On this application form I have a panel which is the parent of different frames. When first displayed there is a "list"-frame created with a grid which lists the customers. When I want to edit a specific record, I close the "list"-frame and create a "detail"-frame where the detail data can be edited. After posting the data the "detail"-frame is closed and the "list"-frame is created again. Data access components grid, query and datasource for the grid are on the "list"-frame, data access components query and datasource for the data edit components are on the "detail"-frame. They use the same data connection component on the Datamodule. On every creation of a frame I open the queries, when closing a frame I close the queries. The question is: because of using frames (with the panel parent on an application form) and the described data access, is this model still recommended and thread safe?        
 

brfc

 

  • Upvote 3
Link to comment
Share on other sites

For 10, I prefer to put the list grid and other controls on a panel. When showing detail frame I make this panel invisible and show detail on top of it, when closing detail frame I make list visible again. Less queries opened, reduced delay and immediate update of changed fields in the list (if using Post on the same dataset as in list). Good for mfPage full screen applications to use all the available browser space instead of messing with forms and their size.

  • Upvote 1
Link to comment
Share on other sites

For 10, I prefer to put the list grid and other controls on a panel. When showing detail frame I make this panel invisible and show detail on top of it, when closing detail frame I make list visible again. Less queries opened, reduced delay and immediate update of changed fields in the list (if using Post on the same dataset as in list). Good for mfPage full screen applications to use all the available browser space instead of messing with forms and their size.

 

thank you for pointing to this alternative, maybe I did it too complicated. 

 

So all logic is implemented in the MainForm of UniGUI, where you have two (2) panels as parents of the list and detail frames? As far as I see the ApplicationForms are instances of the MainModule which deals with the different sessions, and the MainForm is also an ApplicationForm. Ok, its not the same but something similar my approach, only that I use different Application forms and in the form only one (1) panel as the same parent for the list and detail frame.

 

That takes me back to my point (10) of the initial post, that we don't have to deal with threads and sessions, and components and variables in the list/detail frames when modelling programs this way, all this session shielding stuff is managed by the UniMainModule?  

 

brfc

Link to comment
Share on other sites

About thread handling in UniGui: it is simple!

 

Don't use global vars, instead of that use fields/properies (in the form-/module-/anyOther-class definition)

 

Then each session accesses only objects in its own thread (controled by UniGui) and you never read/write memory used by other sessions. Each session has ist own instances of all.

  • Upvote 1
Link to comment
Share on other sites

  • Administrators

Answers in bold:

 

 

Starting a new project with UniGui I want to be sure to understand the main aspects of GUI design with UniGUI. Please correct me if there is something wrong with these statements or if there is general better design of some facts. Thank you!

 

==========================

1. If possible avoid the use of free forms - because they are not framework controlled and the use of variables, (unigui-)controls etc. in these forms are not thread safe.

 

 

The only difference between a Free Form and an App Form is that App Form is automatically created for you when you need it. There is no difference in thread-safety.

==========================

2. When using an unigui wizzard created application form, the framework controls the thread safe use of variables, (unigui-)controls etc which are part of this application form. So when defining a "myvar"variable in the public part of the application form class, this variable can be accessed around the session which creates the application form, and no further attention has to be turned on shielding it from other sessions.   

 

Correct. They are naturally thread-safe because you can only access forms and modules which are part of your session

=========================

3. Not every third party control which is used in application forms is automatically thread safe - if the control itself is not designed in this matter, there may be problems when using them in an internet application. An example may be printing tools/controls.
 

Correct. There are two main issues with 3rd party controls:

1) They use global variables which makes them not thread safe.

2) They use VCL controls internally which again is not thread-safe.

 

==========================

4. Because application forms are instances of UniMainModule, every session which creates this form has its own instance of the form, f.e.:   

function Form_Upload1: TForm_Upload1;
begin
  Result := TForm_Upload1(UniMainModule.GetFormInstance(TForm_Upload1));
end;

 

Correct. UniMainModule keeps track of forms and modules which belongs to that session.
 

==========================

5. Data access components are to be placed in UniMainModule or a Datamodule which is created with the UniGui wizzard, so this Datamodule has also to be an instance of UniMainModule.
 

Data access components can be placed on both Forms, MainModule or Datamodules which are created with the UniGui wizzard,

Actually it is better to only put the Connection on MainModule and put your Queries on respected Forms. It will help you to save memory if your queries return large data.

 

==========================

6. For data access its ok to put the grid, the query and the datasource on an application form, only the database connection component itself has to placed on the UniMainModule or UniMainmodule controlled Datamodule.

 

Correct. See above.
 

==========================

7. Application forms never have to be created manually. As soon as something on the application form is accessed UniGui will create the form. So when I want to init some data access on the application form its ok to build a procedure "OpenData" in the application form (assuming query and datsource are on the application form). When calling myAppForm.OpenData f.e. from the MainForm the application form will be created from UniGui and can be shown with myAppForm.show:

procedure TmyAppForm.OpenData
begin
  Query1.open;
  Query2.open;
  Query3.open;
end;

 

Yes. We should not forget to call show or showModal right after referring the Form name.

The best place to clean up data access then is in the OnClose event of the application form:

procedure TmyAppForm.OnClose
begin
  Query1.close;
  Query2.close;
  Query3.close;
end;

 

Correct.
 

==========================

8. When closing the application form with myAppForm.close the form and the ressources are freed UniGui controlled.

 

When FreeOnClose is True (default) Form is destroyed. Same is true for Free Forms too.
 

==========================

9. It is ok to use some kind of "global variables" as long they are defined in the UniMainModule. So every session has its own set of these (session-)global variables.   

 

If you define them in MainModule they will not become truly Global, but we can say they are global for that session. You are correct. If you need global variables you must put them in uniMainModule public section.

==========================

10. I have a GUI model where in the mainform there are the buttons "customer" and "product". When I click on the "customer"-button, an application form is created. On this application form I have a panel which is the parent of different frames. When first displayed there is a "list"-frame created with a grid which lists the customers. When I want to edit a specific record, I close the "list"-frame and create a "detail"-frame where the detail data can be edited. After posting the data the "detail"-frame is closed and the "list"-frame is created again. Data access components grid, query and datasource for the grid are on the "list"-frame, data access components query and datasource for the data edit components are on the "detail"-frame. They use the same data connection component on the Datamodule. On every creation of a frame I open the queries, when closing a frame I close the queries. The question is: because of using frames (with the panel parent on an application form) and the described data access, is this model still recommended and thread safe?        
 

There is no thread-safety issue here. Regardless of your visual design, all calls to your session will always run in a single thread (not in same thread though).

 

brfc

  • Upvote 5
Link to comment
Share on other sites

  • 1 month later...
  • 1 year later...

Well.Old Thread really interesting subject.

 

,Still don´t get why frames are so much better than forms, I don´t think they´re more reusable,at least not now 

in Unigui 099.Am I wrong?Would like to see an example where frames are better than forms.

 

I liked Perjanbr Desktop 3 example.

 

Marcello

 

Update:I think frames should be used in the place of panels,specially in master-detail relationships,

To show contents when people click in a button,I mean, those screen with many tabsheets and master-details

relationships when the user will not be interested in all of them,but there is a button to show them,what

i did with panels in a traditional desktop applicattion,these panels were invisible and showed when needed.

The difference is that with frames they will be created at run time.

Link to comment
Share on other sites

Also I think that Querys belongs to Datamodule,if it consumes some bytes more(during a short time)

and therefore decreases scalability a little bit,

thats life,scalability is a non-functional requirement that can be reached in other ways like load balancing,you should

close your querys when they´re not needed any more though.

I create many things at run time,since I´m a clientdataset lover,I use clonning,indexing and everything else.

Saving memory is important,But you should not sacrifice load time(and therefore user experience),

People cares more about intermediate screens than the initial loading time,

I won´t complciate my design too much in order to meet

this non function requirement,its a question of balancing the pros and cons,I myself don´t like ORM in every single aspect for instance.

 

Other thing to take in consideration is the scalability neura that has taken the market by assault in the last 5 years.

What kind of product do you produce,Enterprise apps,ERP? If so your application should not be multi-tenant,the vast majority of

your consumers won´t go to the cloud,and you´re sacrificing your design for a scalability that will never be needed.

Do you think to do something like www.amazon.com, so enourmous scalability ,node.js and so on are mandatory.

 

 

Also for companies that want to migrate their existing stuff to the WEB,keeping the querys in the datamodules,by using you own parser/Translator or something like the Delphi Parser,and therefore turn uniGui in a more mainstream

framework.

 

 

 

Marcello

Link to comment
Share on other sites

Another thing I really prefer free forms,because I think you can have several constructors

for the same form,something really useful when you want the same form to act in different ways(Polymorphism).

In fact without it you just can´t use it to interface with mainframes,in banks and credit card companies,where

people have a functionality named workflow.

Also free forms are just like Delphi way,so easier to import existing systems to uniGUI.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...