Classes as data sources

[jkwrpc]

This is a spin off of the question about CLR.

I have long wondered if there is a way to use classes with the .Net namespace to create business objects that are data sources for A5 v11. This was a common practice for me in when using VB.Net. I liked it because it made the object reusable and easy to troubleshoot and maintain. I just don't see how I can to a similar thing in A5. Have I missed something? So far as I can find, I must use a table/set and not a dataset/recordset returned by a data class.

If you cannot do this, it does seem like this is a missed feature. To be able to work with classes in either xBasic or within the .Net framework namespace, in this way, would be a nice/huge addition.

[pulsoft]

Re: Classes as data sources

Hi John

I think this might be what you are looking for.

http://wiki.alphasoftware.com/Genera...romWSDL+Method

Hope it helps, it's all a mystery to me.

Paul

[jkwrpc]

Re: Classes as data sources

Paul -
Thanks for the response, but its not quite what I am after, I am looking for something different. Classes are objects like a table or a layout is an object. If A5 could use classes as a data source in lieu of tables it would be cool. It allows me to create a logic layer filled with reusable objects/classes. I could for example create a single data class that would handle every type of data transaction with customers. I could have do a all my CRUD stuff in one place, plus more. Once my class is built I can instantiate/reference the class and then work with it and its properties, functions and subs. It will give me a form of code completion, consistency, etc. It may seem a lot of extra work, but the reward is over time. If I need to make a change because something in the database has changed. I make the modification in the class and its done. I don't about changing a query or filter in place it exists in my app that is impacted by the change. This is only the beginning... but right now it must not be possible or someone from Alpha would surely have mentioned it could be done.

Just thinking out loud, as the saying goes.

[mronck]

Re: Classes as data sources

Hmm. Thinking a little bit down your line of thought John, it seems necessary to begin with the difference between Alpha Five and any OO-oriented language. Which is of course, that Alpha Five is build on xbasic, which delivers a rather linear programming method, as opposed to the .Net method which implements Object Oriented programming by which you programm with objects and instances of classes. This difference in basic thinking makes it very hard to "use" Alpha to create something near OO.

Second thing to mention is, that objects are entities used in OO-based software to represent a particular part of the system. Since the presence of data in an object is only an implementation technique, one could say that the Alpha Five table and sets are somewhat comparable with Objects.

Third thing to mention would be, that classes are abstract descriptions of sets of objects, used to contain the descriptions of the behavior of the objects it represents. Hence, you could see the Alpha UDF (...maybe.... in some way....) as a class.

Now, it's your turn again John....

[pulsoft]

Re: Classes as data sources

Data Model Binding - dynamic classes connection makes for “unbreakable” development. Because everything is so closely tied to the model and the business logic – the datastore classes, the methods, etc. – each part is synchronized with the other. If you change the behavior of a class or an attribute, it will automatically be reflected everywhere. Each connection carries all of its inherent logic with it, so when you update the back end, you won’t have to redo your front end, and vice versa.

Look guys, I can write hieroglyphics too...

Paul

[mronck]

Re: Classes as data sources

You don't need to if you use UDF's as well.... hieroglyphics or not is all a matter of perspective, isn't it?

[jkwrpc]

Re: Classes as data sources

Marcel - I know that operationally A5 gets the job done. I also understand UDF's are out there. In the end the argument is why even do object oriented programming but that is an old argument. But let's face it object oriented programming is not a new idea. Classes are just one part of the object list. If we go back to VB6 few people worked with classes, generally they liked to stuff everything went into the Main Module and I do mean everything. Maintenance could easily become a nightmare; it often was ugly out there, but it worked.

Classes, which I believe can be overdone, helped sort out that messiness. Somebody changes a datatype or wants to change a datatype, easily done at one spot. Look I know I talking to someone who has worked with objects and classes. In the past I found them to be a convenient clean way to layout and implement an app. Necessary no, but do they add a nice layer of functionality and ease of maintenance...to my way of thinking yes. It can move us from client - server to n - tier apps.

Now personally, I would like to see you arguing for the ability to use business objects (data classes) as data sources for A5 apps! :)

A5 as an object oriented development system, that can run on CLR would perhaps be the game changer and moving us/it to compete with the other OO development systems.

Still just thinking out loud about this and that...

[pulsoft]

Re: Classes as data sources

