CodeGear are letting some people blog about features in the next release of Delphi (Highlander) before it has even been released. How cool is that? A lot less secrecy, what a great move!

Sooooo. How about I spill some beans about ECO IV? Maybe I can find a thing or two to mention :-) I'll just throw together something unplanned, so expect a weird mixture of stuff in no logical order whatsoever!

Well, first of all, you're going to get a whole load of source code. I mean *lots* of it!

There's a new service called the ICacheContentService. Let's say you know for a fact that there is an object in the DB with the ECO_ID 1234 and it is a Customer. Instead of loading that object into the cache with an OclPS evaluation you can simply use this service to register it in the cache. I've found this really useful in an app I am writing where I use SQL to find customers matching a certain sales criteria. I then create an IObjectList of these customers by injecting their ID's into the cache.

There are some generics in there. The generated code is smaller as a result because you don't need a seconary "List" class for each class in your model. PersonListAdapter, CustomerListAdapeter etc. In addition to this it is easier to move from the Element world to the Business Object world. You can do stuff like this

MyElement.GetAsObject<Customer>.Name := 'Hello';
for currentCustomer in SomeElement.GetAsCollection<Customer> do

You can hibernate EcoSpaces. Can you deactivate an EcoSpace to a stream, a kind of snapshot. You can then later activate an EcoSpace from a stream, restoring the original state of the hibernated EcoSpace. This is useful when you want to shut down an application and then restart it where you left off. Maybe you could use it to "keep changes" made on the client without having to save them, and then later update the database. One certain use for this feature I see would be for storing EcoSpaces in a session where ASP.NET is using a DB as the session state so that multiple machines can serve the pages (a farm). I've done this using MonoRail rather than ASP.NET.

You can write ECO VCL.NET apps. Okay, it's not a big secret or anything, but I can tell you how good it is! I haven't played with TDataSet components in years now, but it all came rushing back to me as I played with components such as TExpressionHandle and TReferenceHandle, both descendants of TDataSet. Hooking up a TDBGrid to an ECO expression handle was so strange at first. It seemed like I was hooking up to a TQuery, that is until I started executing methods on the current row, and invoking state machine transitions. Then I felt at home again :-)

ASP.NET DataSource. ASP.NET stuff is so much more simple now. You have an EcoSpaceManager component on the web page that provides an instance of an EcoSpace. Then you have an EcoDataSource component which you can bind GUI controls to that are capable not only of showing the data of the selected ECO objects but also update it too without a single line of code. This approach is so much more simple than using all of those ECO handles on the form and having to manually update the form data into the objects.

ASP.NET Providers. You know 'em, the user, roles, settings etc that come with ASP.NET 2. Well, ECO supports a whole load of those too!

More frequent updates. You wont see this one in the box, this is one that ships afterwards. In the past ECO updates could only be shipped as part of a Delphi update. Well, things have changed. The ECO team (www.capableobjects.com) can now determine their own release schedules.

OCL enhancements. The OCL implementation used has now been extended so that it mirrors the .NET framework more. So you can do stuff like this (in OCL action language)

DatePosted := DateTime.Now.Date.AddDays(1)

BlackFish support. What else do I need to say?

Mapping enhancements. This one might not be a big feature that you'd write on a box, but it saves so much time! Remember in ECO III when you had to write a persistence mapper for every ENUM type in your model? No more! The mapper classes are now provided with type information when converting between DB/Model values so it is easy to write a single generic mapper class to work with any type (enums for example). In fact, you can now just set the PMapper of any ENUM to GenericEnumAsInteger and your enum property will be mapped to an INT column in your DB. What a time saver this one has proven to be!

Nullable types. You can now model your class attributes as Nullable<Integer> etc. So the following code...

Self.AsIObject.Properties.GetByLoopbackIndex(Eco_LoopbackIndices.DatePosted).AsObject := nil;

you can now do this

DatePosted := default(Nullable<datetime>);

