Has anyone considered writing a basic frame to form conversion tool using prolint or something like that ?
Has anyone considered writing a basic frame to form
conversion tool using prolint or something like that ?
Out of interest, is the longer-term goal of such a tool to have an application that only uses the .NET UI for its presentation layer?
Julian's is an interesting question, which has caused us much internal debate. I think it's certainly worth its own thread.
I thought I'd lay out - as a starting point for discussion - some points of comparison between a conversion approach and an embedding approach.
1) Generally with conversion tools what you tend to have at the end of the conversion process is (to paraphrase the HHGG) something that looks almost, but not quite, like a .NET UI. OK, it would be a .NET UI, but it would be a skin in a sense. Work would be required to make it look and feel right and take advantage of all of the features the .NET UI's controls; and in some cases the UI would change completely based on the advanced capabilities of the controls (scheduling functionality is one case in particular). However, whether this is desirable from a business perspective depends, of course, on the business.
There's also the question of converting the event handling logic - the UI logic - and possibly also the business logic. Obviously an already SOA-enabled app helps here, for business logic at least. The issue is "converting" the UI and/or business logic developed using a variety of styles and methodologies.
2) Another approach would be to embed the frames into a new form container: embedding windows would require the creation of a new application shell or main window, or some similar infrastructure, which would control the embedding of existing frames as well as the launching of any new .NET UI forms. The to-be-embedded frames might require some work to allow them to be embedded, but the majority of the work would be in the infrastructure. With this approach the look and feel and functionality of the frames and their contents would remain unchanged for the most part.
Each window would then be converted piecemeal to use the .NET UI; this would be done from scratch. The question about converting the business and UI logic also applies here.
What are your thoughts and opinions about these or other migration, conversion or mix-n-match approaches?
-- peter
1)
We use a runtime screen grabber to convert the (structured) user interface from ADM1/ADM2 to DWP.
All (structured) UI logic like search functionality, description fields, automatic combo-boxes etc. is done automatically as well.
In a business application the screen layout of browsers/viewers will remain the same when the user interface is ADM1 or .NET.
All (unstructured) trigger code/application logic is converted manually to business logic procedures on the server.
We found it nearly impossible to convert this automatically.
The big advantage of DWP is that (for example) the layout is stored in a repository/database.
And there is only one procedure that renders the user interface of your choice.
2)
Easy, but I don't like it in the long term...
I suppose one of the really big questions here is what is one starting with and where is one headed. If one is starting with fat client ABL GUI and one is happy to stay with that, then it seems to me the Advanced GUI is a really cool way to spiff things up. Even if one's goal might be totally replacing every screen with .NET controls, the lovely thing is that one doesn't have to. One can target key screens and work progressively as it seems appropriate. If there were some tools to speed this along, so much the better, but it is inherently as needed, as demanded type of environment.
But, issues are a lot more complex if one is starting anywhere else or wants to end up anywhere else. Nothing about the Advanced GUI moves one any closer to UI and BL separation, for example.
Now, a ChUI to Advanced GUI tool would be very interesting .... if a bit optimistic!
Since the ABL UI and the .NET UI both are windows UI and (despite from details), the .NET UI should be considered the more advanced and more powerful UI and kind of automated conversion of the screen design should not be to complicated. Whether the UI is stored in code or already stored in a repository database.
Added functionalilty like the scheduler elements Peter mentioned can't be a result of a (semi-)automated conversion, because in the standard ABL UI tehre haven't been such UI elements. Automated processes can't create more (in that aspect) than the origin had to offer.
When the UI is (burried) in code, it should be possible to either parse/analyze the code or do this at runtime while walking the widget tree. When the UI is already in a repository form (Dynamics for instance), this approach is way easier.
But if this conversion is just for the UI and the code that drives the UI does not get converted (to almost working code) then developing this conversion routine is a complete waste of time! The UI portion of client development is just a bare minimum of the whole client development afford. And you don't need to be an expert coder to manually convert the visual layout.
Simon mentioned migration from ADM/ADM2 to DWP. That was a conversion of code structured in one well known UI logic methodology to another one. I've done the same with Dynamics to Dynamics4.NET and ADM2 to ADM2.NET in the Advanced GUI.
My experience so far is, that converting the appearance of an ABL widget based application to an attractive .NET Controls based appearance is relatively a piece of cake. It's the application runtime component framework (ADM2 in my sample) took way, way longer. And I doubt that with any other development methodology this is different.
Here is where this thread touches the thread from Mike Ormerod: Conversion of just the UI is a waste of time. Without a complete runtime framework/component library of any kind (or should I say ADM3 or OO-ADM) I don't see how a migration can be a success.
And even worst. The target code structure is unknown and after reading Mike Ormerod threads, I doubt that soon there will be a definition of the target structure. But what's missing as well, is a definition of the origin this conversion should be used for. Some developers used the AppBuilder just for the UI layout maintaining UPDATE, SET AND DISPLAY statements. Others had their own include file based frameworks. The next group coded every screen manually and others used ADM or ADM2.
Julian, if your initial post was really just for the visual layout and no bit of functionality, I'd consider it absolutely doable but I doubt if it's work the (even little) afford.
What I'd rather like to see in a future 10.1A release is added functionality in the Visual Designer (like selecting data base/data source fields in the AppBuilder) rather than having to maintain the DataBinding properties of any TextBox/CheckBox/RadioSet/... manually.
With that feature the conversion of (dump) frames to user controls or forms manually would be easy enough and an even well usable starting point for the conversion of the code.
But if this conversion is just for the UI and the
code that drives the UI does not get converted (to
almost working code) then developing this conversion
routine is a complete waste of time! The UI portion
of client development is just a bare minimum of the
whole client development afford. And you don't need
to be an expert coder to manually convert the visual
layout.
True, for us it was relatively easy because we use DWP and did not have to develop the underlying framework ourselves. We just had to convert the UI to the correct repository format and had instant working CRUD etc. functionality and could focus on converting the business logic (manually). In the time being we can use the standard DWP ABL renderer and wait until the Advanced UI matures.
It was for visual layout and code.
I would like to maximise the impact of the new .net gui (i.e convert as much as possible as fast as possible). I could easily hand that over to some "new" developers with basic instructions on how to "migrate".
Whilst this is going on, we could then use the more experienced developers to put together a proper structure (and, dare I say, framework) that we could migrate to over time.
I guess what I was envisaging was leveraging the power of prolint to
1) extract the gui components, and replace them with .net equivalents (either ms .net or infragistics)
2) extract the trigger code and merge and replace with the appropriate .net trigger code
3) extract the functions and procedures and include files
4) combine all of these into a new .cls file
I know, I know .. I ask for a lot .. but ... well .. I think ithat it would be worth it.
Actually, it sounds like what you are talking about is a variation on ProRefactor. It has access to the full parse tree of proparse plus a lot more information and already has a number of pieces related to recognizing UI pieces. If you have a budget and can describe some specs, I would consider talking to John Green about it.
BTW, as John has indicated in some posts on OE Hive, he is moving Proparse to Java and adding feature that would hand over the whole parse tree in a CLOB. This should simplify the interface to things like ProLint by removing the API. That and the XML output from ProRefactor are suggestive of some interesting tools.
I could imagine approaching this issue in two different ways. One would be as an actual refactoring project to make like substitutions of .NET functionality into existing ABL GUI programs. The other might be some kind of interactive tool used directly within OEA.
Are you considering ProLinting or ProRefactoring just your apps or also the framework/support code/foundation classes/...?
Especially for the framework piece of it, I guess that has be be a manual approach using various prototyping phases. Users probably need to recocnize the application they've been using for ages. The app needs to be demo-sexy. It needs to be maintainable. It might need a minor architecture change.
So I believe, it all starts with a definition of the target structure of code, client side business logic (UI handling code), etc.
A very common problem may be how to turn Progress UI screens with long running transactions and record locks (records lock and transaction start when the update starts) to something you can use in an MDI container. Long running transactions will kill you here. For some client client/server to N-tier might be important, I know many others that still don't want/need to make that move.
Is it realistic, that any refactoring solution will solve the architectural conversion and the UI conversion at the same time? I doubt it - but I'd love to be proven wrong here.
It would be great to call prorefactor, and get xml data back that would allow me to separate the functions and procedures, shove them into a separate .p, extract the gui and shove that into a abl form / dialog with the associated triggers. I would then have to "fix" what is broken.
But at least the vast majority of the gui layout would be done.
Don't suppose that John is on this list ?
Just the apps - I want to build my own framework using forms and classes and migrate my (already .netted) forms and procedures over to it piecemeal.
I agree whole-heartedly with paragraph 2. I also cannot forsee an automated tool providing the solution to the architectural conversion. I was just wanting to .net my form
Taking the limited time and ressources that Mike Omerod mentioned in the OERA/autoedge thread in the beta forum, personally believe that the majority of customers adopting the Advanced GUI would prefer to find a lightweight framework/functional components (like a toolbar with state management, grids with filters that filter at the backend rather than just on the client temp-table, lookup components etc.) than just a UI design copy routine.
They are two different things. I agree with you that a collection of production quality code (which could be combined to form a light framework) is extremely desirable, but I also would like this refactoring of exsiting code (no new functionality, just a capability of swapping out a gui widget for a .net control) would be most useful as well. This would allow the rapid migration to the .net UI. The framework / code collection would facilitate a slower, better migration.
I don't know your application but it sounds like it has trigger code in browsers and viewers and additional functions/procedures in browsers/viewers/containers with presentation logic and business logic mixed together.
If you are going to modify your application the way you say your are I really think you should take the opportunity and go one step further and look into the possibility of separating your user interface and logic as well. I know you have to rethink your application structure but it you are going to do the things you say you want to do I think you should take this into account as well.
In ADM2 there was the set oriented rowObjUpd temp-table in the SDO that was later modified to a record oriented data logic procedure in a separate procedure from the SDO. First there were the TransactionValidate procedures that were later split into the TransValidate procedures (adm2/datalogic.i). First is was "screen" oriented later it became "entity" oriented. I always liked the idea and it is still valid.
I think it is a good thing to isolate your transaction logic in "business entities" or "business logic containers" or whatever you like to call them. You can isolate your logic and reuse the logic from different locations. My experience is that this exercise really helps to clean-up your code because you are merging the code into a single transaction procedure. It also gives you a better insight in the transaction logic because it is all centralized.
It is possible to parse your trigger code and move it to the appropriate procedures in the business entity. But in my experience it is impossible to "load an go". Remember the relation between entity and screen is probably 1:N so you are processing multiple screens into one entity creating all sorts of conflicts and duplicate (different) code coming from multiple locations. Not to mention syntax/compile problems.
Next to the transaction logic there is application logic that are stored in procedures/functions that can be moved to the business entity together with the transaction logic or moved to a separate library.
And there is presentation logic (e.g. search functionality, conditional enabling of fields etc.). This can be done on the client or on the server where server processing is preferred so you don't need to code it for each user interface (.NET, Web etc.).
With the caveat that we don't use SmartObjects:
Yes, most of our maintenance screens are not separated at all. We have gone down the path of using objects and classes over the past two years, and we do not have any UI elements in the classes.
However we still have a large number of screens that are generated by / maintained in the Appbuilder and have UI and data logic mixed together.
In the short term, I want to "convert" these screens to the new UI, while we continue converting the application to OO and classes.
Eventually, the screens themselves will then be modified to use the new / existing classes as and when practical.
Ok, great!
You are looking for a short term conversion solution that will preserve the structure where it isn't a problem if UI and logic are mixed together. Finally the screens will be converted to your long term OO/class solution where UI and logic is separated.
In the short term, I want to "convert" these screens
to the new UI, while we continue converting the
application to OO and classes.
Eventually, the screens themselves will then be
modified to use the new / existing classes as and
when practical.
If the short-term goal is to have the old and new play together nicely*, and then to convert screens to the new desired design, would it not be easier to simply embed the older screens until their time has come?
-- peter
I'd consider a "screen-scraped" conversion as old, since it's basically just a screen refresh
I disagree (I would, wouldn't I?)
I would consider a screen-scraped conversion as new, as it "looks" sooooo much better. And you can easily have funky widgets such as ribbon bars or floating menu bars added with little or no effort. For example, you could provide a "skin" function for the application : A waste of developer time, but makes the client go "oooooooh! I like that"
Embedded screens will still look dated.
I would consider a screen-scraped conversion as new,
as it "looks" sooooo much better.
Embedded screens will still look dated.
Fair enough - the benefit of some UI improvement (far?) outweighs the effort required to create a tool and whatever manual coding is needed?
example, you could provide a "skin" function for the
application : A waste of developer time, but makes
the client go "oooooooh! I like that"
Incidentally, the Infragistics controls come with a control called the Runtime AppStylist, which allows you to apply skins to the whole app, from anywhere in the code.
I also happen to like shiny things like skins (could you tell? )
-- peter
Incidentally, the Infragistics controls come with a
wicked cool control called the
Runtime AppStylist, which allows you to apply skins
to the whole app, from anywhere in the code.
Which btw is available in the AutoEdge GUI HQ (4GL) demo app under menu "Misc".
I could not change anything but the Font but that is probably me...
What you are talking about is very much what John and I are working on, but its a wee bit more complicated than that. Check out my transformation triangle paper on OE Hive for a little background.
I can imagine a ProRefactor based tool which would take existing ABL GUI programs of whatever virtue and simply replace ABL GUI with .NET GUI constructs. Someone would have to figure out the mapping, but it sounds doable. But, this is certainly not going to deal with issues like UI on a locked buffer, long running transaction scope, UI/BL separation, etc. It will be strictly lipstick on a pig ... or lipstick on a model, depending on the quality of your code now.
Doing the more serious job is going to require conversion into a far more abstract form than even the UML we are creating now and will come a lot closer to a tool enabled fresh creation than it will a refactoring.
And, no, John decided not to participate in the beta this time since he is so busy, but we talk regularly!
Rearchitecting to modern standards is obviously desirable ... but is also way more difficult and expensive than merely dressing up the UI of what is already there.
That's the short-term goal. Make it look modern, whilst working on the inside to really make it modern.
Well, if you have a budget, based on getting it done faster and with less programmer effort per program, then I would open a discussion with John and see if you can't evolve a spec. ProRefactor is open source, so you could always do it yourself, but my experience is that he knows how to make these things happen without the long learning curve.
heh! Way ahead of you for a change !
That remains to be demonstrated ...
I have commissioned John to start a feasibility study on a simple window. We'll move on from there.
Yes, I know ... I've been talking to him too. It would be very interesting if he could figure out a way to do this that wasn't overly tied to the idiosyncrasies of your application because I can imagine a number of people being interested in it. If there is only some basic customization required on a per site basis to tune the inputs and adjust the desired output, it could be quite a boon for those with existing ABL GUI applications to make the switch completely and quickly, albeit without the architectural improvement.
I wish I believed it possible to do to a ChUI screen ...
We have agreed to make this an open source project once we have reached certain stages - I will be funding the initial development, and I want to make sure that it isn't confined to my application.
However, saying that, most of my application was written in the Appbuilder so it should work out of the box for most people (if we can get it to work in the first place).
I don't think for one second that this is a silver bullet - I imagine that there will be a fair amount of "finishing" to do, but I hope that most of the grunt work will be done automatically.
One of the requirements is that the app will be able to call out to different "writers" so that I / we / you can target different toolkits (MS .net, Infragistics, Telerik etc)
Well, we can only wait and see.
Sounds exciting!