Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Strange occurrence with a data source in a data module?


This question is answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 18 - Last Post: Sep 24, 2014 8:34 PM Last Post By: > Rich <
David Cox

Posts: 28
Registered: 7/6/07
Strange occurrence with a data source in a data module?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 17, 2014 12:43 PM
Hello All,

I don’t understand why this is happening.

I have a form that creates another form that has a data module as in:

Form1
Form2 with dmModule.Create(Form2)

The data module has a data source that is linked to a data aware combo box on Form2. Everything works!

Now, if the first form has the same data module as in:

Form1 with dmModule.Create(Form1)
Form2 with dmModule.Create(Form2)

The data aware combo box on Form2 no longer works. If I reassign the list source of the combo box on Form2 to the data source in the data module, it works:

cmbobxName.ListSource:=dmModule.dsDataSource; //This makes it work

Any ideas why the combo box needs its list source redefined? What am I missing?

Thanks for your help,

Dave

Edited by: David Cox on Sep 17, 2014 3:43 PM
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 17, 2014 12:57 PM   in response to: David Cox in response to: David Cox
David wrote:

Form1
Form2 with dmModule.Create(Form2)

If you are creating the DM in Form's constructor, make sure you use 'Self'
instead of the global 'Form2' variable.

Now, if the first form has the same data module as in:

Form1 with dmModule.Create(Form1)
Form2 with dmModule.Create(Form2)

The data aware combo box on Form2 no longer works.

The DataModule is linked to a DataSource that is linked to a ComboBox on
Form2. When you create Form1, Form2 has not been created yet, so Form1's
DataSource cannot link to the ComboBox.

For that matter, why are you creating the DataModule twice? I would suggest
you create the DataModule once and have Form1 and Form2 share it. Since
the DataModule has a DataSource linked to a ComboBox, you are trying to link
two separate DataSources to the same ComboBox at the same time. That does
not make sense to do.

--
Remy Lebeau (TeamB)
> Rich <

Posts: 171
Registered: 2/6/09
Re: Strange occurrence with a data source in a data module?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 17, 2014 2:50 PM   in response to: David Cox in response to: David Cox
David Cox wrote:

Now, if the first form has the same data module as in:

Form1 with dmModule.Create(Form1)
Form2 with dmModule.Create(Form2)

I want to bring up something and I hope I don't get bashed for it. But... Over the years I've noticed that all the dataset component sharing suggestions seem to be fruitless. It appears to me that the old apps I created by placing all the required dataset components right onto the form are holding up better to maintenance and extension. Some have suggested using one data module per form and that could be fine. But the idea of not duplicating some dataset components for the sake of smaller apps might be carrying with it more problems than solutions.

First as you can see from the OP's post the complexity increases even with just a small example. I've notice also that it's easier to pull out or replace a form with dataset components or a form with a one-to-one relations to a datamodule than it is to restructure shared data modules.

Maybe "intelligent forms" are something to re-think. Instead of working up complex answers to easy questions by trying to reduce all dataset components to a single sharable set. It might be better to just forget saving those 300 bytes and dup the ones needed to make it easier and quicker to provide a solution.

If you take the time to put coding aside and visualize your applications from 10,000 feet. You'll probably notice, as I have, that you don't really need to share datasets that often.

Thoughts?
Eduardo Elias

Posts: 319
Registered: 9/20/12
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 17, 2014 4:43 PM   in response to: > Rich < in response to: > Rich <
At beginning (delphi 1 - 3) I had these troubles until I understood how works
the binding process of the datasources etc.

I wrote them a big ERP that uses one centralized DataModule. And each form
when opened creates an instance of it. On the form I have a DataSource of
the tables needed connected to the datasets on the Datamodule.

After some other years, I have realized that RAD is a dangerous thing. Very
dangerous.

I know some companies that today are in big trouble because developers only
followed the original Borland idea, and still around with some of the old
guys of the team.... of double clicking a button and adding code right there.

Now I have completelly changed my mind on how to use delphi. It is fine to
use the visual rad part and interconnect things, like livebinding our datasources
with db edits.

But you should not have ANY code on the view.

true OOP needs to have some use of a framework created to hold your data
and rules.

Datamodule is not that. I still use datamodules, to place some DataSet and
give what is needed for the visual part of RAD works. But there is no code
and no use of events or anything on the datamodule. Just a fancy centralizer
container.

