AutoEdge 2.0

There has been such a flurry of activity, both on this forum and in my own work, that it has taken me a while to get back here ... amazing what happens when it scrolls off the bottom of the screen so fast.

To me, there are three major themes which I would like to see addressed in AutoEdge 2.0, were I to have anything to say about it.

1. As I observed long ago in my initial responses to AutoEdge, there are a number of ways in which the model underlying this code is overly simple in terms of the application itself. Yes, I recognize that you aren't trying to (or budgeted for!) creating an entire ERP system as a reference application, but there are places where a very slight increase in complexity would make the structure much more realistic or comparable to real world applications. It isn't that one expects to find the full range of complexity and richness of data that one would get in a real world application, but rather that there should be some of the structural complexity so that one is not looking at code which is overly simplistic. I gave some examples in my earlier discussion.

2. OO. If PSC believes that OO is ready for prime time, show us. I know that you don't want to force people into an OO paradigm, but frankly I don't think you need to worry about that anymore. The people who are really interested in OERA seem to already be looking hard at OO and might be looking harder if they weren't having to wrestle with a large legacy application. Give them good examples and they might see better how to proceed. Besides, if you had to work with OO to try to do something resembling a real application, perhaps it would create incentive for some language enhancements in response to the difficulties you experienced.

3. One of the difficult problems in the wake of the original AutoEdge has been people taking it as being a model for how they should be developing new systems. Yes, you has specifically disavowed that it was not intended to be a model for production systems, but was rather a pedagogical tool intended to get people to think and talk about OERA issues and that in turn would lead them to the design of their production ready frameworks. But, no matter how big a sign you hang on something like this that says "Not Ready For Production Use", I think you are going to have this happening. Not only are individual shops going to take it up as a model, but Professional Services is going to use it in their presentations and training and not only are they not going to hang out a big enough sign, they probably didn't read the original sign. There is really only one fix for this ... make the code a good model for a production system.

Now, I suspect that you aren't budgeted for any of that, but it is what I would like.

Whilst AutoEdge is laudable in it's vision, I feel that there is another audience that needs addressing: The simple howto.

There is no "simple" "right" code to demonstrate things. And if there are smatterings, it doesn't use the latest ABL stuff.

Witness the socket code samples. It is sooooo bad it is not true. It lead me down a path that turned out to be a dead end.

I think that there are certain areas that could benefit from simple code. For example, I want now to use .net to provide a dynamic lookup for a field. To select a customer, either type in the name / code / shortcode or press a button for a lookup. This to me seems to be a perfect example of how to use cutting-edge code.

Now, I am attempting to write this myself at the moment. However, wouldn't it be great come the general release that there was some code that could literally be dropped into a project and used. "See, this is what can be achieved if you use our new OO / .net / new features of 10.2"

AutoEdge is so big. Good examples are simply MIA.

3.

I don't think that is going to happen because if it is good for production use people are going to ask for Progress consultancy, involvement, commitment etc. like with Dynamics, OE-SDK, iMo and Progress does not want that.

To be sure, there is a need at all levels. The simplest illustrations in the manuals, while only a few lines of code, really should always be suitable as fragments from a quality implementation, not something that illustrates a usage pattern that should never be used! At the other extreme, there is a need for an integrated complex example like AutoEdge that shows how it all fits together. While one wants to keep it small enough to be manageable, again, each piece should illustrate good practice. In between, there is a need for topic-oriented discussions of interest areas which cover the pros and cons of different approaches and go into some depth on themes and variations. There are starting to be some manuals in the manual set which are at least trying to go in this direction, whether they are quite the right thing or not.

Personally, I think there are few things which illustrate good practice and the use of principles better than good examples. I am thinking that creating a set of open source services for the common infrastructure aspects of OERA might be a good place to illustrate many of those ideas, especially if they are done as well-defined services and are production quality code.

I agree that open source is the way to go. The problem is that many people may not know about OEHive (for example) but they do see what they read in the documentation, and if that is their first introduction to a feature, then they are sent down a bad road.

I'm not quite sure what you are saying. Are you suggesting that, if the Reference Implementation were a good model for production code, people would no longer want to or need to use PSC Professional Services? I certainly don't think that is true since merely having a good model is only a small piece of building a new application or transforming an old one. I think it would simply mean that those using PS would have a sounder base and spend less time figuring out what is wrong with the model they are using, whole those who weren't going to use PS anyway will have better guidance. After all, if the goal were simply to sell the maximum in professional services, one could stop documenting everything so that one had to get a consultant to explain it.

