New OpenEdge 10.1 based MVC Material

For those of you that downloaded just the code sample, especially before today (August 16th), you may find the whitepaper enclosed in the .zip has a corrupt image on page 5. We have now fixed the file in the .zip.

If you only downloaded the document then you will be ok.

So if you did download just the zip, you can either download the .zip again, or simply download the document.

Sorry for any inconvenience.

This was a public broadcast message brought to you by Applied Technology

Mike

FWIW, I am still having some what look like font issues with a fresh copy. Both the numbers in the illustration on page and the bullets on that and preceeding pages. Only the 1 in the diagram is readable unless I cut and paste into Word, then I can see the numbers fine.

As noted on another thread, it is hard to test this code with missing files.

But, flipping through the code, I am wondering why it is that the controller knows about buttons in the view. Shouldn't the controller only know about actions?

As noted on another thread, it is hard to test this

code with missing files.

The MVC examples are complete and should run, so if they don't then let us know. As also mentioned in the other thread, all the samples should run, provided we've supplied the set up details , which we unfortunately missed and will be posting asap. But as also mentioned, the samples and reference pieces are provided to explain a particular topic, and as such the source that is provided for that sample is only for that sample, the rest of the supporting code is within a library, so we can help focus on just the pertinent piece.

We will in the next few weeks be posting the complete application example (AutoEdge) which a lot of the work is based upon. This will contain the source for the example application so you will get the complete picture. What we didn't want to do was post the complete example, without the supporting explanations of each piece, hence why the samples have been delivered first. So at that point you will have both, some focused samples and reference material, plus the whole complete example, with source, which is runable.

But, flipping through the code, I am wondering why it

is that the controller knows about buttons in the

view. Shouldn't the controller only know about

actions?

Not wishing to accused of avoiding the issue, I'll let John answer that one

Ok, Hopefully 3rd time lucky. It looks like the conversion to pdf did something to the image, so I increased the size of the boxes for each number, so it should be ok now.

FWIW, after discovering that I needed to go back to a shared directory and having accidently deleted a couple of the source zips, I decided to go back and get a fresh copy of everything. I had some trouble finding the MVC stuff until I came back to this thread because I ended up in a presentation folder that didn't have it. When I try to go back and give you the path to it, I find the one who has it ... suffice it to say that I haven't found navigating the library entirely intuitive.

At any rate, do I now have a complete set of the sample code that has been released? I have:

Business Entity

Context Manager

Data Access Object

Data Source Object

MVC

Open Edge Service Adapter

Service Interface

Service Manager

Is that it?

When you do release the complete application, will this stuff get updated with pointers to it?

..

At any rate, do I now have a complete set of the

sample code that has been released? I have:

Business Entity

Context Manager

Data Access Object

Data Source Object

MVC

Open Edge Service Adapter

Service Interface

Service Manager

Is that it?

I think that is the list as of today (there is new stuff on it's way).

When you do release the complete application, will

this stuff get updated with pointers to it?

The links will get updated in the postings, yes.

Yes, in principle the Controller should only deal with abstract events without knowing or caring what exact UI control (or other entity) generated the event. The sample controller procedure represents something of a simplification in this respect. Parts of its code are reasonably independent of any knowledge of the UI controls, such as the simple state map for managing the enabling and disabling of actions such as update and navigation (where the notion of 'enable' could be translated into specific code such as handle:SENSITIVE = YES or into some entirely different way of telling the View to enable an action). But there must be another layer that translates those abstractions into controller actions that the UI can accept, such as the APPLY statements in the controller code. The general idea is that in a full-blown implementation, these two aspects of the controller can be reasonably well separated out, to support a variety of user interface options. In fact, the controller logic event in the sample does not really care whether the object that generated an event was a button, but the layer of the code that receives notification of the event -- the part that is UI specific -- must know how to identify the event for the particular UI being interacted with, in this case using the ABL attributes to identify the UI object and its event (such as SELF:TYPE). Otherwise BUTTON can be taken to mean any event generator that represents activation of a one-event control (such as CHOOSE of a button whose event means 'Select Next'), and FILL-IN can be taken to mean any object that holds the value of a single data field. As far as it goes, the sample therefore tries to show some of the ways to think about removing the event logic from the UI itself, and ways to use the latest ABL capabilities such as the BIND option; much more needs to be done to complete a usable MVC pattern.

Well, not to be picky, but it seems to me that if one is going to promulgate and official set of sample code to illustrate a particular model, then it should be a good implementation of the model, i.e., one should go to the work to make it fully illustrate the principle. That this example illustrates the used of BIND is fine, but it isn't called The BIND Example, it is the MVC Example.

From http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html:

"...

In the MVC paradigm the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task. The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). The formal separation of these three tasks is an important notion that is particularly suited to Smalltalk-80 where the basic behavior can be embodied in abstract objects: View, Controller, Model and Object.