I am using MVP passive, as the best alternative I have found for developing
in Delphi.

For a simple coffe shop Rad application, it takes 10 times more work and
time to develop... however anything serious that needs to grow and changed
frequently, new versions across the years, it is the way to go.

I have my view totally isolated from the code, at point that i have different
views for different platforms using the same (presenter) code.

For me took some time to rewire my brain and forget the old delphi style.
I am now seeing that is a good thing.

David Cox wrote:

Now, if the first form has the same data module as in:

Form1 with dmModule.Create(Form1)
Form2 with dmModule.Create(Form2)
I want to bring up something and I hope I don't get bashed for it.
But... Over the years I've noticed that all the dataset component
sharing suggestions seem to be fruitless. It appears to me that the
old apps I created by placing all the required dataset components
right onto the form are holding up better to maintenance and
extension. Some have suggested using one data module per form and that
could be fine. But the idea of not duplicating some dataset components
for the sake of smaller apps might be ca

rrying with it more problems than solutions.

First as you can see from the OP's post the complexity increases even
with just a small example. I've notice also that it's easier to pull
out or replace a form with dataset components or a form with a
one-to-one relations to a datamodule than it is to restructure shared
data modules.

Maybe "intelligent forms" are something to re-think. Instead of
working up complex answers to easy questions by trying to reduce all
dataset components to a single sharable set. It might be better to
just forget saving those 300 bytes and dup the ones needed to make it
easier and quicker to provide a solution.

If you take the time to put coding aside and visualize your
applications from 10,000 feet. You'll probably notice, as I have, that
you don't really need to share datasets that often.

Thoughts?
> Rich <

Posts: 171
Registered: 2/6/09
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 17, 2014 7:31 PM   in response to: Eduardo Elias in response to: Eduardo Elias

I wrote them a big ERP that uses one centralized DataModule. And each form
when opened creates an instance of it. On the form I have a DataSource of
the tables needed connected to the datasets on the Datamodule.

That's another thing about sharing too much. The one centralized system becomes huge. Supporting every situation that can be thought of. Then if the situation changes the centralized system is so tangled that it's very difficult to change. But having different smaller systems makes it easier to replace any of the smaller parts.

After some other years, I have realized that RAD is a dangerous thing. Very
dangerous.

I think your equating RAD to something its not. RAD is just the drag-n-drop visual environment. The component framework can be implemented in many different ways. In other words I can create a set of components that implement any custom framework but until I make them drag-n-drop they are not RAD.

I know some companies that today are in big trouble because developers only
followed the original Borland idea, and still around with some of the old
guys of the team.... of double clicking a button and adding code right there.

But you should not have ANY code on the view.

That's extending things completely in the other direction. Logic in the form may be just where it should be. Having it in some central location loads up the back end. If you can send particular logic to a user in a form when that user(s) need it why keep it only running in a central location? I remember the fear developers had about making sure, for example, data is scrubbed correctly before storing it to the database. But I've always thought it was bad that the user is forced to wait until they try to apply their work before they get an error message about something they then have to go back to and fix. Having all the logic centralized makes things much easier for the programmer but then the user suffers.

true OOP needs to have some use of a framework created to hold your data
and rules.

The problem is with the world becoming so interconnected you cannot run one big server on an island centralized to everyone. This means logic must be sent to the user where it can be used. If you have rules on the server but someone wants to save data locally for a bit then they either need the rules locally or they will save erroneous data until it gets applied to the central server. That doesn't sound bad except in situations where the user acts upon the data they have locally before it gets applied to the central server where it is found to be erroneous.

Take for example mobile apps. They contain the logic for people to do their work. They are not just a view screen. And they are being used more and more everyday.

Datamodule is not that. I still use datamodules, to place some DataSet and
give what is needed for the visual part of RAD works. But there is no code
and no use of events or anything on the datamodule. Just a fancy centralizer
container.

So where is the logic? On the central server? And, if so, how do people who save data locally know their data doesn't fit in with the centralized rules before the post the data to the server?

For a simple coffe shop Rad application, it takes 10 times more work and
time to develop... however anything serious that needs to grow and changed
frequently, new versions across the years, it is the way to go.

But are you serving the programmer or the user?

I have my view totally isolated from the code, at point that i have different
views for different platforms using the same (presenter) code.

