Best way to break out non GUI code using ENVY?

On Monday, October 27, 2014 4:48:47 PM UTC-4, Richard Sargent wrote:

>> I have an application that has lots of GUI code in it.  I want to begin to carve out some things that I can derive a Windows service from and
>> so what is the best way to do this?

If you haven't already built it with a model separate from the UI, that should be your first step. (The last time I looked, VisualAge Smalltalk had a To Do List example which programmed everything in the GUI. This encourages people to make the mistake of not separating the view from the model, which means you run out of options real fast.)

The Rafactoring Browser tools can be a big help splitting up your code, but they have their own learning curve. You might be just as far ahead to file out the existing code, and bulk edit class and application names to allow you to file in a clone of the existing code. Strip out the #abtBuildInternals and the various #IS_* methods in the clone. Convert event handling methods to an API for the new model. (i.e. If there is a method which does something when a certain button is clicked, strip out any GUI residue from it and give it a good name, one suitable for your nascent model's API. Create attribute declarations for elements of the model you wish to connect directly in the UI.)

You should be able to create tests which exercise the model independent of the UI, so you can verify basic correctness. Then you can remove the modelling code from the UI and connect up the model objects to what remains.

Needless to say, this is a non-trivial exercise. :-)



>> Is it possible to have some of my GUI code references compile to polymorphic non-GUI code an a different configuration map?

This isn't clear enough for me to answer. Can you provide an example from your existing code and a schematic of what you would see changed in it to match what you have described in your question?

 

Hi Richard,

 

Thanks.  Yes of course I know that the GUI and the application model code should be designed and developed decoupled.  However, this is a highly mature codebase which existed before I arrived on the scene.  No such principles were followed.

 

So, now I am in a nonenviable position.  :-(

 

What I am imagining is:

 

1) I start with a clean image

2) I create a new application

3) I produce subapplications which replace GUI classes of the same name

4) I add subapplications to the new application which belong to a different application (which is not loaded).  References in these applications to GUI classes now are bound to the non-GUI classes mentioned in step 3

 

Not doable?  Do I really have to file out all my code and file it back in?  That would force me to maintain the code in two different places.

 

Thanks,

 

-Carl

 

Thanks to you all for your suggestions.  The functionality I am isolating is a report generation service.  It doesn't interact very much at all with GUI classes, so I am expecting that my approach will work well, but I need to understand how to use ENVY to do this.

 

I am loathe to file out code and then file it into another application.  The code should exist in only one place in the code repository.

 

-Carl

On Tuesday, October 28, 2014 8:31:04 AM UTC-4, Joachim Tuchel wrote:

Carl,

I am skeptical about your approach. In theory, you can do lots of things like that, and if you think and work hard enough, this might actually lead to a working codebase.

On the other hand, my fear would be that you fight lots of proxy wars on areas that require a lot of time, attention and thought. You'll probably get lost in areas of your mocking gui code that you never actually dreamed of in your wildest and scariest dreams. I'd try to avoid getting lost in such battles. I remember trying to put code like yours under test by mocking the CW and EW layer. We gave up for even easy things after several weeks. We lost a lot of time and every single day was depressing ;-)

Sebastian's suggestion sounds like a funny and hacky approach and if he says it works, then I trust in it.

I would, however, bite the bullet and start isolating "model" code into new classes in new applications that have no GUI prereqs, but are prereqs to existing guy applications. Maybe you can start by subclassing your current classes and use these subclasses as shallow facades for your new "clean" model classes. For these new shallow classes, it would be okay to depend on gui applications, as long as they really just delegate from the gui- to the non-gui-world and vice versa.

The facades give you a chance to structurally improve your code over time by still providing the old api to existing gui code. While a mocked GUI would leave your code in the sad state that it's in now, just that it runs without a physical GUI. So chances are you'll have to restructure it for further improvements anyways.

This is sure not little work, but I am sure there is much less risk associated to it.

HTH

Joachim

Am Montag, 27. Oktober 2014 22:07:27 UTC+1 schrieb Carl Gundel:

On Monday, October 27, 2014 4:48:47 PM UTC-4, Richard Sargent wrote:

>> I have an application that has lots of GUI code in it.  I want to begin to carve out some things that I can derive a Windows service from and
>> so what is the best way to do this?

If you haven't already built it with a model separate from the UI, that should be your first step. (The last time I looked, VisualAge Smalltalk had a To Do List example which programmed everything in the GUI. This encourages people to make the mistake of not separating the view from the model, which means you run out of options real fast.)

The Rafactoring Browser tools can be a big help splitting up your code, but they have their own learning curve. You might be just as far ahead to file out the existing code, and bulk edit class and application names to allow you to file in a clone of the existing code. Strip out the #abtBuildInternals and the various #IS_* methods in the clone. Convert event handling methods to an API for the new model. (i.e. If there is a method which does something when a certain button is clicked, strip out any GUI residue from it and give it a good name, one suitable for your nascent model's API. Create attribute declarations for elements of the model you wish to connect directly in the UI.)

You should be able to create tests which exercise the model independent of the UI, so you can verify basic correctness. Then you can remove the modelling code from the UI and connect up the model objects to what remains.

Needless to say, this is a non-trivial exercise. :-)