I agree with you. Redhat makes a nice profit, despite the code being open source. That is because some people are willing to pay for support and consultancy. If PSC consultants were able to use "best of breed" components and classes and models then they would be far more productive and thus able to provide better services and support

What I meant was is that I don't think that Progress wants to be in any way "responsible" for a model/framework (or something that looks remotely similar - not even AutoEdge) that can be used for production.

Look at BDK (gone), ADM2 (inactive), Dynamics (inactive), OE-SDK (gone), iMo (partners).

Progress provides the core tools (ABL, OE Architect) / OERA / consultancy and facilitates the partners in building tools/frameworks/applications...

But if the model / framework was just a set of "best practices" then there would be no argument - you could say that progress show you how to use a "Button", but no-one would say that they are responsible for how you use it.

There are a lot of options short of providing a supported framework. In fact, I wouldn't want them to invest in creating and supporting a framework exactly because of the kind of history you suggest (although I though OE-SDK morphed into iMo rather than disappearing). But, providing a Reference Implementation which shows at least one good way to do things can be done without any implication of support at all, any more than they provide support on AutoEdge now.

Ok, this is a good discussion.

Firstly I hear you on the simple how-to stuff, and I hope that providing the ABL based infragistics samples is a move in the right direction. Yes, I understand we always need to do more, and not just Infragistics based! We will continue to strive to produce more, simple samples. I could almost see an FAQ type approach of simple question with code samples as answers? Maybe even provide these as snippets!

The framework question will be a perennial question to which there will never be a right answer that suits everyone. I agree with Julian in that if we can provide a set of components based upon 'best practices' (a term I hate by the way as again, what's best for one person may not be best for another), so lets say based upon good/sound practices, then I think we're on the right track. Don't for one second think I'm talking about an ADM3 style approach, far from it. But if there were a set of reference components based upon sound reasoning, that could work together as a coherent set of bits, or are built in such a way that they could be substituted and augmented then I think that could be of some use? This would be a great thing to workout as an open collaborative piece of work, but as always again that then opens the question of who has time when everyone is busy trying to just build there own stuff and keep money coming in the door! It's fair to say there isn't a great track record of such initiatives in the past, you always end up with more people taking than contributing!

AutoEdge always was balancing act, and as such will always have compromises. Too simple and it's viewed as exactly that, and not much better than standalone samples. Too large and people view it as too complex and difficult to grasp. And yes, at the end of the day it's meant to be a learning aid, not something we're looking to sell, last time I checked we're not in the application selling space!!

A key question is whether or not AutoEdge does indeed fill it's brief of being a teaching aid. I certainly come across lots of people that have, and continue to use it in some way shape or form. But does it have a life we should continue, or should we devote time elsewhere, such as simple how-to's and reference components and stop there, not showing how these reference components could fit together in a pseudo realistic example?

In many ways, this is the interesting discussion, before you even get to talking about how you'd implement the required bits and what object/data model we'd look to follow, as all that is meaningless if what we'd be trying to do isn't what is wanted in the first place!!

So keep the discussion going, and don't hold back, there is no ego here and I don't get easily offended (Unless it's personal then u better watch out ), as these are important decisions we need to make.

I honestly think that if a plethora of good code examples and howto documents would go a long way to providing a mechanism of a framework.

For example, I'm just playing around at the moment with the user controls - the mind is boggling at the potential uses for this. Already, I have a dynamic lookup on any table populating a combo box with no lines of code, just the initial user control class I created.

I'm now thinking along the lines of having a complete crud form where I have a standard toolbox (add / delete / edit etc) with a menu and a data grid. This form only needs to be passed a table, query and field names and it will handle most of simple data entry, again, with little or no code.

Smart Objects were the brontosaurus of 4GL code. Now, evolution has happened and we are into the mammals - we need to make sure that we can build a better mammal using both .net and 4gl components, and not end up with the Camel or duck-billed platypus

I think that finally the 4GL has caught up with the ideas and visions that were SO and dynamics, and we can build that better widget. Let's just start on that road with good code - using the language to the full.

This would be a great thing to workout as an open collaborative piece of work,

Coming soon to a Hive near you ...

For example, I'm just playing around at the moment with the user controls

Doesn't do much for a non-Windows server, though ...

Wow - you mean .net controls don't work on CHUI ??

Seriously - there are things that are always going to be windows / gui only : that shouldn't mean that we must not write code and examples for the gui. In our circumstances, our product is not designed for, nor will it ever be deployed on, command line / CHUI. We have no desire to have a UI for CHUI.

I still want code examples showing me how to do things in the GUI , even if it means it will not work for a non-windows server.

I think that this is part of my "frustration" at the current frameworks / code examples. They try to be all things to all men.

Let's have some code for the "real world" as well as the "academic world"

But have have to take into account that the user interface will probably be different again in a year or so...

Ooooh I hope so - that would mean that there was something else apart from .net ... which could only mean either wpf or a cross platform gui toolkit like Qt

The issue about "non-Windows" has mostly to do with the server ... being able to use a Windows box as a server should be an option, not a requirement. Having a Windows machine as the client is a far less restrictive assumption.

which could only mean either wpf or a cross platform gui toolkit like Qt

Good thing you included the smiley since I can't imagine anything in those directions happening. From what Shelley has said in various talks, it might be possible to support Java in a similar fashion to the .NET, but I don't get the impression that there is nearly the same level of market demand for that at this point. It could be interesting for non-UI applications, but that certainly isn't where this work is pointed.

More likely would be some inherent support for some form of rich browser client, although obviously the client code would then not be ABL. But, while the market demand is there for this, I'm not holding my breath on seeing actual product any time soon because the market is so fragmented with alternate technologies. I can't see PSC trying to predict the winner at this point.

What I meant was that you should design your application in such a way that you can switch the user interface to AJAX, 3D UI, MS Silverlight, MS Surface or whatever by only rewriting the presentation logic.

And be able to run your application without user interface...

And be able to run any server platform...

And be able to use any database...

It may sounds like overkill but I believe in the end this is the best way to go.

maybe you are right. However, in my world I am sticking to

a) the progress db because it has worked well for us over the last 20 years, not once giving us any data corruption. Why would I want to change ? What benefits would swapping our inhouse apps over to another database give ?

b) the database works on linux or windows already. This is progress.

