Re: [binarycloud-dev] entity definition format

[Alex B. <en...@tu...>]

> Hmm. But isn't that markup stuff something for the template engine/up to the
> designer? I'm not quite sure if integrating the UI stuff with the entities
> is wise or not.

It would never be a requirement. The reason it could be useful, is you could
pass an entity name into a default module, and get a complete form out (the
module would use entitytmanager to get data, and pass that data to the
editor) or list, etc.

If the entity carried what UI components it should use, there would be no
"extra" information needed.

You can make some basic assertations about a field, i.e. "this is usually
going to be a textbox that's 20 chars long." if you don't explicitly define
that 'format' then the default is assumed and you can continue about your
business.

Editor also makes pretty good "guesses" about what UI components to use if
they aren't defined.

> Imagine you use the size/length attribute of an input field within more
> contextes. So you have a from_a with size="20" is fine, in form_b using the
> same entitiy size="20" does not fit, you need size="40" in form_c you need
> style="width: 80px" and the so on...
> Ok, maybe you can override this in the template and the etydef values are
> defaults or whatever. Anyway, I think markup stuff does not belong here.

a) there isn't markup there
b) yes, that part is "overridable"

>>> 3. could you explain a field PATH a bit?
>> path is sort of like the way you ref a table.field_name in sql:
>> location.locationid is an entity path that points to a field in an entity.
>> it could also be a sql table_name.field_name path - it's intentionally
>> similar.
> Extremely nice.
> 
> <required>
> Antoher question. Does the <required /> tag mean "not null" in the database
> only or with the form? I think this should not be combined, caus there are
> applications you have the db-field defined "not null" (requried) but no
> input value coming from the ui whatever, not required or not present.
> </required>

Usually, yes. Not always.

For example, you may want to have a entity posts always contain data, but
some other source is posting data that has fields missing. I can see use in
having separate "settings" for the database and the app.

best,

_alex