ComboBox based on a join of two entities

ComboBox based on a join of two entities

  
Hi,

I have two entities:
  • User, with people's names
  • Employee, being, of course, related to User
I need to to have a ComboBox that displays names from User but returns identifiers from Employee. As for now the intuitive solution (a Join as the source) seems to be not allowed. I know that I can create my own Structure, fill it reading from my Join, then supply it in ComboBox as the source. It is acceptable once or twice but not as a standard solution.

Is there some other solution or are there plans to improve this?

Regards
Tomasz
Tomasz,

Encapsulate that query in a function and invoke it directly in the "Source" property of the dropdowns you need. This will save you the hassle of building that join on every place you'll need it.

Cheers,
Hermínio
The question here is: why is the solution of joining the necessary entities in an output structure composed of Identifier and Description to use in the ComboBox only acceptable once or twice?

Is it because you need multiple times the same query in the application? As Hermínio mentioned, you can encapsulate the query to be reusable 

Or is it a different reason for why it's not acceptable?

Best regards,
PC
Hi,
This is not acceptable because it forces me to create unneccessary structures (and unneccessary actions). They are created only because of some shortcoming of the software platform.

This is not only the problem of joins. Let's suppose that the User entity contains not Name but FirstName and LastName. In this case I want to show the combination of two columns - and still can't because the combination doesn't belong to the core User entity.

Regards
Tomasz
First of all, the platform is here to make your life easier, but there are limitations for what it can do.

What would be the good value for the number of entities allowed to be used in the ComboBox? 2? 3? 20?

And how do you want to join them? With a "-", a "/", a " ", enclose in brackets? Should the platform allow all of this? How does it guess which one you want?

To be honest, I believe this is a lazy request...

A combo has a value that is shown and an identifier, it's simple you can put whatever you want in it as long it comes from a structured data format (entity, structure, static entity)

What is wrong with creating a simple structure like:


And then reuse it when you have the need?

Bes regards,
PC
Hi,
comboBox needs only 2 source attributes: one for displaying, one for being the widget's value. The source aggregate may consist of as many entities as required - it doesn't matter.

Look at "Table Records" widget. It also uses the output of an aggregation but accepts columns from various entities. This is exactly the same case (at least from the programmer's point of view).

It is nothing wrong in creating such a simple structure. It is something wrong when I must create many simple structures of this type - they are many because Identifier is strongly typed, at least as far as I know.

Regards
Tomasz
Table Records and ComboBox aren't really comparable, most of the time you are using other widgets inside the table records in order to achieve that result you are trying to compare.

And you don't have to create many structures, you can simple create one with the Identifier as Text and do the appropriated conversions when required

Best regards,
PC

Hi,
OK, the Table Records was not a good example.  But any other widgets  - Label, Text Box etc. - can be bound to any data from Aggregates. Any - excluding Combo Box.

Let's stop this discussion. You have your opinion, I have mine. The issue is not a blocker, it's rather a kind of inconvenience. If you ever changed your mind and improved CombBox in this respect - it would be appreciated :-)

Regards
Tomasz
I agree with Tomasz, it would be nice to be able to specify attributes from more than just a single entity. Also, Pedro, with regards to your remark about how to display, it'd be ideal if you could actually specify an expression to show in the list, instead of just a single attribute. Since the platform has to iterate the list anyway, this would be rather easy to do.
Hermínio Mira wrote:
Tomasz,

Encapsulate that query in a function and invoke it directly in the "Source" property of the dropdowns you need. This will save you the hassle of building that join on every place you'll need it.

Cheers,
Hermínio
 
 Hi Hrminio,

I like what you are suggesting. However I cannot select the function on the ComboBox. 
What am I missing?

Regards,
Andre