What is the user's experience? Are they getting the most features where and when they need them?

For me took some time to rewire my brain and forget the old delphi style.
I am now seeing that is a good thing.

I'm not sure exactly what you consider the old Delphi style. But if you think of forms, even ones with a corresponding data module, to be like mobile apps. How will the user get any features to use if there is no logic in the forms or the data module?
David Cox

Posts: 28
Registered: 7/6/07
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 6:32 AM   in response to: > Rich < in response to: > Rich <
Thanks everyone for your replies.

I am not sharing the data module as there are enough differences in what data is being presented to the user between Form1 and Form2. Form1 is a large presentation of data to the user and from there they can drill down into various other subsets of views and editing of this data (that is an oversimplification, but you may get the idea).

So if I want to create a separate data module for each form, my error is that I need to create (and destroy at form close) the data module with Self. That makes sense, thanks!

I struggle with the centralization of data and logic from the developer's standpoint, and balancing out the "user experience". I go with the best user experience which can complicate things a bit for me. I have yet to find the developer's holy grail solution, but then again that does keep me busy and usually out of trouble...

Thanks,

Dave
David Cox

Posts: 28
Registered: 7/6/07
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 7:07 AM   in response to: David Cox in response to: David Cox
I tried changing the data module to use .Create(Self) in the FormCreate and it did not resolve the issue. I still need to reassign the controls to the data source. So I am still stumped.
Peter Below

Posts: 1,227
Registered: 12/16/99
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 8:17 AM   in response to: David Cox in response to: David Cox
David Cox wrote:

I tried changing the data module to use .Create(Self) in the
FormCreate and it did not resolve the issue. I still need to
reassign the controls to the data source. So I am still stumped.

If you bind db-aware controls to a datasource/dataset at design-time
then the form with the controls on it will only work as intended at
run-time if the datamodule containing your dataset already exists when
the form itself is created. The form resolves the references to the
datamodule (which the designer has stored into the form resource) by
looking for the datamodule in an application-global list
(Screen.Datamodules) by name (value of the name property of the
datamodule). If you try to use one datamodule per form and still use
design-time binding you have to

- override the form's constructor (using the onCreate event handler
will not work, it executes too late!)
- create the datamodule instance before you call the inherited
constructor
- call the inherited constructor (which loads the form resource and
resolves the references to the DM)
- the set the Name property of the datamodule instance you created to
empty.

If you don't do this last step the next instance of the form you create
will bind to the already existing datamodule, not the one you created
for it.


--
Peter Below (TeamB)

David Cox

Posts: 28
Registered: 7/6/07
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 23, 2014 7:05 AM   in response to: Peter Below in response to: Peter Below
Peter Below wrote:
David Cox wrote:

I tried changing the data module to use .Create(Self) in the
FormCreate and it did not resolve the issue. I still need to
reassign the controls to the data source. So I am still stumped.

If you bind db-aware controls to a datasource/dataset at design-time
then the form with the controls on it will only work as intended at
run-time if the datamodule containing your dataset already exists when
the form itself is created. The form resolves the references to the
datamodule (which the designer has stored into the form resource) by
looking for the datamodule in an application-global list
(Screen.Datamodules) by name (value of the name property of the
datamodule). If you try to use one datamodule per form and still use
design-time binding you have to

- override the form's constructor (using the onCreate event handler
will not work, it executes too late!)
- create the datamodule instance before you call the inherited
constructor
- call the inherited constructor (which loads the form resource and
resolves the references to the DM)
- the set the Name property of the datamodule instance you created to
empty.

If you don't do this last step the next instance of the form you create
will bind to the already existing datamodule, not the one you created
for it.


--
Peter Below (TeamB)


Hi Peter,