>> Is it possible to have some of my GUI code references compile to polymorphic non-GUI code an a different configuration map?

This isn't clear enough for me to answer. Can you provide an example from your existing code and a schematic of what you would see changed in it to match what you have described in your question?

 

Hi Richard,

 

Thanks.  Yes of course I know that the GUI and the application model code should be designed and developed decoupled.  However, this is a highly mature codebase which existed before I arrived on the scene.  No such principles were followed.

 

So, now I am in a nonenviable position.  :-(

 

What I am imagining is:

 

1) I start with a clean image

2) I create a new application

3) I produce subapplications which replace GUI classes of the same name

4) I add subapplications to the new application which belong to a different application (which is not loaded).  References in these applications to GUI classes now are bound to the non-GUI classes mentioned in step 3

 

Not doable?  Do I really have to file out all my code and file it back in?  That would force me to maintain the code in two different places.

 

Thanks,

 

-Carl

 

Carl,

so what you say is you have classes that should already be independent of GUI classes and you are looking for a way to make the containing Application clean of GUI prereqs?

What you can do is move these classes to another Application (you lose the version history, but so do you if you file out/filein). Or you can just try changing the prereqs of your application.

But maybe I misunderstand completely....

Joachim

Am Mittwoch, 29. Oktober 2014 14:55:50 UTC+1 schrieb Carl Gundel:

Thanks to you all for your suggestions.  The functionality I am isolating is a report generation service.  It doesn't interact very much at all with GUI classes, so I am expecting that my approach will work well, but I need to understand how to use ENVY to do this.

 

I am loathe to file out code and then file it into another application.  The code should exist in only one place in the code repository.

 

-Carl

On Tuesday, October 28, 2014 8:31:04 AM UTC-4, Joachim Tuchel wrote:

Carl,

I am skeptical about your approach. In theory, you can do lots of things like that, and if you think and work hard enough, this might actually lead to a working codebase.

On the other hand, my fear would be that you fight lots of proxy wars on areas that require a lot of time, attention and thought. You'll probably get lost in areas of your mocking gui code that you never actually dreamed of in your wildest and scariest dreams. I'd try to avoid getting lost in such battles. I remember trying to put code like yours under test by mocking the CW and EW layer. We gave up for even easy things after several weeks. We lost a lot of time and every single day was depressing ;-)

Sebastian's suggestion sounds like a funny and hacky approach and if he says it works, then I trust in it.

I would, however, bite the bullet and start isolating "model" code into new classes in new applications that have no GUI prereqs, but are prereqs to existing guy applications. Maybe you can start by subclassing your current classes and use these subclasses as shallow facades for your new "clean" model classes. For these new shallow classes, it would be okay to depend on gui applications, as long as they really just delegate from the gui- to the non-gui-world and vice versa.

The facades give you a chance to structurally improve your code over time by still providing the old api to existing gui code. While a mocked GUI would leave your code in the sad state that it's in now, just that it runs without a physical GUI. So chances are you'll have to restructure it for further improvements anyways.

This is sure not little work, but I am sure there is much less risk associated to it.

HTH

Joachim

Am Montag, 27. Oktober 2014 22:07:27 UTC+1 schrieb Carl Gundel:

On Monday, October 27, 2014 4:48:47 PM UTC-4, Richard Sargent wrote:

>> I have an application that has lots of GUI code in it.  I want to begin to carve out some things that I can derive a Windows service from and
>> so what is the best way to do this?

If you haven't already built it with a model separate from the UI, that should be your first step. (The last time I looked, VisualAge Smalltalk had a To Do List example which programmed everything in the GUI. This encourages people to make the mistake of not separating the view from the model, which means you run out of options real fast.)

The Rafactoring Browser tools can be a big help splitting up your code, but they have their own learning curve. You might be just as far ahead to file out the existing code, and bulk edit class and application names to allow you to file in a clone of the existing code. Strip out the #abtBuildInternals and the various #IS_* methods in the clone. Convert event handling methods to an API for the new model. (i.e. If there is a method which does something when a certain button is clicked, strip out any GUI residue from it and give it a good name, one suitable for your nascent model's API. Create attribute declarations for elements of the model you wish to connect directly in the UI.)

You should be able to create tests which exercise the model independent of the UI, so you can verify basic correctness. Then you can remove the modelling code from the UI and connect up the model objects to what remains.

Needless to say, this is a non-trivial exercise. :-)



>> Is it possible to have some of my GUI code references compile to polymorphic non-GUI code an a different configuration map?

This isn't clear enough for me to answer. Can you provide an example from your existing code and a schematic of what you would see changed in it to match what you have described in your question?

 

Hi Richard,

 

Thanks.  Yes of course I know that the GUI and the application model code should be designed and developed decoupled.  However, this is a highly mature codebase which existed before I arrived on the scene.  No such principles were followed.

 

So, now I am in a nonenviable position.  :-(

 

What I am imagining is:

 

1) I start with a clean image

2) I create a new application

3) I produce subapplications which replace GUI classes of the same name

4) I add subapplications to the new application which belong to a different application (which is not loaded).  References in these applications to GUI classes now are bound to the non-GUI classes mentioned in step 3

 

Not doable?  Do I really have to file out all my code and file it back in?  That would force me to maintain the code in two different places.

 

Thanks,

 

-Carl