Hello

I wonder why: Fields on related fields could only be 1 level depth ?

Give us example of what you are trying to do, and we will try to help you with the best options.

I wonder why: Fields on related fields could only be 1 level depth ?

It would be nice if you could go deeper using the designer, but you can't. You can achieve the same effect by adding custom code to the generated entities. Unfortunately then the project doesn't know about them.

please give an example where the** semantic** meaning of a field of a related entity Y 4 hops away over 1:1 / m:1 relations (solely these relations!) is of any value to an entity X. You can always navigate yourself to these entities, so its just about having a bindable list. With 1 hop away (as is supported) I can understand, but more... I can't come up with a use case for that.

1 - Example (soso) A model you could have 3 entity like that:

Company (M:1 with) Telephone (M:1 with) TelephoneType (home-cell-work-fax).

Note: In my case the company has only one phone this is why the M:1 relation. I also re-use phone entity for person.

It would be nice to have the telephone type into the company.

2 - Be sure it have it's value... last sample (better)

The sample is base on a soccer (football) entity model:

MatchGoal (M:1 with) Player (M:1 with) Position

You want to have the player name and it's position in each entity of the MatchGoal.

3 - I happen often were you split the same object in 2 for clarity and one of the 2 has value that come from a "value table".

I have a customer, which has Billing Accounts, each month a billing account has an invoice. As I process the invoices I find problems things that were billed incorrectly, these are stored as disputes. Along with customer a Billing Account belongs to a vendor.

customer -> Billing Account -> Invoice -> Dispute 
                     ^
vendor -------|

When I display disputes I want to show the customer name, the vendor name, the Billing Account Type, the invoice date, etc.

I could live without it if you fix the typed list problem. The typed list problem is really important to me and to anybody who have to use the LLBLGenProDataSource.

I could live without it if you fix the typed list problem. The typed list problem is really important to me and to anybody who have to use the LLBLGenProDataSource.

For sure the answer for these cases is a TypedList. And the TyoedList is working perfectly with me. I'll close this thread, so we can proceed on the TypedList thread.

For sure the answer for these cases is a TypedList.

In my opinion it's not for sure it's typed lists in many cases.

When working with entities, the answer is to modify the entity to add the distant fields and have the getter return the value via related entities. This however isn't as good as allowing (at least) the field itself to be defined in the designer, since the knowledge of these fields isn't stored in the project they aren't available for code generation purposes. But for my purposes you can treat this as a feature request which has already been requested.

So it would be great if there was a way to formulate a list kind of thing in-code from fields in a graph of entities (which is actually a projection) WITHOUT actually projecting the data, so altering the values in the list is reflected in the graph?

the downside of having the fields mapped into the entity is that it is a nightmare due to the eventhandlers, and also it doesn't always make sense for the entity (which is very important!). So for a view, or LIST of fields (e.g typed list but then in code) it makes sense, but not for an entity to have these fields all in one place.

So it would be great if there was a way to formulate a list kind of thing in-code from fields in a graph of entities (which is actually a projection) WITHOUT actually projecting the data, so altering the values in the list is reflected in the graph?

Yes, but better than doing it in code would be to create the list of fields in the designer (so the are stored in the project) and then if it can't be described in the designer, the binding (setting events, etc) to the distant values could be done in code.

it doesn't always make sense for the entity (which is very important!). So for a view, or LIST of fields (e.g typed list but then in code) it makes sense, but not for an entity to have these fields all in one place.

I'm not sure I'm understanding you completely. I think I remember, you like to see entities as relating very closely (1 to 1) to tables in the db? I see these virtual fields as viewports the entity provides to other information, it could be a value of a field on a remote entity or the sum of a set of values from remote child collections (for example open order count and total open order amount displayed on a customer entity, even though that detail is several levels away). I don't think it is important that they be updateable in the hosting entity and while it would be nice if the things that make them up would notify the host when they changed, it would be a step forward if the host had to poll them for their current values.

I think the critical thing is to give a way to define the place holder in the entity designer. The developer can take responsibility for providing the value.

arschr wrote:

So it would be great if there was a way to formulate a list kind of thing in-code from fields in a graph of entities (which is actually a projection) WITHOUT actually projecting the data, so altering the values in the list is reflected in the graph?

Yes, but better than doing it in code would be to create the list of fields in the designer (so the are stored in the project) and then if it can't be described in the designer, the binding (setting events, etc) to the distant values could be done in code.

I don't think that will ever happen. See below.

it doesn't always make sense for the entity (which is very important!). So for a view, or LIST of fields (e.g typed list but then in code) it makes sense, but not for an entity to have these fields all in one place.

I'm not sure I'm understanding you completely. I think I remember, you like to see entities as relating very closely (1 to 1) to tables in the db?

No an entity is a group of attributes forming the abstract definition of an entity. So in theory, you can do: Select o.orderid, c.companyname from orders o join customers c on ...

and you'll have a new entity: o.orderid & c.companyname.

The thing is though, that this projection is 1-way. And we already have that: either a typedlist (designer) or a dynamic list (code) and even with projections from a datareader.

So if you want it 2-way, you can't use this, as you then need a reverse projection back: what if value X changes.. etc. The entity above: can you save these when I change the companyname? Probably not, as there's no customerid and no values for non-null fields.

I see these virtual fields as viewports the entity provides to other information, it could be a value of a field on a remote entity or the sum of a set of values from remote child collections (for example open order count and total open order amount displayed on a customer entity, even though that detail is several levels away). I don't think it is important that they be updateable in the hosting entity and while it would be nice if the things that make them up would notify the host when they changed, it would be a step forward if the host had to poll them for their current values.

I think the critical thing is to give a way to define the place holder in the entity designer. The developer can take responsibility for providing the value.

One thing you have to know: there's a big difference between what's necessary for the entity to be an entity with valid data and what's necessary to paint a list of values on a screen.

What you describe above is a typedlist. The fields mapped on related fields are actually pretty much there for databinding purposes as they're simply allowing you to show a list with fields from other entities in that same list.

My proposal above is a component where you in code define the fields from a graph (including relations how to navigate) and eventually expressions, which make up the columns of the list, and then you put in a graph and the list materializes as a view over the graph.

The fancy thing is: it IS updateable, as the fields in the list are ports to the fields in the entities, perhaps deep inside the graph.

It's a way to create a new 'entity' by defining a projection which is updatable as it's not really a projection (as the object representing the list has the ability to pass data back and forth to fields). Putting all these fields inside a real entity in the designer is IMHO pretty much not what you want, as they are NOT part of that entity. I already find the fields mapped onto related fields pretty much not that great, but it's an easy way to make databinding work easier. however, if that would be possible for a myriad of fields from the graph the entity is part of, event nightmares are bigger than you and I can imagine and I definitely won't go there: a pattern like MVC has taught the world that it is much better for that purpose and my proposal is actually a different viewer on top of the same model (graph)