What you say makes sense, however if what you explain is true, why does the follow work (and it shouldn't):

Form1 (creates Form2)
Form2 with dmModule.Create(self)

The Form2 data module has a data source that is linked to a data aware combo box on Form2. This should fail as the data aware controls are set to the data source at design time, but it works. As soon as I create the same data module in Form1, that's when it fails.

One easy way around this problem is to add a data source to each form that will be using the data module, bind the data aware controls to the form's data source, and then during the FormShow set the local form's data source's data set to he data module's date set. This requires a data source on each form that will have data aware controls, but adds nothing to maintaining the data module. I am leaning towards using this solution.

Thanks for your help,

Dave
> Rich <

Posts: 171
Registered: 2/6/09
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 23, 2014 8:29 AM   in response to: David Cox in response to: David Cox
David Cox wrote:

One easy way around this problem...

There you have it. Now you can move on and add more features!
David Cox

Posts: 28
Registered: 7/6/07
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 24, 2014 6:58 AM   in response to: > Rich < in response to: > Rich <
> Rich < wrote:
David Cox wrote:

One easy way around this problem...

There you have it. Now you can move on and add more features!

Right on!
Peter Below

Posts: 1,227
Registered: 12/16/99
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 24, 2014 10:01 AM   in response to: David Cox in response to: David Cox
David Cox wrote:

Peter Below wrote:
David Cox wrote:

I tried changing the data module to use .Create(Self) in the
FormCreate and it did not resolve the issue. I still need to
reassign the controls to the data source. So I am still stumped.

If you bind db-aware controls to a datasource/dataset *at
design-time* then the form with the controls on it will only work
as intended at run-time if the datamodule containing your dataset
already exists when the form itself is created. The form resolves
the references to the datamodule (which the designer has stored
into the form resource) by looking for the datamodule in an
application-global list (Screen.Datamodules) by name (value of
the name property of the datamodule). If you try to use one
datamodule per form and still use design-time binding you have to

- override the form's constructor (using the onCreate event handler
will not work, it executes too late!)
- create the datamodule instance before you call the inherited
constructor
- call the inherited constructor (which loads the form resource and
resolves the references to the DM)
- the set the Name property of the datamodule instance you created
to empty.

If you don't do this last step the next instance of the form you
create will bind to the already existing datamodule, not the one
you created for it.


--
Peter Below (TeamB)


Hi Peter,

What you say makes sense, however if what you explain is true, why
does the follow work (and it shouldn't):

Form1 (creates Form2)
Form2 with dmModule.Create(self)

Have you verified that the datamodule is not autocreated? That is the
default...


The Form2 data module has a data source that is linked to a data
aware combo box on Form2. This should fail as the data aware
controls are set to the data source at design time, but it works. As
soon as I create the same data module in Form1, that's when it fails.

One easy way around this problem is to add a data source to each form
that will be using the data module, bind the data aware controls to
the form's data source, and then during the FormShow set the local
form's data source's data set to he data module's date set. This
requires a data source on each form that will have data aware
controls, but adds nothing to maintaining the data module. I am
leaning towards using this solution.

Yes, that is a good solution.


--
Peter Below (TeamB)

> Rich <

Posts: 171
Registered: 2/6/09
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 9:13 AM   in response to: David Cox in response to: David Cox
David Cox wrote:

I struggle with the centralization of data and logic from the developer's standpoint, and balancing out the "user experience".

I haven't ever heard of a customer buying a product based on whether it used for loops instead of while loops or whether the data sets are in the data module or on the form.

I have yet to find the developer's holy grail solution

Purists will run you and everyone else including their self in circles over that. Don't be lazy, give your designs a good think, but then just provide the features users want by using what Delphi offers!
Eduardo Elias

Posts: 319
Registered: 9/20/12
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 24, 2014 2:41 PM   in response to: > Rich < in response to: > Rich <
one of the two: or i could not express myself, or you totally not understand
what I said !!

Based on your comments you seems to be old Delphi RAD guy somewhere Delphi
2 or 3 ;)

I wrote them a big ERP that uses one centralized DataModule. And each
form when opened creates an instance of it. On the form I have a
DataSource of the tables needed connected to the datasets on the
Datamodule.
That's another thing about sharing too much. The one centralized
system becomes huge. Supporting every situation that can be thought
of. Then if the situation changes the centralized system is so tangled
that it's very difficult to change. But having different smaller
systems makes it easier to replace any of the smaller parts.

Depends of what you call smaller systems. Many programs? Classes? What?


After some other years, I have realized that RAD is a dangerous
thing. Very dangerous.
I think your equating RAD to something its not. RAD is just the
drag-n-drop visual environment. The component framework can be
implemented in many different ways. In other words I can create a set
of components that implement any custom framework but until I make
them drag-n-drop they are not RAD.

I am saying what RAD was in the first versions of Delphi. I bought Borland
Pascal 6 that came with the very first Delphi 1 with it

