Is it possible to have a value in a transfer object applied even if it's not declared in the DataSource?

[mathias]

Here's my usecase:

I create a user. it has ds fields like first name, last name etc.

I have an additional field called "password send method". This is not part of the user itself, but part of the add operation. i have it as a popup parameter when the user presses save - "How do you want to send the password"


- So, i'm trying to, when i call form.save to add an additional field, which i do like 'form.setValue("passwordSendMethod", "BANANA");'


On the server, i have a spring bean method, add(UserTO user). The TO is just a javabean, and it has the passwordSendMethod.

---

Now, i can see that the passwordSendMethod appears on the server, it becomes a field in both the "values" and "clientSuppliedValues" maps of the dsRequest. However, it does not get set in the UserTO, probably because it's not one of the fields in the user.ds.xml?

I tried debugging a bit and in DataTools, a property seems to be not inserted into the "tryAsBean" map if the field is not in the datasource?

So, pretty basic question:

Is there for me to have a submitted property value added to my transferobject automatically even if it's not declared in the ds.xml?

I am doing this for 2 reasons:

1. is don't want the field in the ds.xml if i can avoid it since it's not really a part of the user.
2. i would still like it to be added to the transfer object, since then i don't have to declare the datasource and/or the values map as a method parameter and do manual digging out of the parameter.

Pointers appreciated

[Isomorphic]

You do indeed want a field declaration for this. Fields do not imply permanent storage: they are used for calculated values, criteria that are not specific to a field, etc.

When you think of the possibility of non-String additional parameter (a number or date for example) then it becomes more obvious why you would need a field declaration for something that isn't part of permanent storage: to convey type information, validators, etc.

[mathias]

OK, but to me, it kind of doesn't make sense. Let me take another, fictional, example.

Say that when creating a user, the admin doing it has a field for what truck the person having an account created happens to be driving that day, so that an automated phonecall can go out to that specific car with one-time information about the new account.

That field is in no way related to the user being created, it does not belong to the user at all.

But if i put a field in the datasource, it's always there, in *every* situation somebody, any developer for example, has to deal with the concept of the user datasource, not to mention that the field is visible everywhere. There will be questions about the field is for, it is included as a field in traffic between the client and server all the time, for no good reason, etc.

To me, that'd not desirable.

In that case, i'd rather resort to having the Map parameter in the create method signature, and fetch the parameter out manually at that specific operation. It's ugly, and i will cry every time i see it, but at least it is only in one place then. Too bad.

[Isomorphic]

Remember, a DataSource is the definition of an entity and the operations on it. This field most definitely falls into the category of the operations on the user entity, since the UI submits it and the server does something with it.

As far as the consequences of the declaring the field, none of what you describe is actually true. You simply mark such a field as hidden by default, and it never appears in any component that uses the DataSource (unless declared in that component) and never appears in network traffic unless explicitly used. So none of the consequences you are concerned with actually exist.

[mathias]

Not sure what you mean "explicitly used". In my spring mvc beans, i return a java bean that corresponds to the ds.xml. If i include the field in the ds xml, it is always included as a field in the response over the network always, whether the variable is set or not. I would have preferred it to not be included over the wire if not used/set - In the jackson lbrary you can do this via annotations - @JsonInclude(JsonInclude.Include.NON_EMPTY). Is there something similar here? (i have required set to false in the xml).

[Isomorphic]

The previously described use case, in your words, was "I have an additional field called "password send method". This is not part of the user itself, but part of the add operation".

This describes a one-time parameter which is presumably not stored and not part of the bean, and for that use case we have accurately described that no unnecessary data would be sent with the recommended approach of adding a field for this one-time parameter.

You have now shifted to a different use case of a field you don't want to send to the client in most circumstances - this is also very simple to solve, by just setting the operationBinding.outputs of the default fetch. Then, the data will not be sent unless you use a special operationBinding with a different setting for outputs.

[mathias]

ok, i'll look into that.