..."

And from http://martinfowler.com/eaaDev/uiArchs.html:

"...

In MVC I'm assuming a Domain Model of regular objects, rather than the Record Set notion that I had in Forms and Controls. This reflects the general assumption behind the design. Forms and Controls assumed that most people wanted to easily manipulate data from a relational database, MVC assumes we are manipulating regular Smalltalk objects.

..."

There is an interesting point here: we tend to use (databind) datasets and resultsets as our model, while the original MVC-design uses domain objects, which encapsulate data and behavior, as their model. Why? In a remoted scenario, we don't want to be tied to an AppServer during the lifetime of the form. Solution for that was the data transfer object (ProDataSet for ABL). So to fix the original MVC-architecture, we have to create a ModelFacade. This is a facade to stateless AppServer services and the communicated ProDataSet. It will provide the original Model functionality. Question when I read this fragment from http://www.psdn.com/library/entry.jspa?externalID=1594&categoryID=290:

"...

This paper’s examples could form the basis for an implementation of an MVC Presentation layer that effectively works with Business Entities on one end and with a native OpenEdge or non-OpenEdge user interface.

..."

Isn't the "native OpenEdge or non-OpenEdge user interface" communicating data (datasets) instead of talking to a domain model? I think it will be hard for .Net to bind to an ABL-object.

Fowler talks about two kinds of controller, one the historical controller of MVC and the other a pattern he calls Application Contoller. In his Patterns of Enterprise Application Architecture he notes that the separation between model and view is the more important separation and that, in practice, the separation between the view and contoller, what we might call the MVC controller to make this more clear relative to Application Controller, is less important and often disappears in a rich client. I suppose that what I am really championing here is the Application Controller since that is what allows one to separate the UI from the domain and provide multiple UIs with a single domain object.

Isn't the "native OpenEdge or non-OpenEdge user interface" communicating

data (datasets) instead of talking to a domain model? I think it will be hard

for .Net to bind to an ABL-object.

Right now, of course, one can't send an object over the wire, per se. I'm not sure this is actually an important limitation since one can have an identical class on both ends of the wire and populate it with a transmitted dataset, effectively "teleporting" the object, except for its identity. This, of course, means that the other end doesn't need to be ABL and it also means that the receiving object doesn't actually have to be identical ... if might be read-only, for example.

...

Isn't the "native OpenEdge or non-OpenEdge user

interface" communicating data (datasets) instead of

talking to a domain model? I think it will be hard

for .Net to bind to an ABL-object.

Probably me being stupid here, so go easy, but I don't get what you mean by '.Net to bind to an ABL object'? As you said earlier in your post, the ProDataset is basically the DTO, and through use of proxy-gen you can happily transport the dataset to .NET, or are you saying you wish to transport more than the DTO, but the entire object? If so, how would that work in a disconnected world, when you don't know what technology is being used by the requestor?

Well, not to be picky, but it seems to me that if one

is going to promulgate an official set of sample

code to illustrate a particular model, then it should

be a good implementation of the model...

Part of the answer to your point is that we don't intend that anyone take samples posted by PSC employees as necessarily being "official" in the sense that they are totally complete, or represent a single unified corporate point of view, or are supported in any way. We try to make sure that what we post is useful and in some sense exemplary. The code as posted isn't totally complete in many ways, some of which are called out in comments in the code or comments in the paper, and some not. As far as it goes, the examples show a way (not necessarily the way) to create a Presentation layer where the UI definition is very thin and dirt simple, where a separate procedure can manage standard useful events in a standard way, and where the data itself is kept separate from both but available to the UI for display and editing. This is what the paper and the examples are trying to show. No doubt much is left to the resourcefulness of the reader to adapt and complete the example, or simply to use it as an interesting point of reference.

We try to make sure that what we post is useful and in some sense

exemplary.

Well, what I am suggesting is that this is not a case in which it was exemplary.

I realize that I am being hard on you John, but it is only because I am looking for excellence. 10.1A and OERA has gotten me really excited about this product again and the acquistions you have made add even more zing, especially if you figure out how to get the licensing down out of the stratosphere.