It is all there, how to be RAD. Place a button on the Form, click twice and
write the code !!!! Are you sure you using Delphi all these years?

I know some companies that today are in big trouble because
developers only followed the original Borland idea, and still around
with some of the old guys of the team.... of double clicking a button
and adding code right there.

But you should not have ANY code on the view.

That's extending things completely in the other direction. Logic in
the form may be just where it should be. Having it in some central
location loads up the back end. If you can send particular logic to a
user in a form when that user(s) need it why keep it only running in
a central location? I remember the fear developers had about making
sure, for example, data is scrubbed correctly before storing it to the
database. But I've always thought it was bad that the user is forced
to wait until they try to apply their work before they get an error
message about something they then have to go back to and fix. Having
all the logic centralized makes things much easier for the programmer
but then the user suffers.

You are talking like Client/Server stuff. Wrong.

Central location is not a server. Try reading some MVP, MVVM or MVC stuff
and you will understand the differences on how to separete the layers

See, one thing is to have a server with data and logic. Other thing is how
you manípulate this and show this on your forms.

Right now I am sucessfully using VCL FMX and UniGui, 3 different frameworks,
with the same software. I need only to rewrite the View (the form). There
is no code at all on the view.

I can even implement partially the view in another framework, since the process
of control understand that.

You are confunsing things. User experience has nothing to do with the choosen
framework. User experience needs to be best always. If not you failed as
programmer. If you solelly rely on whatever you writing you failed. You need
to structure your software creating your framework first.

true OOP needs to have some use of a framework created to hold your
data and rules.
The problem is with the world becoming so interconnected you cannot
run one big server on an island centralized to everyone. This means
logic must be sent to the user where it can be used. If you have
rules on the server but someone wants to save data locally for a bit
then they either need the rules locally or they will save erroneous
data until it gets applied to the central server. That doesn't sound
bad except in situations where the user acts upon the data they have
locally before it gets applied t

There is nothing related to centralized server here. If you learn MVP for
example you will see that.

My logic is spread over the structure of my software, but in a way that each
layer only holds what is concerned for it. I dont use SQL server as a business
logic centralizer. I know you can do that, and almost write an entire software
based on SQL stored procedures and triggers.

My use of SQL is just plain. I have a ORM layer to deal with SQL. My software
has NO SQL AT ALL. But uses it, even queries. No more nightmares with those
strings with sentences, that once you change the database you need to go
across everything to change senteces strings. Take a look on Aurelius you
will see.


o the central server where it is found to be erroneous.

Take for example mobile apps. They contain the logic for people to do
their work. They are not just a view screen. And they are being used
more and more everyday.

Again, the thinking is not cliente/server only. This is basic. You do have
on the software Model, Viewer and Presenter. Each one doing its part. And
the Model contacts the server for data.

In my case my model Layer, uses Aurelius, that uses XData on the server side,
that is using Aurelius to create the bussines logic in the server side and
then finally the SQL Server.

All these layers reduce the complexity of each other layer. When you get
close the user things are easier. But again the view is nothing, it is just
a view, the presenter is what asks the model for data and gives to the view
on the right place.

Datamodule is not that. I still use datamodules, to place some
DataSet and give what is needed for the visual part of RAD works. But
there is no code and no use of events or anything on the datamodule.
Just a fancy centralizer container.
So where is the logic? On the central server? And, if so, how do
people who save data locally know their data doesn't fit in with the
centralized rules before the post the data to the server?

The logic is spread. Each place with the rules that are appropriate. but
not in the form

For a simple coffe shop Rad application, it takes 10 times more work
and time to develop... however anything serious that needs to grow
and changed frequently, new versions across the years, it is the way
to go.
But are you serving the programmer or the user?

I am serving my own interstest that is giving the best to the user with the
better from programming.

I have my view totally isolated from the code, at point that i have
different views for different platforms using the same (presenter)
code.
What is the user's experience? Are they getting the most features
where and when they need them?

I dont understand what is your problem, seems that you learned to count 1,
2, 3 and anything different of that causes fear.

Software is something you create the way you want. If you have a bad experience
for the user is because you wrote that way. So go there and write it correctly

For me took some time to rewire my brain and forget the old delphi
style. I am now seeing that is a good thing.
I'm not sure exactly what you consider the old Delphi style. But if
you think of forms, even ones with a corresponding data module, to be
like mobile apps. How will the user get any features to use if there
is no logic in the forms or the data module?

