This works:

    
// Use RTrim to eliminate trailing spaces from char field
fields.DefineField(CustomerFieldIndex.CustomerCode, 2, "Customer Code", "Customer");
EntityField2 CustomerCode = (EntityField2)CustomerFields.CustomerCode;
CustomerCode.ObjectAlias = "Customer";
FunctionExpression sqlRTrim = new FunctionExpression(CustomerCode, "RTrim");
fields[2].ExpressionToApply = sqlRTrim;

But seems clumsy, is there a way to do something like:

// Use RTrim to eliminate trailing spaces from char field
fields.DefineField(CustomerFieldIndex.CustomerCode, 2, "Customer Code", "Customer");
FunctionExpression sqlRTrim = new FunctionExpression(fields[2], "RTrim");
fields[2].ExpressionToApply = sqlRTrim;

without a stack overflow?

or even better would be

// Use RTrim to eliminate trailing spaces from char field
FunctionExpression sqlRTrim = new FunctionExpression( "RTrim");
fields.DefineField(CustomerFieldIndex.CustomerCode, 2, "Customer Code", "Customer",sqlRTrim);

A stack overflow exception is easily tracked: what code calls itself in an infinite loop? It would be helpful if you could paste that code or explain where that happens.

Either way:

fields[2].SetExpression(new FunctionExpression(CustomerFields.CustomerCode.SetObjectAlias("Customer"), "RTrim")); 

should do it too

It would be helpful if you could paste that code or explain where that happens.

In the second example, when I try to use the field I've build for my dynamic list, as input to the constructor of the expression.

FunctionExpression sqlRTrim = new FunctionExpression(fields[2], "RTrim");
fields[2].ExpressionToApply = sqlRTrim;

I see the "loop", so I quickly tried the other methods I displayed.

The thing that seems "wrong" about the code you replied with and my code that works:

fields.DefineField(CustomerFieldIndex.CustomerCode, 2, "Customer Code", "Customer");
fields[2].SetExpression(new FunctionExpression(CustomerFields.CustomerCode.SetObjectAlias("Customer"), "RTrim")); 

