In working on modifying the samples so that they will run from their own subdirectories in a single project, I am adding a lot of using statements. Typically, I am finding that I want to add
using as most of thise are done. This seems like it might be a pretty standard best practice, i.e.,
1. The name of the class should include the full path from the PROPATH root.
2. Normally, one would provide a using statement to the containing directory since the contents of a subdirectory will typically be strongly related.
In the WinGrid/SamplesExplorer case, it is a little more complicated since there are two subdirectories another level deeper -- DataServices and DataSources (also Graphics, but there is no code there) -- plus a number of classes in the SamplesExplorer directory itself. I'm not sure I would choose to put code on multiple levels like this, but I'm not going to argue that point at the moment.
In the DataServices subdirectory, the classes typically have:
using Progress.Lang.*.
using DataSources.*.
using WinGrid.SamplesExplorer.DataServices.SportsService.
class DataServices.CustOrderService inherits SportsService :
This raises a couple of questions. I am inclined to modify the second and third line to:
using WinGrid.SamplesExplorer.DataSources.*.
using WinGrid.SamplesExplorer.DataServices.SportsService.
but might one also typically want to use:
using WinGrid.SamplesExplorer.DataServices.*.
since this is a collection of related classes? And, if so, I presume that the line with SportsService can then be dropped.
What do people think of the style of pointing to the individual class versus the directory? As it happens in this case, there is only the one class in that directory, so there isn't much impact, but I am thinking in terms of style. I.e., if I am organizing my code into directories by relatedness in a systematic way, should my typical using statement point to the directory or should it only do that for the local directory and using statements for other directories should be as specific as possible?
I'm rather new to this oo/classes stuff but I would like to see the USING as a sort of "application (code) fixed sub-propath". Also because the ABL classes are organized into subdirectories.
So I would use the .* syntax.
Also there are no code changes if one would add classes to the subdirectory...
I prefer to point to the full namespace/package using the USING abc.xyz.* syntax.
I'm used to that from C# and I believe in Java also the full package get's imported. As I always try to avoid ambigious class names, I've never had a problem with that.
I see this like Simon as a lokal extension to the propath. And I also try to avoid any mix and match with Propath entries. My classes (most of them ) are in a Namespace directory Consultingwerk..... relative to the project root.
The only time, that I use a USING statement with the full class name is for Progress.Windows.Form to avoid confusion (in my own brain and in the compiler) with System.Windows.Forms.Form.
By the way: When it comes to DYNAMIC-NEW, I use fully quallified classes. I've never tried if DYNAMIC-NEW follows the using directive. But when storing the class name in a database table (menu structure or as an attribute in the ICFDB) you never know, if the program using this class name is compiled with the same USING statements.
+1. I agree with you Simon.
One way in which USING doesn't seem to quite behave like a subPROPATH extension is as follows.
Given a directory structure of WinGrid/SamplesExplorer with subdirectories below this of DataServices and DataSources.
Given a using statement in a class in WinGrid/SamplesExplorer of
using WinGrid.SamplesExplorer.*.
If one then has a line:
define private variable fCustOrderDataSource as DataServices.IDataService no-undo.
That does not compile. Instead, one has to also provide
using WinGrid.SamplesExplorer.DataServices.*.
and then
define private variable fCustOrderDataSource as IDataService no-undo.
Is that a bug or just the way it works.
Nop, doesn't work like that...
From the ABL reference:
For both ABL and .NET object types, you can only reference class names for classes, interface names for interfaces and so on) that are defined in the specified ABL package or .NET namespace. For example, you cannot reference partially qualified class names for classes in packages that are further defined under the specified package. To reference the class names of classes in other packages, even those that appear to be subpackages, you must specify an additional USING statement for each package.
Like I said ... not quite a subPROPATH.
No, there is the restriction mentioned above. But I do like to think the USING is an extension to the propath... Also because the USING is directly reflecting the directory structure. I also like the FROM PROPATH syntax. But yes maybe sub-propath is the wrong term. And I also don't want people to arbitrarily choose (less) meaningful class name like they where subdirectories so...
In the WinGrid/SamplesExplorer case, it is a little
more complicated since there are two subdirectories
another level deeper -- DataServices and DataSources
(also Graphics, but there is no code there) -- plus a
number of classes in the SamplesExplorer directory
itself. I'm not sure I would choose to put code on
multiple levels like this, but I'm not going to argue
that point at the moment.
Well, you kind of just did...
In any case, keep in mind that the beta samples were posted as separate standalone samples and that the structure is a result of this. A "real" implementation would very likely have DataSources and DataServices elsewhere.
We've decided to try to make the samples into one project for FCS and we might move these elsewhere. But they will still probably reside in the same project. In a "real" implementation one might have adapters, services and data sources in separate projects.
One of the benefits of the new launch configurations is that you can have (and build) visual code and services in a project with no db connection and only have data access code in a project that is connected. You can still launch the visual objects with a db connection. I have not tried this and it is possible that one might find it too much of a hassle to have to check the database connection for the launch configuration of visual classes, but a separation like this can have many benefits. You might for example avoid the e- prefix on your temp-table names in your services.
Note the latter approach requires that you have full control over your build and always build without db connections when written without db connections.
Message was edited by:
Attempted to clarify that the decision is to try to make the samples into a single project. There's no guarantee that the samples will be in a single project for FCS (or ever for that matter).
Havard Danielsen
Well, pretty soon I will have them working that way, if you would like me to give them back to you.
Thanks for the offer, but my versions have some fixes that you don't have and I also have several new samples.