Here is the problem in your thinking, you are stuck on the Old RAD thinking.
You need to free your mind. It is a bondage.

I know I have been there.

I see people back on 2004 talking about crazy stuff like MVP and I did not
understand. Those where crazy people.

I losted some years not recycling myself. Get a good book of MVP, start learning
the Gang Of 4, not that I am pattern freak, you need to use what is better
for the situation, however since programs grow and fast you need to learn
from experince, from others..

I do not advocate RAD anymore, neither SQL centralization, I think that there
are different concerns and n-tier is that. But do not think about "modules",
it is most of the time "classes", layers of classes in your framework. My
software is basically Client/server if you see it far away, if you get closer
you will see litlle more layers. But inside it the thing changes a lot.
> Rich <

Posts: 171
Registered: 2/6/09
Re: Strange occurrence with a data source in a data module? [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 24, 2014 5:09 PM   in response to: Eduardo Elias in response to: Eduardo Elias
Eduardo Elias wrote:

Based on your comments you seems to be old Delphi RAD guy somewhere Delphi
2 or 3 ;)

Yes I started with Delphi v1 doing RAD stuff. Then I went through all the "code it up" undulations that most go through. Now as I look back on my older stuff. Some of it running 10+ years without changes. I wonder if all those efforts to be purist were really worth anything more than learning what else is available.

Depends of what you call smaller systems. Many programs? Classes? What?

Well most everything. One big program or one big unit or one big class isn't good. Look at mobile apps. If people would have created a dedicated data module for each form or master form. Something many here suggested against, myself included, at one time or another. The dev could easily pull out the dm and the related forms then with a little tweaking compile a mobile app. Now that's an awesome way to move a system to mobile! But with not wanting to use duplicate data set components and trying to reuse data modules across forms you have to more or less create a new mobile app from scratch. Or you have to untangle the connections. In other words the redundancy of the beginner is now a benefit.

Are you sure you using Delphi all these years?

Yes I'm fairly certain of it. Unless the world I live in doesn't actually exist. :-)

You are talking like Client/Server stuff.

I know the MVC approach. But I'm saying. Don't get stuck thinking about being a purist of one or another approaches for this discussion. Think first the user then worry about the implementation.

Central location is not a server. Try reading some MVP, MVVM or MVC stuff
and you will understand the differences on how to separete the layers

I understand those. I thought you were meaning one server.

Right now I am sucessfully using VCL FMX and UniGui, 3 different frameworks,
with the same software. I need only to rewrite the View (the form). There
is no code at all on the view.

So what kind of logic do you include with a mobile app? For example... If the mobile app user is entering some data and the business rules require all first letters of words to be capitalized. Must the mobile app post the data to the server before it will check the business rule of first letter capitalized?

User experience has nothing to do with the choosen
framework. User experience needs to be best always.

I think user experience is impacted by the framework sometimes. I agree that the ux should always be best. Like for example when using a browser app and I can't do any work because the internet went down. That's not the best and the framework causes that.

There is nothing related to centralized server here. If you learn MVP for
example you will see that.

I understand MVP. You're just proposing that it's the best. I'm not making that assumption.

I have a ORM layer to deal with SQL.

I like ORMs.

the Model contacts the server for data.

But, again, where is the ux logic? Do the screens the user interacts with need to post to a remote layer for all logic or is there logic on the mobile device?

When you get close the user things are easier.

But are they as robust? Can the user see a violation of the rules before they've finished a large screen and then posted their work?

The logic is spread. Each place with the rules that are appropriate. but
not in the form

So when are the rules applied? Can the user still run the app without being connected and sync when the connection is back?

I am serving my own interstest that is giving the best to the user with the
better from programming.

But if the user must be connected to find out if what they are doing follows the business rules then I would contend you're serving the programmer and not the user. The user should not have to be connected 100% of the time to work.

I dont understand what is your problem, seems that you learned to count 1,
2, 3 and anything different of that causes fear.

I would contend here that you only want to accept MVP.

Here is the problem in your thinking, you are stuck on the Old RAD thinking.
You need to free your mind. It is a bondage.

I understand. But just because you have moved to MVP and are stuck with it is not a valid argument.

I losted some years not recycling myself. Get a good book of MVP, start learning
the Gang Of 4, not that I am pattern freak, you need to use what is better
for the situation, however since programs grow and fast you need to learn
from experince, from others..

