Page 1 of 1

We need an Object Model

PostPosted: Mon Feb 11, 2008 7:20 pm
by mxvanzant
I would like to see some kind of object model in Servoy such as:

actual database (Sybase, etc.)
||
database layer (Servoy dataproviders)
||
object model layer (this would be new)
||
user interface layer (Servoy layouts)

This would allow the binding of your layouts to your object model instead of directly to your database layer.

It would allow binding a list view to a list of objects in your object model such as: customer.phonenumbers. And data fields directly to object properties (like get???() methods in Java or properties in C#) such as customer.firstName.

Value lists could be bound to lists of objects.

Calculations would be replaced by object methods or properties.

The current Servoy system of tables, relationships, calculations and table methods is a very disjointed way of presenting some aspects of an object model. A true object model would be much easier to work with and also encapsulate code in an organized manner.

Object code could perform validation and could also present edit and formatting masks and/or allow binding not just of object properties (to get the data) but also of edit and formatting masks.

To get some idea of what object models are all about, please see:

http://www.service-architecture.com/database/articles/object_model_concepts.html

and

http://www.db4o.com/about/productinformation/whitepapers/

I hope this feature request starts a discussion!

Thanks!

PostPosted: Wed Feb 13, 2008 7:04 pm
by david
It is not immediately obvious but the current Servoy structure gives you plenty of room to abstract your own object model. Ex: put all your value lists in a value list module, build generic code routines and put them in a module, put all your graphics in another module, put specific business workflow screens in their own modules separate from solution functions like record and form navigation, code generic search functionality, code generic validators, etc.

Goal #1 of an object model is separation of GUI, generic solution functionality, and specific business workflow functionality. This let's you focus coding business functionality without worrying the same time with record navigation for example.

Goal #2 of an object model is reusability. A simple example of this is putting value lists in one module so they can be used everywhere and thus avoiding creating the same value list in several modules.

You can get all these advantages in Servoy if you go about structuring your solution and code to this effect. It takes a bit of experience with Servoy to accomplish for sure. I know how much work it took us to get all this figured so I am not about to disagree with you that it is possible things would have been easier if Servoy was structured a bit different!

BUT, what we have accomplished with Servoy would be impossible to nearly impossible to do with any other IDE. That is just a fact.

Attached is a screen shot of a CRM screen in our frameworks which is currently in release candidate phase. If you're interested in checking it out:

http://frameworks.data-mosaic.com

Just create your specific business workflow screens, our frameworks takes care of the rest for you.