Not being a programmer tutored in modern tech speak, I will try and outline what I understand classes to be in my own particular parlance.
In my previous development environment we had a thing called a type repository or dictionary. Here we could create instances for any field data type, for example I might create a type that I call datetype I could define the type as date and specify a wide range of characteristics (type properties) for it. I could do such things as allocate an input format for example 'DD/MM/YYYY' and I could attach programs to it's possible events such as 'on click'. This on click event might invoke a date picker program or it might call a table look up showing unique date entries in the table associated with that program, or whatever. Other events such as 'on form save' might run a batch program to perform a date calculation of some sort and update a system-wide (global) variable, etc. Very similar to field rules but more far ranging.
At the time of describing tables you could specify these types instead of conventional field types. You could then alter specific aspects of the resulting inherited field properties should you wish to. Doing this however would exclude the modified field from being globally changed if in the type repository the original datetype was changed for example to have an input format of 'YYYY/MM/DD' instead. Having made a change to the type all relevant tables with non-changed fields referenced as datetype would be changed automatically throughout the project\solution, relevant data would be converted if necessary and all related forms, browses, reports and batch processing routines (Xbasic scripts in Alpha) would all be modified to take into account the cosmetic changes made.
Likewise, if the example date field that was changed from it's original inheritance features at table level was again subsequently changed then as with the types all related forms, etc. would be changed for the modified field in the same way as a modified type.
Everything was cross referenced by where and how used and by make-up attributes as well as by reference name. A sort of programming genome.
Of course Alpha has field types and sets which are useful but nothing that gives you the power of this global modification.
I hope that makes sense. I know it is slightly off-topic in respect of John's original post but I would love to see something like this in Alpha.
Sorry, if my terminology is a bit whacky...
You may of course wonder why I changed from EDeveloper to Alpha - Well that is another story - At times I still wonder...
Paul

[mronck]

Re: Classes as data sources

John, I agree with you that it would be great should Alpha Five as a whole be able to seamlessly communicate with the .NET platform. That, however, ain't gonna happen any time soon. And although you COULD mimic the methodology of Classes and Objects by using User Defined Functions (that is why I mentioned it of course) this would be like learning a Chinese person the sounds of some German words: he could be able to use it but would not understand a word of what he was saying. The syntax of the languages differ too much.

I agree with you on a lot of points. If you are proficient with Alpha, I see no particular reason why .NET would be "better". That is of course reasoning besides the matter of .NET being the defacto market standard, which whatever we think about it IS a big issue.

Would one think more "efficiently", I mean, in terms of how to take advantage of the "positives" of .NET whilst using Alpha Five, then one could program core functions in UDF's and call upon them from anywhere you need: this comes close to the class instance when you are flexible enough with the UDF parameters.

There is a lot hidden in UDF's. As in all of Alpha Five, there is far more to enjoy then the most of us will ever know. For instance take xdialog. It is a world of its own. Some of the Alpha specialists are very proficient with it, like Daniel Weiss. If you start studying xdialog, you will get surprised by its power.

At the base of taking good use of all of this is "thinking" and "debating" about, like you do in this thread. It is a good thing.

[jkwrpc]

Re: Classes as data sources

Paul
I read through your post a couple of times. In my way of thinking we take and wrap that functionality into a an object and call it a a class. In your case this could be called dataType and in that you could have a function that format your date. You could call it DateFormat. You would design it so you would pass the value you want formatted into it. You could then call that by something like dataType.DateFormat(date) and it would return the date formatted as you want it.

I realize this can be done by some built in date functions or by a field rule if its a single date. But by using a class, say you want to change the format, you go into the class make the change and its done throughout the entire application. Now you don't have to go to every place the date is located and convert it.

Again, I appreciate that A5 has the means to do some of these things but that is not the point. The point is moving the model from what Marcel called a linear type of coding to an object model of application development.

Just thinking out loud again, a dangerous thing for me to do. I always end up in trouble

[kkfin]

Re: Classes as data sources

I use Alpha v11 classes as base elements to all my webpages.

Every new page is a new instance of base class. The base class has inside the layout (header, footer, main menu...). and xbasic template for html and class properties and functions which are similar to all pages

If I change something in my base class all my pages will change. Very nice and clean.

When I then create a new basic a5w page it is just 9 line of xbasic code.

[jkwrpc]

Re: Classes as data sources

Ken - its nice to hear someone using Alpha is making use of classes. Thanks for the post.