All that has happened is you've gone from RAD to another purist view. Here is the difference in our opinions. I don't want the framework to drive the ux. I want the ux to drive all the development.

I do not advocate RAD anymore, neither SQL centralization

I advocate giving the user the best experience possible then worry about the approach needed to accomplish that. We're getting a bit off topic. The most important thing at this point in our discussion is that RAD is not the framework. It is just the drag-n-drop. You can apply drag-n-drop to any number of different frameworks.

Sometimes a browser like approach is good. Like with these NGs. I don't want to keep data on my local machine to read and post here. But if you have a situation where a user must complete their work in the field with or without being connect. Then an approach that requires a connection is inferior.
Eduardo Elias

Posts: 319
Registered: 9/20/12
Re: Strange occurrence with a data source in a data module? [Edit][Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 24, 2014 6:35 PM   in response to: > Rich < in response to: > Rich <
My validation rules are spread over the layers :)

For example, as I am using ORM, the Entities are classes, not just records.
So the knowledge of UpperCase like you asked is up to the class to understand.

It can be hardcoded, then you need to recompile and create a new version
if you need to change.

Or you can store it on a config that the classes load that config and take
the right behavior. That config could be in a SQL server (via ORM either)

I am not a purist. However I am not in the middle. I dont know where is the
middle.

Right now I am using MVP, but besides I am pushing it on this talk, I dont
necessarily consider it the only option. You need to separate responsabilities
on your code, if you do that correctly you will fall on one of the patters.
So if you learn them helps. But I dont stick with them.

For example, I start using Observer partern and got bored with it... now
I use in very few places.

If I need to validate a complex form it will have levels of validation. Presenter
validate obvious things (that usually would be the view), the entity when
trying to be saved will validate itself and then the model will validate
the entity againt the business rules. That all on the client side. When using
server, I use the XData from TMS, where it adds a ORM layer behind it, so
that layer go more deep.

The SQL server only does the very basic Constraint rules validations. Nothing
else, so I can easily switch SQL servers.

When something goes wrong there is a error raising mechanism and go all the
way back to the presenter, where it brings the proper message to the user.

It is harder to write this way, thinking in one objective view/form. But
the result is solid and changes do not break things so easily.

My overall circle of development/testing/deployment is very different now.
Let say that 80% of the time is expent on Dev.

About the browser thing, in this case the user already understands that with
no connection, no work. So this is not an impact, at least in this case.

Centralization is not the probleme, I think, the problem is put the responsabilities
on the right places. It is design.

My 2 cents.

Eduardo Elias wrote:

Based on your comments you seems to be old Delphi RAD guy somewhere
Delphi 2 or 3 ;)
Yes I started with Delphi v1 doing RAD stuff. Then I went through all
the "code it up" undulations that most go through. Now as I look back
on my older stuff. Some of it running 10+ years without changes. I
wonder if all those efforts to be purist were really worth anything
more than learning what else is available.

Depends of what you call smaller systems. Many programs? Classes?
What?
Well most everything. One big program or one big unit or one big class
isn't good. Look at mobile apps. If people would have created a
dedicated data module for each form or master form. Something many
here suggested against, myself included, at one time or another. The
dev could easily pull out the dm and the related forms then with a
little tweaking compile a mobile app. Now that's an awesome way to
move a system to mobile! But with not wanting to use duplicate data
set components and trying to reuse da

ta modules across forms you have to more or less create a new mobile
app from scratch. Or you have to untangle the connections. In other
words the redundancy of the beginner is now a benefit.

Are you sure you using Delphi all these years?
Yes I'm fairly certain of it. Unless the world I live in doesn't
actually exist. :-)

You are talking like Client/Server stuff.
I know the MVC approach. But I'm saying. Don't get stuck thinking
about being a purist of one or another approaches for this discussion.
Think first the user then worry about the implementation.

Central location is not a server. Try reading some MVP, MVVM or MVC
stuff and you will understand the differences on how to separete the
layers
I understand those. I thought you were meaning one server.

Right now I am sucessfully using VCL FMX and UniGui, 3 different
frameworks, with the same software. I need only to rewrite the View
(the form). There is no code at all on the view.
So what kind of logic do you include with a mobile app? For example...
If the mobile app user is entering some data and the business rules
require all first letters of words to be capitalized. Must the mobile
app post the data to the server before it will check the business
rule of first letter capitalized?

