I would like to suggest that PSC adopt a naming convention in published code going forward which makes it easier for us to work with samples and such. In particular, I would like to see all the code in a directory structure starting with com.progress under which should be major groupings like AdvancedGUISamples or AutoEdge, and directory structures under that appropriate to the complexity of the content. This would allow us to do things like install all the samples in one project and have them sensibly structured and for others to publish other samples which would articulate appropriately.
I think, there is also a need for an installer which will allow one to publish a subset assemblies.xml file and to update the project assemblies.xml.
A naming convention is absolutely desirable.
But at we are doing .NET frontend development, most classes we are dealing with follow the .NET (Microsoft) style of Namespaces/Namings.
System.Windows. ...
Infragistics.Win. ...
Progress.Windows. ...
Camel cased words, no domain prefix like com. or org. which I know only from Java style names.
Progress.AdvancedGUISamples. or Progress.AutoEdge. seem to fit better in the .NET world.
I think, there is also a need for an installer which
will allow one to publish a subset assemblies.xml
file and to update the project assemblies.xml.
You mean the Assembly References Tool?
I am all for that, and have no real preference although com.progress and com.dotr (as I have seen) will surely guarantee unique names as these are unique domain names.
I already regret my new company name: Future Proof Software.
Using com.futureproofsoftware looks a bit awkward but it seems the only possibility. Any other ideas?
Perhaps the reason you see the tla.domain convention in Java and not in .NET is because it isn't Windows-centric. I see no reason for ABL to use Windows-centric standards.
I suppose the question is what are you using for your web site. I decided to go with cintegrity.com instead of computingintegrity.com because of length so my code is all in com.cintegrity.
I guess I am stuck with futureproofsoftware.com since all possible abbreviations are taken.
BTW I agree with your point that this should be a convention independent of windows, so my vote goes to com.futureproofsoftware.
Windows-centric. I see no reason for ABL to use
Windows-centric standards.
It's a little too late for avoiding "Windows-centric" standards.
We are already using Progress.Lang.Error, Progress.Lang.AppError, Progress.Lang.SysError and so on. Progress.Data.BindingSource and Progress.Windows.Form and Progress.Windows.UserControl will become famous very, very soon.
I will not code in a way, that I have
USING Progress.Data.* .
USING Progress.Lang.* .
USING Progress.Windows.* .
USING System.Windows.Forms.* .
USING Infragistrics.Win32.* .
and some
USING com.progress.*
at the beginning of my source code. That would only lead to the fact, that a developer has no chance to remember the namespace for a particular class. I'd rather be proud of having a unique, clear naming convention for all class files I'm using in ABL code than beeing proud of not to being Microsoft addicted...
Everybody is free with his/hers decision here. But within a company it should be uninque. And it looks that within PSC that is Progress.* when it comes to classes accessible to ABL code.
I know there are Java portions of the tool using the com.progress namespace (OEA, WSA, AIA, ...). But we don't use those objects in ABL code - I'm sure you will correct me if I'm wrong...
Message was edited by:
Mike Fechner
You mean the Assembly References Tool?
I hadn't stumbled into that yet ... and now that I have, I'm not sure what I'm looking at!
I hadn't stumbled into that yet ... and now that I
have, I'm not sure what I'm looking at!
The ART is for updating assemblies.xml files but I don't think that is what you were looking for...
There are a couple of things which don't quite gel for me here ... and obviously they are for a bunch of the rest of you since you are busy working with new controls.
One simple thing that it seems like I might want to do is to merge two assemblies.xml files, e.g., to create a combined one that works with all the samples.
Do I take in in practice that one can use either the ART or the Assemblies tab in Project properties to point to a control and that is the way that one adds it? Wouldn't one then need to merge this into a global file for the application?
FWIW, it doesn't seem to me that this is a great way to manage this information. Yes, it means that one can have only one file to maintain, but the flip side is that one has no easy way of determining which controls are used where.
Hmmm...
In Microsoft Visual Studio there is the concept of a "solution" that contains one or more projects that are possibly related. So in Eclipse the workspace is on the same level as the solution in MS Visual Studio (?). With multiple project that can be related to each other. Or is a workspace more directly related to the user? (would be limiting the number of levels).
A workspace can be for example a test environment for customer XYZ (?) that contains separate projects for the GUI front-end, WEB front-end and back-end software. The GUI client needs an assemblies.xml file, the WEB client and server software probably not.
The assemblies.xml is located in the project root directory but can be redirected to an alternative location be specifying the -assemblies parameter on the project properties page, OpenEdge, Startup parameters thus giving the possibility to "share" assemblies.xml files between projects if needed.
Or is the project the "solution" that contains folders for gui, web and server? So you can have for example the development, test and production environment in one workspace. All folders/application components sharing the same assemblies.xml file even when for example "server" does not need any .NET references...
Or with the OpenEdge samples: one project "samples" with one assemblies.xml file and different directories for each sample. Or one project and assemblies.xml file per sample?
BTW
If you add a control to a form the assembly references are automatically added.