Well, that's it for now. If I think of anything else I'll let you know. It's hard to remember what's new when you've been playing with it for so long!

Disclaimer: The code in this blog might not compile after shipping. Not because it is subject to change and other such legal stuff, but because I am typing from memory :-)


william said...

Nullable types! I don't know that... it is a great time saver since the models I have been using always include so many nullable attributes... BTW, any enhancement in testing the null?

I can see Enum is really improved so much and how about some helper classes to get the user friendly string representation (including spaces) of enum values? e.g. 'System Administrators' instead of 'SysAdmin' perhaps?

For hibernated EcoSpaces, I wonder would it be possible to do the business logic (my main purpose is secure audit trail/access control) on the server side by passing the EcoSpaces from clients to server just like the good old MIDAS?

Finally any suggestion in organizing the application into multiple DLLs and namespaces?

Anonymous said...

What is new on Winforms?

Peter Morris said...

William nullable:

Testing for null is very simple...

if not DatePosted.HasValue then
//It is nil

You can probably also do this, but I haven't tried except in C# which works...

if DatePosted = nil then
//It is nil


You could send stuff back and forth as a binary packet. In fact you can also tell ECO to only serialize dirty objects, all objects, or even a specific list of objects.

I expect it is possible using standard .NET techniques and overriding ToString.

Multiple DLLS / namespaces:
I always create my business classes as a separate DLL, what sort of thing did you have in mind?

WinForms aren't in Highlander, but that's not new news. Although I have been playing with ECO IV + WinForms in VS2005.

Anonymous said...

Hi Peter, good to know about ECOIV, some doubts:

I have the model in a dll using c# builder + together what about migrations the model from ECOIII to ECOIV in Visual Studio 2005?, which model editor I can use from VS, ModelMaker or Together yet?

What about the database support, I mean the community can get better support for instance in mySQL, now I have a model using attributes AutoInc, it work ok using MS SQL Server or Interbase but I get troubling generating the model to mySQL5, in some thread I read that I have to make my persitenceMapper ect, now I don't have time to do it, for that I would like to know if ECOIV has better support for other database.


Peter Morris said...

Hi Frank

I am currently using EcoModeler with VS2005. Gerrit has updated it to support ECO IV, Generics, and nullable types.

As for MySQL, there is a mapper for that in ECO IV.

Anonymous said...

I would known if there is a better support for the events (insert/modify/delete ..like ReceiveEventFromOwned/ReceiveQueryFromOwned in Bold) in ECO IV?



Anonymous said...

Thahks Peter for the info, but what about migration from EcoIII model to EcoModeler, I have to do again my model?, is there any idea if will be together eco editor model to vs2005, is there any info about the price EcoIV to VS + EcoModeler?

can I do model in different dll and associate class between different dll in both directions?


Peter Morris said...

No. It is possible, but no easier than it was in ECO III.

To upgrade a Together model to EcoModeler you can import the EcoPkg file.

It does not import any diagrams, and you will have to recreated your state diagrams too (as this is how EM state machines are actually defined).

After than you would need to generate code into a folder with no source and then copy/paste your method implementations over.

This are one-off steps.


Anonymous said...