c) the appserver / web speed programs already run on any supported platform

d) we make heavy uses of classes and oo stuff - the UI hooks into these, the non-UI hooks into these.

Is this a perfect scenario ? No . Is it worth the investment needed to rewrite the application from scratch to attain some lofty goal that we may at some time decide to move to another UI ? I don't think so.

As I mentioned earlier, what suits us does not mean that it would suit anyone else . That is why i wanted good, generic code that we could use and others could use

Understood.

But it is always a good thing to keep things like OERA in mind and it doesn't have to (or can) happen in one big bang. It has taken us years and years and several small bangs and we are not there yet either... But we are now in a position where we could switch to an alternative UI like the OE Advanced GUI or AJAX without turning things completely upside down...

Does Microsoft also provide a reference architecture or application. I read something about Microsoft Application Blocks?

Then we are thinking alike. As mentioned, we are moving over to a system of classes and OO - I actually think that in the not too distant future we could be entirely class based.

Then it is another step to move to UI independence .. !

Simon sets a high bar, but it doesn't need to mean turning to Java or something to reach it ... or at least to get pretty close. I am with you in being fond of writing server-side code in ABL. I think it is efficient, productive, and enjoyable. I have some issues with some of the supporting infrastructure like AppServers, but I think that I can either live with it or get around it. I am more than happy to use the Progress DB, but given the choice, I would also program for DataServers because it keeps you from being locked out of an opportunity where they put technology first.

But, UI is something else. Whether you are there yet or not, you should certainly be wondering about fat clients in general. To be sure, if one has an existing ABL GUI, this .NET stuff is a very cool way to spiff things up and get some more mileage out of things without having to start over. There might even be contexts in which it is a reasonable architecture to have fat clients, but it certainly has downsides. But, working toward UI independence has got to be a key piece in future proofing.

Obviously one of the goals of the OERA, or potentially any modern architecture concept, is that your services should be as independent as possible, both at the back end and from the UI. I made a flippant remark in an different posting that we put the new Ultra based UI on the AutoEdge code base without changing one line of back end code, which may seem trivial, but potentially is a huge thing!

Of course, as Simon says, moving to a modern architecture is not a big bang thing, or at least isn't for the vast majority of people, is has to be introduced iteratively and gradually over a period of time, but when you get there, the pay offs can be substantial.

Anyway, I have a question. On the one hand I hear we need simple, how-to type materials, on the other I hear we need more 'production' not 'academic' samples. So given as always limited time, resource, etc, what would be the priority? I'm not saying these things are mutually exclusive, but there is a difference, or?

An anwser to your question:

I think that in theory they are one and the same thing. A "production quality" sample would have to be good code in order to get into production. Good code is simple code.

If the "academic" code you allude to is the code examples in the documentation / src folders, then I can honestly say that I have not once used any psc example code in production.