Is that it feels like I am specifying the contents of the field twice, once as CustomerCode, then replacing that (but using it's DataType) with as rTrim(CustomerCode).

So more natural would be something like:

fields.DefineField(new FunctionExpression(CustomerFields.CustomerCode, "RTrim",System.String), 2, "Customer Code", "Customer");

But I understand that an expression isn't a EntityField, so this can't work this way.

Thanks for your help.

I think the loop indeed is about the field containing the expression is also part of the expression and is then thus evaluated, which then causes the expression to be evaluated etc. etc.

About the somewhat odd setup for expressions: I hear you, I also find it a bit odd. I'm currently looking into solutions for this, though it will be hard to make an Expression object act like a true entityfield object. The interfaces can help but the big problem is the operator overloading stuff which then won't work anymore...

About the somewhat odd setup for expressions: I hear you, I also find it a bit odd. I'm currently looking into solutions for this, though it will be hard to make an Expression object act like a true entityfield object. The interfaces can help but the big problem is the operator overloading stuff which then won't work anymore...

Given a choice, I would give up operator overloading to get expressions that act as fields, and the ability to express rich expressions done either on the database side or the client side.

Have you looked down the path of a field having a data source. The data source could be responsible for getting the data from the database, manipulating other fields to get the data, etc.

arschr wrote:

About the somewhat odd setup for expressions: I hear you, I also find it a bit odd. I'm currently looking into solutions for this, though it will be hard to make an Expression object act like a true entityfield object. The interfaces can help but the big problem is the operator overloading stuff which then won't work anymore...

Given a choice, I would give up operator overloading to get expressions that act as fields, and the ability to express rich expressions done either on the database side or the client side.

I'll try to find a solid solution. I have to, as in v2. function calls are supported and it then gets awkward as well, so I want to solve it properly once. Though all my attempts to solve this failed till now, but I still hope to find a solution soon.

Have you looked down the path of a field having a data source. The data source could be responsible for getting the data from the database, manipulating other fields to get the data, etc.

In what context are you thinking of using this?

Quote:

Have you looked down the path of a field having a data source. The data source could be responsible for getting the data from the database, manipulating other fields to get the data, etc. End Quote:

In what context are you thinking of using this?

I can't say I've thought it through, but on the surface it seems a field get's it's data from somewhere, straight passthrough from database, an expression/function on database side (case when i = 1 then 'sad' else 'happy' end) or an expression/function on the client side ([client side fielda] = [serversideside fieldb]/100) or ([client side fieldb] = summary of [client side field x contained in collection hanging off of an entity]

So, my thinking is, that building every field as an expression, many of which are very simple "passthrough" expressions, gives the foundation to build on. The expression language then has to be able to express the kind of things we want to do, on both the server side and the client side. Things like conditionals, arithmatic, agregates, manipulations etc.

arschr wrote:

Quote:

Have you looked down the path of a field having a data source. The data source could be responsible for getting the data from the database, manipulating other fields to get the data, etc. End Quote:

In what context are you thinking of using this?

I can't say I've thought it through, but on the surface it seems a field get's it's data from somewhere, straight passthrough from database, an expression/function on database side (case when i = 1 then 'sad' else 'happy' end) or an expression/function on the client side ([client side fielda] = [serversideside fieldb]/100) or ([client side fieldb] = summary of [client side field x contained in collection hanging off of an entity]

So, my thinking is, that building every field as an expression, many of which are very simple "passthrough" expressions, gives the foundation to build on. The expression language then has to be able to express the kind of things we want to do, on both the server side and the client side. Things like conditionals, arithmatic, agregates, manipulations etc.

Interesting!

There are two things I think: entities on one side and the big pile of all their fields (attributes so you will) on the other side.

Working with entities sees the entity as the item you work and an entity field is just that: the field of an entity.

Working with the fields/attributes, for example in lists, opens up possibilities like aggregates/groupby and expressions which are out of place in the world of the entity.

In the world of fields/attributes I think indeed that working with an 'expression' is more appropriate than working with a 'field' and apply stuff onto that field. In the world of the entity, I think the entity is what you're using.

In v2.0 entityviews will be added and entityviews are filtered / sorted 'views' on an entitycollection. You then can create projections from these views, to datatable, new entities or custom classes, and these projections can contain complex processing logic.

I hope to address the need for function calls and expression fields in entities through the designer for entities, and for field/attribute usage in code for lists, I hope to be able to find a solution for the 'add what you want to a field object' problem, as it's not intuitive.

I like your datasource idea. I don't think it's applicable for the entity world, but for the world where you work with fields/attributes like in typed lists/dynamic lists and also in filters. As everthing internally is build around the field object, it's a bit problematic to say the least to change that and build it around the datasource/expression object, but if I can make a datasource/expression look like a field, we're also done Thanks for offering this ideas

Working with entities sees the entity as the item you work and an entity field is just that: the field of an entity.

Working with the fields/attributes, for example in lists, opens up possibilities like aggregates/groupby and expressions which are out of place in the world of the entity.

I'm not sure the two ideas can't be reconciled. Entities could have both integral attributes and calculated attributes. Calculated attributes could be aggregates (total order amount) or group by collections of (possibly derived) child entity views ( say order information with multiple attributes summarized by sales man). It may be that the entity view idea covers those areas.

To me one of the big differences is one of storage. In order to get a (valid) value in this attribute can I calculate it or do I need to retrieve it from the db. This then relates to saving the entity. Will I need to save this attribute value or not.

arschr wrote:

Working with entities sees the entity as the item you work and an entity field is just that: the field of an entity.

Working with the fields/attributes, for example in lists, opens up possibilities like aggregates/groupby and expressions which are out of place in the world of the entity.

I'm not sure the two ideas can't be reconciled. Entities could have both integral attributes and calculated attributes. Calculated attributes could be aggregates (total order amount) or group by collections of (possibly derived) child entity views ( say order information with multiple attributes summarized by sales man). It may be that the entity view idea covers those areas.

The plan is to add expression fields to an entity in the designer. These expressions then can be db expressions or code expressions (evaluated with the data read from the db).

It will be a struggle though to expose this in an intuitive manner, but we'll see

I wish you luck.