Peter if I understand you, I have to import from EcoModeler the EcoPkg file and then create again all class diagram, association, ect... (in my case I don't use states diagram),

which is you advice about, migrate a project with 50 class at moment to EcoModeler, begin it from scratch will be better?

the doubts Peter is because I hope to buy ECOIV to Visual Studio, now I am developing with together, but the project is growing and I don't know if better begin the migration now to EcoModeler or wait for release the ECOIV.

can I make the EcoModeler from C# Builder 2006 and then migrate it to visual studio?

any advice is welcome


Peter Morris said...

Hi Frank:
"I have to import from EcoModeler the EcoPkg", correct, the EM project will create all classes, associations, properties, methods, etc.

"create again all class diagram, association, ect"

If you want diagrams then you can recreate them, but you don't have to. You don't have to recreate the associations, they are imported from the EcoPkg file.

EM is different compared to Together. In Together when you delete an association on a diagram you delete it from the model. In EM you only delete the view of the association from the diagram, it remains in the model. So, just because you don't have a diagram showing the association means nothing in EM.

In fact, if you add two associated classes to a diagram the existing associations will automatically appear too.

"which is you advice about, migrate a project with 50 class at moment to EcoModeler, begin it from scratch will be better?"

No. Import the EcoPkg file, generate source to an empty folder, and then just copy the method implementation source to the new files. That is definitely the best path to take!

"the doubts Peter is because I hope to buy ECOIV to Visual Studio, now I am developing with together, but the project is growing and I don't know if better begin the migration now to EcoModeler or wait for release the ECOIV."

I would continue to develop with Together and then migrate. It isn't much work at all, especially if you do not have state diagrams.

"can I make the EcoModeler from C# Builder 2006 and then migrate it to visual studio?"

Yes, but it will be using ECO III assemblies rather than ECO IV. There are some bug fixes in ECO IV which were not patch candidates in ECO III. It just depends whether or not you can live with those.


Anonymous said...

Thanks again Peter, other doubts about ECOIV, is noticeable the perfomance, retriving and update data in ECOIV?, I mean the performance in ECOIV is better that ECOIII?

some trouble like do ocl using like on attributes text in interbase or sql server are fixed?

any news about performance stability will be good to know.


Peter Morris said...

Hi Frank

Without specific bug reports I can't say because I don't know exactly what you mean.

If you can quote QC report numbers or enter example projects into bugs.capableobjects.com Jan has said he will run them through a profiler.

Peter Morris said...


Some of the persistence optimisations in ECO IV include

01: Loading of multi-links has been optimised. You can tell ECO IV to load the object as well as just the ID when a multi-link is fetched. E.G. PurchaseOrder will also fetch PurchaseOrderLines.

02: Accessing an element within an IObjectList will retrieve 50 objects at a time. So if you iterate over a list of 250 objects you will see 5 sets of DB access rather than 250.

Anonymous said...

Thanks Peter for the answer. I deduce that the help -you are writing- will be highly necessary....


william said...

Hi Peter, for multiple DLLs I mean separate the ECO classes into multiple DLLs, e.g.

CompanyA.ProductA.Accounting, etc.

and there exists a common base class MyBaseClass in the Common assembly while all other classes would inherit from it.

Peter Morris said...

Hi William

Why would you want to split the classes of a single app into multiple DLLs? Are you really asking if it is possible to reuse multiple packages in multiple apps?

Please explain in more detail :-)

Thomas Wolf said...

Hi Peter!

Sounds great. Will it be possible to handle struct-types in OCL-expressions? I'm using them in EvaluateAndSubscribe()-methods as a return value (in order to evaluate more than one value in one step).

If Attrib is a struct and Var1 is a member of the struct. it would be nice to type in the OCL-editor: 'MyObject.Attrib.Var1'

Actually this is not working with ECOIII because only known types like double, int etc. are allowed.

Thomas Wolf

Peter Morris said...

There's nothing that I am aware of in ECO IV that makes this any easier.

Why would you use a struct rather than a class?

If you really need to do this then I expect you'd have to implement an OCL extension which is specific to your application.

william said...

Hi Peter, the main reason why I would like to split the classes into multiple DLLs is extensibility, kinda like the plugin system. It would be nice if I could create an put in any new DLLs without recompiling the whole application... and another reason is security. In a 3-tier application there exists several server only classes which should not be known/used by the clients...

In fact I tried this kind of multiple DLLs approach in BDS 2006 and it created far much troubles for me and I put all the classes into a single DLL in the end :P

Anonymous said...

Peter in the newsgroup I wrote a issues in the thread subject: ocl to sql generation error?

I reported it in http://qc.codegear.com/wc/qcmain.aspx?d=51244

What about ECO IV with this issue?

to me it is a basic query, so is better the generation sql in eco IV, any info is welcome