Tutorial

The closest you will come is a couple of OERA whitepapers which talk about how one might use OO in OERA, but they are a long way from a tutorial on the application as a whole and are suspect in a number of ways (e.g., see http://www.oehive.org/OERAStrategies ).  Frankly, I don't think there is enough of a consensus yet about what an application should look like to define the goal of the tutorial.  Even for pre-OO, AutoEdge is better as a starting point to stimulate discussion than as an actual model of how one would want to build production code.

You might be interested in the OpenEdge Open Source Initiative http://www.oehive.org/OERAOSI , but no one has contributed any actual code there yet, so there isn't even anything to copy.

I'm not sure if you found this one already:

Class-based OERA = http://communities.progress.com/pcom/docs/DOC-24258

That's the code, but one needs the whitepapers too.  And, that isn't really a tutorial.

And, as noted:

This code is not complete and not supported in any way, but is meant to serve as a sufficient body of samples to illustrate the architectural discussions in the papers.

Moreover, there is far from consensus on even what they show is a good model.

Hi Thomas,

This is exactly my experience.

Looking at Progress from the past they provided ADM2 which illustrated how Progress suggested to build your application. It provided some structure/method to build your programs.

After that they adopted Dynamics, which is build on ADM2. Dynamics provided a high level of framework.

Nowadays Progress seems to step back and only provides the 4GL and talks about a concept; OERA.

ADM2 is not upgraded to ProDataSet, OO-techniques and OERA. Same for Dynamics.

If they are not providing a framework/tools that really implement this concept in a professional way, I am wondering how strong this OERA is.

I think its very cheap to only talk about OERA but not providing the tools to realize it.

Maybe tomorrow they come with another philosophy.

So we are back on same level as before ADM.

It looks like, if I am a software company developing applications, I first have to develop a complete framework, before I can start developing an application/functionality.

Every other software company developing applications is doing the same thing in its own way.

I have also bad experience with open-source initiatives. So to be honest I do not expect anything usefull, except small parts of code doing nice things.

I am really wondering whether Progress is thinking about bridiging the gap between buying Progress and building applications (and not frameworks).

Rgrds

Martin

Hi Martin,

I agree with many things you said.

ADM2 is not upgraded to ProDataSet, OO-techniques and OERA. Same for Dynamics.

Except this, as it is not exactly true. I guess in one of the 10.1 releases Progress did implement the DataView SmartObject, a client side component for using ProDataset and OERA based backends. This works very, very well in static ADM2 and Dynamics as well.

Regarding OpenSource: I'm pretty sure most enterprises nowady rely on some OpenSource software (Linux, Apache, ...). So there are many vital and useful OpenSource initiatives.

My feeling about this in the Progress community is, that people are not that much technology adicted - basically because they have chosen Progress because it solves many issues while implementing business applications. I was involved in trying to get an OSI of the ground. Many people seemed interested, obviously there was a lot to share and some code got shared by very few people and the majority got caught either by having no time to clean up things to make them sharable and others might have hesitated to submit code, before there's enough in the project for them to justify their own submission. IP concerns probably did the rest. Also open source initiatives require steering and a lot of time to discuss about a direction and even review submissions. It's hard to justify that in many cases when there's a development project to be completed on time. Submitting to OSI is always an investment in the future, not the current.

It looks like, if I am a software company developing applications, I first have to develop a complete framework, before I can start developing an application/functionality.

Well, there are some frameworks available from tool vendors and consulting organizations. But even though I'm one of them - I personally would prefer if Progress would ship much more out of the box (and out of the box means locally on my PC, not on PSDN). A working OERA implementation, back- and frontend out of the box, contained in any OpenEdge Architect installation. Including wizards that generate working data entry screens and web services based on a proven pattern. Ah yes - including tech support.

From the discussions I had with various people at Progress in the past, I doubt that we can expect something similar soon. But people should use any available channel requesting such a feature.

There are different ways of looking at PSC's role in providing frameworks and related tools on top of the language and IDE.  To be sure, it seems like a naturual extension of their missiion statement.  But, then we look at the track record ... and while there are fans of their various efforts, none of those efforts has managed to be really compelling nor have they achieved wide acceptance, even for new applications.  Some fans, yes, at least for the more recent versions, but a lot of people who are not only not compelled to interest, but who actively dislike the concept.

While some of this is blamed on not having the right visionary sort of leadership to do the problem "right", I also think it is a statement about the ABL community.  We're here because we like the ABL well enough to have chosen it to develop our applications, though we vary widely in how really fond we are of it, but beyond that we are a pretty diverse and ornery bunch.  In many ways, this is not exactly surprising since I think it is true of other language communities as well.  It is just that if one develops a framework used by 3% of Java developers that's a much bigger number than 3% of ABL developers.  To make things worse, there is only the very tippy tip of the iceberg of us visible and interacting in on-line communities.  The vast majority are in shops where participation is either unknown or actively discouraged or forbidden.  Can you imagine a Java shop where they would forbid people to use the internet in the course of their work?  Withoutt that sense of community, it is hard to build consensus and direction.

I do think that one of the persistent flaws of the efforts to date is that they have been all-or-nothing type structures.  If they were more component oriented, it would have been easier for people to try out one or two components and perhaps gradually to have moved to using a larger percentage, but in combination with locally produced components or variations on the standard.

I do think that one of the persistent flaws of the efforts to date is that they have been all-or-nothing type structures.  If they were more component oriented, it would have been easier for people to try out one or two components and perhaps gradually to have moved to using a larger percentage, but in combination with locally produced components or variations on the standard.

I agree in parts. Yes it should be components communicating with each other, loosely coupeled. But there needs to be a large "distribution" containing everything from a single source (may even the OpenEdge installation CD, sorry ESD download). A beginner should be able to get a feature right working environment in very little time to proove productivity. You may start thinking about replacing various bits and pieces later - basically when you feel a bit more familiar with what's required (how hard it's to achieve) in the new SOBA or OO world.

Arguing for components is not arguing against completeness.  To be sure, the offering should be complete, but if it is componentialized, then someone with a million lines of existing ABL code can pick up a piece here and there and make use of it easily whereas committing to the system as a whole is a major, major decision and expense.

Martin,

Not a direct answer to your question, but maybe you find an interesting framework here: http://www.my-imo.com/.

--
Kind regards,

Stefan Houtzager

Houtzager ICT consultancy & development

www.linkedin.com/in/stefanhoutzager

Doesn't iMo still require a big buy in?  Do you even let people into the club on this side of the pond?  I've never had any luck trying to find out anything about it.

Hi Thomas,

I have no idea, I'm not playing a role in the imo-club. But things might have been changed. Check for yourself, there even is a telephonenumber on the my-imo.com page. Seems you can become a partner. There is an imo group on linkedin too: http://www.linkedin.com/groups?about=&gid=100592&goback=%2Egdr_1246099105716_1.

Kind regards,

Stefan.