I have to agree with Julian here ... good examples are merely small pieces of production quality code.

Which said, I think it is difficult to create really good small how to examples without creating a production context since without that, you have no way of knowing whether it is quality code.

Which said, I think it is difficult to create really

good small how to examples without creating a

production context since without that, you have no

way of knowing whether it is quality code.

You see the dilemma

If the "academic" code you allude to is the code

examples in the documentation / src folders, then I

can honestly say that I have not once used any psc

example code in production.

I believe you sir used the term "academic world" so you can define it however you like

Well, I see the dilemma in the sense that, if one relies on people who mostly spend their time writing manuals to create code samples, the code samples are unlikely to be examples of production best practice. I do know of cases where the person responsible for code samples had prior experience actually developing production code, but that is certainly not typical.

To me, what it suggests is that one should start by acting as if one was developing a meaningful production system. Then, one should find ways to trim and simplify the design in order to simplify both the example and the implementation. I think it is important to move in that direction rather than the other since if one starts with a schema like sports, one has to practically chuck it out and start over again, whereas there are ways to trim out which still leaves a meaningful skeleton and relationships.

Then, develop this reference implementation ... but make sure there is plenty of input from an early stage about the work to make sure that the techniques conform to real world best practice and address real world issues.

Then, harvest the result to provide examples for the manuals. And, based on the experience, create some how to manuals about various topics.

I.e., the goal of AutoEdge 2.0 shouldn't be just a new demo, but rather a systematic way to improve the knowledge base.

Well, from some of the examples I've seen it's pretty easy to create poor code examples ...

Especially if the person creating the samples has no real world experience using the thing he or she is creating a sample about.

Hell yeah. Just don't mention socket samples to Mr Higgins ..

That certainly is one of the well known examples!

and of course all the 'production' systems out there contain no poor code at all!!

I'm not going to get into a mine is bigger than yours argument over samples & experience, suffice to say that different samples are aimed at different things. Some are used to purely explain a syntactical concept, others to explain larger problems.

So rather than heading down a negative route, lets try and keep this positive about what could/should be done going forwards.

All production systems contain very poor code. Mine does - and some of it because when I moved from the char of V3-V6 CHUI into V7 GUI there were poor examples which I slavishly copied as gospel. I'm trying to avoid that going forward into the brave new .net world.

Don't throw a little wobbly, or get upset. Nothing is personal or attacking. I just want to make sure that the samples we give out with the new .net GUI have had the best chance to be "the best example" of how to do something.

Hey no wobblys, or upset, as I said earlier no ego's here!! Just want to make sure we stay positive and look at what we can do going forwards

Plus, knowing u for as long as I have, I can only imagine your code

 * jmls takes home his ball.

Hey, that's my ball

gah.

The jumpers we used for goal posts are yours

Are they the old 10.1A goalposts, or the nice, new .net goalposts ? The ones that keep moving ?

Sorry, couldn't resist

..lol...

Never, ever, ever, lose your sense of humor

and of course all the 'production' systems out there contain no poor code at all!!

A great many of them contain some of the worst examples of all. Some of that is, as Julian suggests, due to the authors working from PSC examples, but frankly there were a lot of people out there inventing new ways to write horrible code as well. But, one of the big reasons for a lot of that horrible code is simply that a lot of it was written 20 years ago or, if written more recently, was copying the style and methods of 20 year old code.

So, absolutely, by "production quality" I don't mean simply any code now in production. I mean code one would want to be producing for production purposes according to modern standards and principles. The fact that existing production systems are full of such terrible code only emphasizes the need for good examples to provide guidance.

"The fact that existing production systems are full of such terrible code only emphasizes the need for good examples to provide guidance."

This complete thread in a nutshell. Well said, sir.

Having started off as a Varnet VAR, I have a lot of inspiration!

I'm really glad you never got to see / will get to see my original V7 GUI code. Ouch. I still have maintenance nightmares. Especially from code that other developers wrote basing their programs on mine. Oh! the insanity.

I'm really glad you never got to see / will get to

see my original V7 GUI code. Ouch. I still have

maintenance nightmares. Especially from code that

other developers wrote basing their programs on mine.

Oh! the insanity.

Hehe. There's nothing worse than fighting your way through some complete idiot's code only to find out that you're that idiot.

I wish I could say that it's only happened to me once

-- peter

can we have the installer changed to work with 10.2a1p ? it errors at mo with "this version of autoedge required openedge 10.2a1b or higher.

Thanks Mike

Hi John

We're just wrapping up building & testing a new version, so I'll check how quickly we can post it.

Mike

Thanks Mike, much appreciated.