I have just switched from REALBasic to Revolution. I have previously used Hypercard extensively so it has felt like coming home. One feature of REALBasic which I have not been able to replicate in Revolution is the concept of classes and instances.
A class is a "master template" which contains the functionality of an object including code and property definitions. An instance is a particular use of this class which may be used multiple times in a project. Updating the code for multiple objects is then simply a matter of updating the code in the class.
To my understanding, this can be replicated within a single stack using groups as backgrounds but not across different stacks where it seems the whole object must be copied in order to be used. This means that code updating must be carried out across multiple locations in a project which is inherently error prone and tedious. Is there something I have missed in Revolution which replicates the behaviour of classes and instances?
Classes and Instances
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
Janschenkel
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Contact:
I'm afraid Revolution is as object-oriented as HyperCard : it is object-based, imbued with OO-characteristics, such as 'sending' messages to other objects, its way of handling those along the message path (chain of command pattern) and its controls have properties with accessors, using an 'of' keyword rather than dot-notation.
But you can't make your own controls from scratch, and there is no concept of inheritance. One of the concerns, of course, is inserting full OO into the language without alienating new programmers and causing some sort of schism in the community between 'traditional' and 'object' programmers.
Admittedly, it would be nice if we could have objects (even if it's only non-visual business entity-style objects) but this falls in the realm of engine changes, and there's a long list of changes I would rather see them implement before OO. Not to mention they'd best insert some form of namespaces to prevent conflicts.
In the meantime, you can already do a lot by taking advantage of frontscripts, backscripts and 'the target' - allowing you to intercept messages before they reach the control and/or just before the message makes its way to the engine.
Jan Schenkel.
But you can't make your own controls from scratch, and there is no concept of inheritance. One of the concerns, of course, is inserting full OO into the language without alienating new programmers and causing some sort of schism in the community between 'traditional' and 'object' programmers.
Admittedly, it would be nice if we could have objects (even if it's only non-visual business entity-style objects) but this falls in the realm of engine changes, and there's a long list of changes I would rather see them implement before OO. Not to mention they'd best insert some form of namespaces to prevent conflicts.
In the meantime, you can already do a lot by taking advantage of frontscripts, backscripts and 'the target' - allowing you to intercept messages before they reach the control and/or just before the message makes its way to the engine.
Jan Schenkel.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com
Classes and Instances
Hi Jan
Thanks for your informative reply. I thought as much so I shall have to think my way around it.
I was interested in another post of yours where you discussed abstraction when designing databases for use with the web. I'll see if I can find it again but if in the meantime you can point me in a direction where I can learn some more about implementing this structure in Revolution, I would appreciate it.
Alex
Thanks for your informative reply. I thought as much so I shall have to think my way around it.
I was interested in another post of yours where you discussed abstraction when designing databases for use with the web. I'll see if I can find it again but if in the meantime you can point me in a direction where I can learn some more about implementing this structure in Revolution, I would appreciate it.
Alex
-
whelkybaby
- Posts: 47
- Joined: Sat Nov 17, 2007 6:04 pm
Hi Alex,
I thought I'd build a little upon what Jan was saying, in case it's useful.
I've been building a custom control for deployment here, there and everywhere. It's a complex group and is made up of around 40 buttons, fields and other controls.
Most of the scripts that make the control work are put into a library stack, which is put into use simply by using the 'start using' command. This is pretty much the same as in HyperCard.
By using a front script, I can intercept each message that's being sent by Rev and decide whether I need to do something with it (usually by examining the target and checking a custom property to see if it's my control or not).
For example, by intercepting preOpenCard, I can check whether the card has my complex group on it and paint or reset it before the card is shown. Or by catching resizeStack, I can provide help with geometry without needing the GM. Again, by intercepting mouseDown, mouseWithin, etc. I can make the control behave how I wish without needing to put scripts inside it.
Thus should I change any code in the front script or in the library stack, all instances of the control will get updated in one go. The only drawback is that if I add extra functionality to the group and need to add a new control within the group, such as a field, I'd have to be able to check whether it exists first and then add it.
Cheers,
Steve
I thought I'd build a little upon what Jan was saying, in case it's useful.
I've been building a custom control for deployment here, there and everywhere. It's a complex group and is made up of around 40 buttons, fields and other controls.
Most of the scripts that make the control work are put into a library stack, which is put into use simply by using the 'start using' command. This is pretty much the same as in HyperCard.
By using a front script, I can intercept each message that's being sent by Rev and decide whether I need to do something with it (usually by examining the target and checking a custom property to see if it's my control or not).
For example, by intercepting preOpenCard, I can check whether the card has my complex group on it and paint or reset it before the card is shown. Or by catching resizeStack, I can provide help with geometry without needing the GM. Again, by intercepting mouseDown, mouseWithin, etc. I can make the control behave how I wish without needing to put scripts inside it.
Thus should I change any code in the front script or in the library stack, all instances of the control will get updated in one go. The only drawback is that if I add extra functionality to the group and need to add a new control within the group, such as a field, I'd have to be able to check whether it exists first and then add it.
Cheers,
Steve
-
Janschenkel
- VIP Livecode Opensource Backer
- Posts: 977
- Joined: Sat Apr 08, 2006 7:47 am
- Contact:
One of the best explanations of the Message Path and where frontscripts, libraries and backscripts come into play, is Richard Gaskin's article here: http://www.fourthworld.com/embassy/arti ... _path.html
As for database access abstractions: I talked about that at the Revolution Live conference in Las Vegas, so maybe you ought to get the DVD - not just for my talk of course, but for all the interesting information that was shared there! https://secure.runrev.com/store/store-f ... VSLLIVEDVD
Anyway, the central part of this strategy is to keep all the database access on the server, in an n-tiered architecture. Don't panic, you won't have to involve Java or .NET if you don't want to: Revolution can be used on both the clients and the server.
What the client does, is gather the information and use the 'post' and 'get' commands to exchange this data with the server application - I prefer to exchange data in XML format, but there are plenty of options. You can make these 'services' as coarse- or fine-grained as you wish.
For instance, your 'order entry' service could have both a 'do it all in one go' call where you send an entire order to the server, including the detail lines, and a set of 'do just one thing at a time' calls to create/read/update/delete individual parts.
Your user interface doesn't access the database by itself, it asks the server process to do that - however, the user interface need not be a dumb terminal: it can take care of data entry checks (no reason why an invalid date should ever make it to the server) but also do the grunt work of visualization (the server doesn't have to draw the graph, it just hands over the data and the cliet can do the work of interpreting the data for charts, reports, etc.)
As you design these services that make up the server part of the distributed application, you're free to expose these in ways that make sense as part of a workflow, rather than thinking in terms of tabels, records and fields. The user interface shouldn't have to care about how the data is stored where - and ocne you start dividing up the responsibilities, large scale projects suddenyl become a lot more manageable.
I do still plan on writing up a series of articles on the topic but am a little stretched for time right now. Hopefully, I can get back to that soon, and I'll make sure to keep everyone posted.
Jan Schenkel.
As for database access abstractions: I talked about that at the Revolution Live conference in Las Vegas, so maybe you ought to get the DVD - not just for my talk of course, but for all the interesting information that was shared there! https://secure.runrev.com/store/store-f ... VSLLIVEDVD
Anyway, the central part of this strategy is to keep all the database access on the server, in an n-tiered architecture. Don't panic, you won't have to involve Java or .NET if you don't want to: Revolution can be used on both the clients and the server.
What the client does, is gather the information and use the 'post' and 'get' commands to exchange this data with the server application - I prefer to exchange data in XML format, but there are plenty of options. You can make these 'services' as coarse- or fine-grained as you wish.
For instance, your 'order entry' service could have both a 'do it all in one go' call where you send an entire order to the server, including the detail lines, and a set of 'do just one thing at a time' calls to create/read/update/delete individual parts.
Your user interface doesn't access the database by itself, it asks the server process to do that - however, the user interface need not be a dumb terminal: it can take care of data entry checks (no reason why an invalid date should ever make it to the server) but also do the grunt work of visualization (the server doesn't have to draw the graph, it just hands over the data and the cliet can do the work of interpreting the data for charts, reports, etc.)
As you design these services that make up the server part of the distributed application, you're free to expose these in ways that make sense as part of a workflow, rather than thinking in terms of tabels, records and fields. The user interface shouldn't have to care about how the data is stored where - and ocne you start dividing up the responsibilities, large scale projects suddenyl become a lot more manageable.
I do still plan on writing up a series of articles on the topic but am a little stretched for time right now. Hopefully, I can get back to that soon, and I'll make sure to keep everyone posted.
Jan Schenkel.
Quartam Reports & PDF Library for LiveCode
www.quartam.com
www.quartam.com
Classes and Instances
Hi Steve
Thanks for your post. I was thinking along these lines but there is no way of getting around having to duplicate the objects which is inherently less elegant and more error-prone than than using true objects.
But there are trade-offs. I just love swapping backwards and forwards between design and implementation in Revolution rather than the cumbersome design, compile everything of the run cycle in REALBasic. I have already built a couple of small stacks for specific tasks in about half the time it would have taken to do it in REALBasic.
Alex
Thanks for your post. I was thinking along these lines but there is no way of getting around having to duplicate the objects which is inherently less elegant and more error-prone than than using true objects.
But there are trade-offs. I just love swapping backwards and forwards between design and implementation in Revolution rather than the cumbersome design, compile everything of the run cycle in REALBasic. I have already built a couple of small stacks for specific tasks in about half the time it would have taken to do it in REALBasic.
Alex
Classes and Instances
Hi Jan
Thanks again for lots of great information. It is reassuring for me to observe some similarities in thought from someone who clearly has an extensive experience with the Revolution environment.
I had already implemented some degree of abstraction in an earlier database project in REALBasic which was written to simplify SQL access to multiple databases and your advice has educated a broader view of the whole process. Your sage advice has given me one of those little "ah ha" experiences - I suddenly appreciate how the seeming increase in complexity which comes from adding one or two tiers to a structure actually simplifies the conceptual management of the whole project - thank you. Thanks also for the link to the presentations - I shall follow through with that.
I have begun to experiment with sockets and I found a code snippet in the archives which has got me going. I am also interested in encryption but I shall put that into a separate thread.
Alex
Thanks again for lots of great information. It is reassuring for me to observe some similarities in thought from someone who clearly has an extensive experience with the Revolution environment.
I had already implemented some degree of abstraction in an earlier database project in REALBasic which was written to simplify SQL access to multiple databases and your advice has educated a broader view of the whole process. Your sage advice has given me one of those little "ah ha" experiences - I suddenly appreciate how the seeming increase in complexity which comes from adding one or two tiers to a structure actually simplifies the conceptual management of the whole project - thank you. Thanks also for the link to the presentations - I shall follow through with that.
I have begun to experiment with sockets and I found a code snippet in the archives which has got me going. I am also interested in encryption but I shall put that into a separate thread.
Alex