But, the world is full of a lot of really ugly and bad ABL code. Some of that comes from trying to do things when the language support wasn't what it was today and a lot of it comes from not having had a strong architectural model to guide us. The implicit architectural model in a lot of PSC code hasn't been a very good guide historically, but with OERA you have leapt out to the front.

But, to back this up, you need excellent code examples to go with it. People are looking at this code trying to learn. But, they are going to learn both the good things that you intended them to learn and any bad things which you let creep in. Or, as in this case, they learn at best half a lesson because there is no guidance in how to approach having multiple UIs work off the same code base as we expect to be able to do in an OERA context. People need help making the leap from the concept to the concrete.

Is that hard? Sure, it is very hard. But excellence is always hard.

There is an interesting point here: we tend to use

(databind) datasets and resultsets as our model,

while the original MVC-design uses domain objects,

which encapsulate data and behavior, as their model.

I think the basic objectives of MVC are quite independent of whether the application is dealing with true domain objects or relational datasets or something else. While we are adding object-oriented capabilities to the programming language, we still can be quite unapologetic about the fact that our 'native' internal data format matches the relational form of the data in the database, which simplifies both the physical-logical mapping and the business logic. Fowler himself estimates that a third of most programming projects (in languages like Java and C#) is consumed in bridging the object-relational gap in data representation, which is something we aren't faced with. So identifying the usefulness of identifiable sub-parts that represent View, Controller, and Model is very valuable even if used and implemented perhaps very differently from Smalltalk.

Isn't the "native OpenEdge or non-OpenEdge user

interface" communicating data (datasets) instead of

talking to a domain model? I think it will be hard

for .Net to bind to an ABL-object.

See response to Thomas's response.

Fowler talks about two kinds of controller, one the

historical controller of MVC and the other a pattern

he calls Application Contoller. ... the

separation between the view and contoller, what we

might call the MVC controller to make this more clear

relative to Application Controller, is less important

and often disappears in a rich client. ...

Another point I would make here is that maintaining a clearly separate Controller (whether I have succeeded at that in the current sample code or not) has great value, even in a rich client environment, because it enables you to code the standard capabilities of the UI as "features" which are pervasive, consistent, and mostly "free" to the UI developer who inherits them simply by assembling screens using appropriate conventions. Letting the Controller disappear into the View because the rich client programming environment allows it encourages programmers to wire too much repetitive and inconsistent behavior into the UI screen by screen.

Right now, of course, one can't send an object over

the wire, per se. I'm not sure this is actually an

important limitation since one can have an identical

class on both ends of the wire and populate it with a

transmitted dataset, effectively "teleporting" the

object, except for its identity. This, of course,

means that the other end doesn't need to be ABL and

it also means that the receiving object doesn't

actually have to be identical ... if might be

read-only, for example.

Yes, without commenting on the future direction of the class-based enhancements to ABL, it seems very appropriate to pass around relational datasets within the application without accompanying each with its (possibly class-based) behavior. For one thing, the behavior (r-code) is a lot of bytes relative to the data in many cases, and many instances of data for Orders all carry the same or largely the same behavior. Also, in a business application, the behavior you want to have available on the client is not necessarily the same behavior you want to have available on the server, so passing all the behavior around isn't necessarily useful anyway. Again, we can learn from and apply principles that come to us from the OO world without necessarily adopting all the baggage that comes along with them in a strictly object-oriented development environment.

Also, in a business application, the behavior you want to have available on

the client is not necessarily the same behavior you want to have available on

the server, so passing all the behavior around isn't necessarily useful

anyway. Again, we can learn from and apply principles that come to us from

the OO world without necessarily adopting all the baggage that comes along

with them in a strictly object-oriented development environment.

Not to mention that passing between a rich client and a server is just a special case of passing between services, where OO language applications don't pass objects either.

hi. I'm having some problems with the provided example. Apparently i'm missing a beOrder procedure. where can i find that? Should i build that from the beSupport procedure??

hi. I'm having some problems with the provided

example. Apparently i'm missing a beOrder procedure.

where can i find that? Should i build that from the

beSupport procedure??

Hi, you have to make sure you've downloaded the original set of code first from here (http://www.psdn.com/library/entry.jspa?externalID=1442&categoryID=289) then extract the MVC code and you should be all set.

HTH

Mike

Oaki, it worked. 10x a lot(maan i'm lost in this code...)

You might consider supplementing the MVC code with the AutoEdge code. The AE code might seem positively overwhelming at first, but it not only has the advantage of being embedded in a complete example so that you can see the interfaces and connections, but it is also exceptionally well documented.

yeah, i think i kinnda did this wrong , starting with the mvc materials, and then with the oera owerview...