User experience has nothing to do with the choosen framework. User
experience needs to be best always.
I think user experience is impacted by the framework sometimes. I
agree that the ux should always be best. Like for example when using a
browser app and I can't do any work because the internet went down.
That's not the best and the framework causes that.

There is nothing related to centralized server here. If you learn MVP
for example you will see that.
I understand MVP. You're just proposing that it's the best. I'm not
making that assumption.

I have a ORM layer to deal with SQL.
I like ORMs.

the Model contacts the server for data.
But, again, where is the ux logic? Do the screens the user interacts
with need to post to a remote layer for all logic or is there logic on
the mobile device?

When you get close the user things are easier.
But are they as robust? Can the user see a violation of the rules
before they've finished a large screen and then posted their work?

The logic is spread. Each place with the rules that are appropriate.
but not in the form
So when are the rules applied? Can the user still run the app without
being connected and sync when the connection is back?

I am serving my own interstest that is giving the best to the user
with the better from programming.
But if the user must be connected to find out if what they are doing
follows the business rules then I would contend you're serving the
programmer and not the user. The user should not have to be connected
100% of the time to work.

I dont understand what is your problem, seems that you learned to
count 1, 2, 3 and anything different of that causes fear.
I would contend here that you only want to accept MVP.

Here is the problem in your thinking, you are stuck on the Old RAD
thinking. You need to free your mind. It is a bondage.
I understand. But just because you have moved to MVP and are stuck
with it is not a valid argument.

I losted some years not recycling myself. Get a good book of MVP,
start learning the Gang Of 4, not that I am pattern freak, you need
to use what is better for the situation, however since programs grow
and fast you need to learn from experince, from others..
All that has happened is you've gone from RAD to another purist view.
Here is the difference in our opinions. I don't want the framework to
drive the ux. I want the ux to drive all the development.

I do not advocate RAD anymore, neither SQL centralization
I advocate giving the user the best experience possible then worry
about the approach needed to accomplish that. We're getting a bit off
topic. The most important thing at this point in our discussion is
that RAD is not the framework. It is just the drag-n-drop. You can
apply drag-n-drop to any number of different frameworks.

Sometimes a browser like approach is good. Like with these NGs. I
don't want to keep data on my local machine to read and post here. But
if you have a situation where a user must complete their work in the
field with or without being connect. Then an approach that requires a
connection is inferior.
> Rich <

Posts: 171
Registered: 2/6/09
Re: Strange occurrence with a data source in a data module? [Edit][Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 24, 2014 8:34 PM   in response to: Eduardo Elias in response to: Eduardo Elias
Eduardo Elias wrote:

Centralization is not the probleme, I think, the problem is put the responsabilities
on the right places. It is design.

Good discussion. I think it best to use the approach that provides the most features and the best ux. Delphi provides a framework. Of course we could always create a different one. But if it can be done with what you already have go for it!
David Cox

Posts: 28
Registered: 7/6/07
Re: Strange occurrence with a data source in a data module?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 7:05 AM   in response to: David Cox in response to: David Cox
Well I jumped the gun thinking that creating the module with Self would resolve the issue; it does not.
> Rich <

Posts: 171
Registered: 2/6/09
Re: Strange occurrence with a data source in a data module?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 18, 2014 9:25 AM   in response to: David Cox in response to: David Cox
David Cox wrote:
Well I jumped the gun thinking that creating the module with Self would resolve the issue; it does not.

If I'm understanding what your explaining I think you need to do this (not actual code just an explanation):

DataModule1.Create;
Form1.Create;
Form1.Show;

DataModule2.Create;
Form2.Create;
Form2.Show;

Or if it is your main form then you just set the data module to be created first in the project settings.

Keep in mind I haven't written much Delphi code for a few years but I did use it for many years before that. I think you're trying to package your data modules and your corresponding forms together. You're wanting the form to know which data module it needs and to create that when it needs to. Again "intelligent forms."

I'm not a programmer anymore. I'm a software developer. So I too focus on user features. But I've fought through all the purist stuff over the years. These guys here know their stuff but you need to ensure you explain you're not creating the all encompassing world changing do all be all platform.

Also if you need help and you're in the US let me know and I'll give you my contact information for direct help.
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02