Is this not something that anyone else has any opinions on?
I take it that you have all either resolved the issue, not gotten to this yet or have given up on implementing ProDataSets in Dynamics.
Message was edited by:
Thomas Hansen
At one customer I am using ADM2 not Dynamics. We recently have gone service based using the OERA examples. However, it's design is so fundamentally different and because of the problems I've had in moving forward on versions with ADM2, I have not considered continuing with ADM2.
When we moved to 10.1A we had a lot of problems with ADM2 code and we actually still have some of them. Because of those issues we have not moved the ADM2 code off 10.1A, and we are currently installing 10.1C in development i.e. we have 10.1C but running 10.1A ADM2.
The main issue we have yet to face is the framework to be used at the front end in the GUI environment. Currently we are developing a WEB interface for external users using PSE script but at some stage we will have to tacky the GUI.
Apart from the ADM2 problems we had in moving through versions (at least to 10.1A) many of the developers had issues in coding in ADM2 and I admit that at times I struggled with working out how to do some things and yet I was reasonably proficient with ADM2.
So I haven't really examined ways of using ADM2 with OERA.
I suspect that if you divide the world first into those who use Dynamics and those who don't and then cross cut that division with those trying to use PDS and/or full fledged OO, you would find that there were not very many people on the Dynamics side of the fence who were on the PDS or OO side of the fence. The place one would most expect that is in the core development team preparing for a new release. I would think that a lot of users of Dynamics pretty much accept the tool for what it is and don't look to change the way it is working.
I think people may be missing the point here - the focus here is not only on Dynamics users.
The issue with lack of complete examples or even complete framework support is the same for both Dynamics users and ADM2 (non-Dynamics) users alike.
Those who are using ADM2 and/or Dynmaics are used to (or spoilt - depending on how you look at it) having a complete and comprehensive framework available that will make it easy and productive to implement and use new technologies from Progress. The lack of an official and supported implementation of ProDataSets (and with this some sort of OERA implementation) in my mind is very limiting to the productivity that we are used to having.
Personally, I believe very strongly in the benefits of using a framework for application development. Rather than everyone having to gow their own. ADM2 / Dynamics have been (are) some of the most complete and productive ones from Progress. Something I think Progress should continue to focus on.
Others of us believe in frameworks, but do not find those supplied by PSC to be good examples of the genera.
Hi Thomas (Mercer-Hursh) and others - if you are not talking in pluralis majestatis - please help me out: What other frameworks (other than ADM, ADM2 and Dynamics) for GUI development were available in the V9, pre ProDataset area? Free of charge, out of the box, with tool support in the IDE (ADE), shipped with full sourcecode, customizable and offering a lot of documentation?
Many developers in smaller teams that I know are not migrating to OE10 and/or ProDatasets because they are missing a framework or a complete solution like those that I named with the features that I have named.
Not every developer has the time like some of us (active in this forum) to get experienced enough to build a framework based on all the latest and greatest language elements and fulfilling all new architectural patterns.
General availbility of a solution is for many developers more important/easier to adopt than a more perfect solution that comes at more cost (time or money). Visiting community web sites (potentially in a foreign language) seeking for alternative solutions consumes also time.
Oh, I understand that not everyone has the time to roll their own and, moreover, there aren't really a lot of people who have the skill and vision to create a good framework. It isn't that ADM and Dynamics are the worst of a large number of options by any means ... there are certainly worse examples. But, they aren't the best of the best, either. I don't know of any readily available framework that I would say was good, but that doesn't keep me from knowing that it could have been done better.
Among other things, I wish that these frameworks had been designed more as integrated sets of components so that one could use individual components in a different context when they were appropriate and so that it was easy to replace a component when the standard one didn't do the job. Wouldn't it be lovely to be able to just subclass a standard component to add new or different behaviors?
Among other things, I wish that these frameworks had
been designed more as integrated sets of components
so that one could use individual components in a
different context when they were appropriate and so
that it was easy to replace a component when the
standard one didn't do the job. Wouldn't it be
lovely to be able to just subclass a standard
component to add new or different behaviors?
Well I paid my rent for the last couple of years exactly by doing that within the Dynamics framework...
But from my understanding replacing/subclassing components within a Framework environment is way more easy than taking one of the components into a different context. In ADM2 and Dynamics things are built to work closely together. Taking a component out of this context is almost impossible.
Perhaps with the exception of (static) SDOs that can be used in different contexts: Web Speed, .NET Clients and I once even developed a Business Entity that used a SDO as a Datasource.
Perhaps with the exception of (static) SDOs that can
be used in different contexts: Web Speed, .NET
Clients and I once even developed a Business Entity
that used a SDO as a Datasource.
How could I forget my own Exchange 2008 presentation: Using SDOs with the Advanced GUI...
Which is my point. How much better it would have been, for example,
if there were a security component which one could "steal" and use
in a pre-existing application to upgrade the security handling or
which one could easily subclass to add additional security
features.
That is he whole point of what Progress have been doing by moving central parts of the Dynamics framework such as auditing, session management and other core services into the core of Progress.
By doing his, they are making it possible to improve the usability of features that originated from a framework with known limitations (as well as huge benefits), such as being implemented in the ABL, and allow non-Dynamics customers to leverage these new technologies in their own frameworks or toolsets.
No question that moving some of these things into the language is a big plus, but for things not yet in the language or too complex for a language element, designing them as components would allow a broader and more flexible use than having an all or nothing framework.
Which is my point. How much better it would have
been, for example, if there were a security component
which one could "steal" and use in a pre-existing
application to upgrade the security handling or which
one could easily subclass to add additional security
features.
Agreed. Sounds like a perfect solution... But what if the security component needs help from other components? If it needs to talk to a session management or context management component? One benefit of a framework might be that central functionality (like knowing the user) is available for each other component. But that creates dependencies.
Dependencies may be loose but than it at least requires a clear definition of interfaces (in an OO world, interface declarations would be nice - but that was not available when Dynamics and many other Frameworks were built pre V10).
designing them as components would allow a broader
and more flexible use than having an all or nothing
framework.
I am not too sure about that. It might offer more flexibility on the short term - but that would require more individual coding when using this component in a certain development project together with other components. And imagine the added overhead when you need to replace such a component.
This is really just a question of good design. If one designs with tight coupling and dependencies, then this kind of reuse is not possible. If one thinks more OO, whether using OO or not, and designs for close encapsulation and independence, then it becomes possible.
But anyways the security component needs to know the user attribute when it comes to making a decision if the current user is allowed for some function or not. It may ask then context component when it needs to know the user or the one who who ask the security component needs to tell this as well. Anyways there is a dependency between these to components. Inside or outside.
Again, this is just a question of design. One doesn't need to design the components so that they will only work with each other. They can be designed to be well encapsulated with a published API and anyone who can feed that API can use the component. One shouldn't even need to know how the component does its job, just what job it does and how to interface to it.
You are talking about interface declaration. If you are not Microsoft in .NET (or Progress might take that position for the ABL) I believe the chance that people implementing various components will not agree 100% with your interface specifications is pretty high.
Microsoft has definded a set of Interfaces for Data-Binding and similar features in the .NET framework - because of their power they could and everybody agreed on them (or at least implements their components based on this interfaces).
Two independently well designed interfaces (let's say you and I were both experts on this) for security and context handling components will not guarantee that I'll be able to use your security component with my context component. Interfaces just take the dependency away from the actual implementation - but a dependency will remain to the Interface.
If you and I do security and content respectively and both develop full fledged implementations, then yes, it is unlikely that we can just plug them together. But, that is hardly the only option. If one of us does the development first and the other one likes it, then one can program to that interface. Or, if one has source, one could modify it a little. Or, if it is OO, one might be able to subclass and get the exact features one wanted.
And, of course, that isn't really the point either. If there were a strong set of foundation components which one liked and to which one had source or subclass ability, one would be likely to adopt the set, possibly with changes (which is why the subclass would be nice since then one could upgrade in the future). The real issue here is having this embedded in a structure which means that one pretty much needs to adopt the whole environment or none of it.
Guys! You are messing up the purpose of this thread by turning it into a way too theoretical discussion on components. Maybe this is a separate topic that should be discussed in a separate thread.
I am still interested in hearing from people who are using ADM2 and/or Dynamics and who have an opinion on the lack of updates to the toolsets / frameworks that you have chosen to use as a the basis for your application development.
Yeah, I guess we have kind of hijeacked your thread.
But, I think the real question here is not really the specific one of PDS and OERA in the existing ADM and Dynamics products, but really it is a statement of direction from PSC on where they are going in this space. They seem to get enthusiastic about these products for a release or two, then they realize that it isn't quite the wonder tool they thought it was, and then they figure out they need enough rework or from scratch development that it gets a new name and then they are enthusiastic about that new thing. My informal and completely unofficial view is that we have reached the ennui stage with the current products, but haven't yet gotten to the point where there is clear direction about what will replace them. Perhaps this is just a lull of committing resources to other needs, like the Advanced GUI, but that's the way it feels.
I am still interested in hearing from people who are
using ADM2 and/or Dynamics and who have an opinion on
the lack of updates to the toolsets / frameworks that
you have chosen to use as a the basis for your
application development.
Isn't Dynamics in what PSC terms the "mature" phase?
That's what I mean about them having lost interest.
Greg was just making noises on PEG about expecting a new idiom in 10.2 that is a spin off from the Advanced GUI. If it is based too heavily on the Advanced GUI, it could be uninteresting, but he is right that there is certainly a big To Do item to deal with Appbuilder versus Architect in a less clumsy way.