From: Alex B. <en...@tu...> - 2001-08-15 20:07:39
|
hi all, this is a large xml file, sorry... but this is a near-final entity definition format for r2. have a read, let's discuss this and get it final :) best, _alex -------------------------------- <entity> <!-- the name of the entity --> <name>furbees</name> <!-- db-related stuff for compatibility with metabase. this allows for auto-generation of metabase schema files from entity definitions --> <database> <!-- the db name to use when creating tables or databases --> <name>binarycloud_db</name> <!-- create the database? --> <create>0</create> <!-- the table this entity references --> <table> <!-- table name --> <name>furbee</name> <!-- an index declaration for the primary key --> <index> <name>furbee_id</name> <unique>1</unique> <field> <name>furbee_id</name> </field> </index> </table> <!-- a database sequence for the primary key --> <sequence> <name>furbee_id</name> <start>1</start> <on> <table>furbee</table> <field>furbee_id</field> </on> </sequence> </database> <!-- field definitions are the 'heart' of an entity these definitions carry all of the information necessary to create schemas, do validation, and label fields in html. --> <fields> <field> <!-- the field name --> <name>furbee_id</name> <!-- the field label, or "full name" --> <label>Furbee ID</label> <!-- the description of the field --> <desc>Unique ID for ever Furbee</desc> <!-- the path in the entity --> <path>furbee_id</path> <!-- must this field be valid to do a post of this entity? --> <required>true</required> <type> <!-- is this the default field in the db table? --> <default>0</default> <!-- can the field be null? --> <notnull>1</notnull> <!-- what is the simple, 'database' type of this field? --> <dbtype>text</dbtype> <!-- what is the complex 'application' type of this field? --> <type>text</type> <!-- if you don't understand the difference between dbtype and type, an email address is put in a text field in a db, but must be validates as an email address. --> <!-- the maximum number of chars allowed in input fields and posts --> <maxlength>20</maxlength> <!-- a regex pattern which will be run against input --> <format>/[\s\w_\-\.]{1,20}/</format> <!-- note that type declarations will carry some regex from the system by default, for example we will have an "email" type which automatically does validation for you. --> </type> </field> <field> <name>furbee_type_id</name> <label>Furbee type ID</label> <desc>The id of the type of furbee</desc> <path>furbee_type_id</path> <required>true</required> <type> <dbtype>int</dbtype> <!-- note the "pointer" type this field is a pointer to another entity, and a foreign key in the database --> <type>pointer</type> <!-- form above, the entity name to use for requesting data from this pointer --> <entity>furbee_type</entity> <maxlength>20</maxlength> <format>/[\w\s_\-\.]{0,20}/</format> </type> </field> </fields> <!-- this should only be required to map old schemas to entities - under normal circumstances the fields should match names the entsource field is the path to the entity field, the dbtarget is the path to the database field. --> <schema> <map> <entsource>furbee_type_id</entsource> <dbtarget>furbee.furbeetypeid</dbtarget> </map> </schema> </entity> |
From: Jason H. <jc...@ey...> - 2001-08-15 21:30:35
|
the entity declaration makes good sense to me, though i have a few questions and concerns. 1. within <field>, your example showed TEXT and POINTER. could we get a list of these 'application' types w/ descriptions? 2. i noticed <maxlength> which i can forsee being used for setting a maxlength in a input field (HTML), and for possibly determining the field length in the database. (is this correct?) BUT, there was no LENGTH value anywhere. if HTML forms are to be built on the entities, having a MAXLENGTH as well as a LENGTH would be desired. 3. could you explain a field PATH a bit? .. beautiful sh*t you have going on here. =] jason |
From: Alex B. <en...@tu...> - 2001-08-15 22:54:15
|
> the entity declaration makes good sense to me, though i have a few > questions and concerns. > > 1. within <field>, your example showed TEXT and POINTER. could we get a > list of these 'application' types w/ descriptions? don't exist yet. I imagine email, text, dna_sequence, phone_number, date, etc. It would be extensible with user 'types' - we'll have a set of default ones that come with the system. They'd be simple classes that do validation. > 2. i noticed <maxlength> which i can forsee being used for setting a > maxlength in a input field (HTML), and for possibly determining the > field length in the database. (is this correct?) BUT, there was no Correct on both accounts. > LENGTH value anywhere. if HTML forms are to be built on the entities, > having a MAXLENGTH as well as a LENGTH would be desired. Yes, I see your point. I was toying with the idea of associating UI controls with each field type. That may still happen, so: <field> <name>furbee_type_id</name> <label>Furbee type ID</label> <desc>The id of the type of furbee</desc> <path>furbee_type_id</path> <required>true</required> <type> <dbtype>int</dbtype> <!-- note the "pointer" type this field is a pointer to another entity, and a foreign key in the database --> <type>pointer</type> <!-- form above, the entity name to use for requesting data from this pointer --> <entity>furbee_type</entity> <maxlength>20</maxlength> <format>/[\w\s_\-\.]{0,20}/</format> </type> <!-- look here --> <uicontrol> <name>TextField</name> <params> <length>20</length> </params> </uicontrol> </field> > 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. the idea is to be able to ask FormBuilder to make you a form for an entire entity, or just a set of fields in that entity by passing in entity paths. > .. beautiful sh*t you have going on here. =] thanks :) This isn't all mine, I was on the right track but odysseas, john donagher, and john campbell are the masterminds behind the original entitymanager. I'm making tweaks to some of the design so it's less application specific, and more "metabase integrated" if that makes sense. :) _alex > jason |
From: Andreas A. <a.a...@th...> - 2001-08-16 09:50:32
|
Hi Alex, > > 2. i noticed <maxlength> which i can forsee being used for setting a > > maxlength in a input field (HTML), and for possibly determining the > > field length in the database. (is this correct?) BUT, there was no > > Correct on both accounts. > > > LENGTH value anywhere. if HTML forms are to be built on the entities, > > having a MAXLENGTH as well as a LENGTH would be desired. > > Yes, I see your point. I was toying with the idea of associating > UI controls with each field type. That may still happen, so: > <!-- look here --> > <uicontrol> > <name>TextField</name> > <params> > <length>20</length> > </params> > </uicontrol> > </field> 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. 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. > > 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> Andi |
From: Jason H. <jc...@ey...> - 2001-08-16 15:36:10
|
-- Quoting the R2 draft spec -- Default ui controls are assigned to each entity based on its type declaration, which means the system is capable of generating default forms. To facilitate such a great feature, it would be required to define these markup values in the entity definition. I would like to see the defaults defined here, as you mentioned, but tolerant for overriding values in the templates. jason Andreas Aderhold wrote: > > > 2. i noticed <maxlength> which i can forsee being used for setting a > > > maxlength in a input field (HTML), and for possibly determining the > > > field length in the database. (is this correct?) BUT, there was no > > > > Correct on both accounts. > > > > > LENGTH value anywhere. if HTML forms are to be built on the entities, > > > having a MAXLENGTH as well as a LENGTH would be desired. > > > > Yes, I see your point. I was toying with the idea of associating > > UI controls with each field type. That may still happen, so: > > <!-- look here --> > > <uicontrol> > > <name>TextField</name> > > <params> > > <length>20</length> > > </params> > > </uicontrol> > > </field> > 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. > 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. |
From: Alex B. <en...@tu...> - 2001-08-16 17:01:37
|
> -- Quoting the R2 draft spec -- > Default ui controls are assigned to each entity based on its type > declaration, which means the system is capable of generating default > forms. Oh, really! Heh, apparently I have already thought of this! :) > To facilitate such a great feature, it would be required to define these > markup values in the entity definition. I would like to see the > defaults defined here, as you mentioned, but tolerant for overriding > values in the templates. Which is exactly what I had envisioned. I don't view it as a 'breach of style' to have UI components associated with fields in an entity definition. Imagine defining a set of xml files, and being able to basically say "ok, make me a set of database tables and default modules + pages" and _bing_ a default site is built for you, which you can take and customize to fit the application. > jason > > > Andreas Aderhold wrote: >>>> 2. i noticed <maxlength> which i can forsee being used for setting a >>>> maxlength in a input field (HTML), and for possibly determining the >>>> field length in the database. (is this correct?) BUT, there was no >>> >>> Correct on both accounts. >>> >>>> LENGTH value anywhere. if HTML forms are to be built on the entities, >>>> having a MAXLENGTH as well as a LENGTH would be desired. >>> >>> Yes, I see your point. I was toying with the idea of associating >>> UI controls with each field type. That may still happen, so: >>> <!-- look here --> >>> <uicontrol> >>> <name>TextField</name> >>> <params> >>> <length>20</length> >>> </params> >>> </uicontrol> >>> </field> >> 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. >> 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. > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
From: Alex B. <en...@tu...> - 2001-08-16 16:59:21
|
> 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 |
From: Andreas A. <a.a...@th...> - 2001-08-17 09:01:11
|
Hi, > If the entity carried what UI components it should use, there would be no > "extra" information needed. I see your point. > 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. Ok, that's nice. > I can see use in having separate "settings" for the database and the app. Jepp. I think this is neccessary. Another question. Can a entity span say parts of one or more tables? Something similar like a view in SQL? In the example the complete db entitys are mapped in the definition. And so querys are genearated for all fields. But that might me overhead. So I would like to define a entity that spans parts of tables. E.g. If I have a enty defined called "Subscriptions" that span the tables.fields: user.userId user.login smssubscriptions.userId smssubscritpions.serviceId emailsubscriptions.userId emailsubscriptions.serviceId but the tbl user has more fields I do not need to query for this entity. But for this one it's just fine. Andi |
From: Alex B. <en...@tu...> - 2001-08-17 18:51:44
|
>> I can see use in having separate "settings" for the database and the app. > Jepp. I think this is neccessary. > > Another question. Can a entity span say parts of one or more tables? > Something similar like a view in SQL? "Sort of" you can embed entity references (called pointers) in entity definitions. so you can say: user_id user_name user_password address_id -> address i.e. "get the address entity with this id" > In the example the complete db entitys are mapped in the definition. And so > querys are genearated for all fields. But that might me overhead. So I would > like to define a entity that spans parts of tables. > > E.g. If I have a enty defined called "Subscriptions" that span the > tables.fields: > > user.userId > user.login > smssubscriptions.userId > smssubscritpions.serviceId > emailsubscriptions.userId > emailsubscriptions.serviceId > > but the tbl user has more fields I do not need to query for this entity. But > for this one it's just fine. I don't see why not. I don't _think_ entityManager supprts that currently but I have no problem with the idea as long as its implemented properly :) ------------ Actually, along these lines: does anyone have any qualms about making this assumption?: -Entity Field names must correspond exactly to table field names (we could get rid of the schema map if we did this) It would simplify a lot of the code, I think. _a |
From: John D. <jo...@we...> - 2001-08-18 05:50:10
|
On Fri, 17 Aug 2001, Alex Black wrote: > >> I can see use in having separate "settings" for the database and the app. > > Jepp. I think this is neccessary. > > > > Another question. Can a entity span say parts of one or more tables? > > Something similar like a view in SQL? > > "Sort of" > > you can embed entity references (called pointers) in entity definitions. > > so you can say: > > user_id > user_name > user_password > address_id -> address > > i.e. "get the address entity with this id" > Yep. > > In the example the complete db entitys are mapped in the definition. And so > > querys are genearated for all fields. But that might me overhead. So I would > > like to define a entity that spans parts of tables. > > > > E.g. If I have a enty defined called "Subscriptions" that span the > > tables.fields: > > > > user.userId > > user.login > > smssubscriptions.userId > > smssubscritpions.serviceId > > emailsubscriptions.userId > > emailsubscriptions.serviceId > > > > but the tbl user has more fields I do not need to query for this entity. But > > for this one it's just fine. > > I don't see why not. I don't _think_ entityManager supprts that currently > but I have no problem with the idea as long as its implemented properly :) > It does support that; you have to specify the joins in a hierarchical array structure in the entity definition (that syntax could use some rethinking before we release as it was imported from an earlier abstraction layer). I can supply an example entity definition if there is interest. > ------------ > > Actually, along these lines: does anyone have any qualms about making this > assumption?: > > -Entity Field names must correspond exactly to table field names (we > could get rid of the schema map if we did this) > The schema structure is optional; if it's not present, we use the object structure, which is single-dimensional, instead. Odysseas or John C. will probably have better rationale for this than I do, but at least one example of where the schema mapping comes in useful is in building a generic public data access structure which could be used to automatically generate, for example, dtd's for XML access to these objects. Having a degree of independance between your data access structure's element names and your database field names could prove useful for cases like this. HTH -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD |
From: Andreas A. <a.a...@th...> - 2001-08-19 15:31:10
|
Hi, > > > Another question. Can a entity span say parts of one or more tables? > > > Something similar like a view in SQL? > > "Sort of" > > you can embed entity references (called pointers) in entity definitions. > > > > so you can say: > > > > user_id > > user_name > > user_password > > address_id -> address > > > > i.e. "get the address entity with this id" > Yep. OK, will that work for the 4NF ? i.e. "get all interest names for user with this id" user_id user_interests -> userinterests userinterests: user_id interest_id-> interests interests: interest_id interest_desc [entities that span tables/part of tables] > It does support that; you have to specify the joins in a > hierarchical array structure in the entity definition (that syntax could > use some rethinking > before we release as it was imported from an earlier abstraction > layer). I can supply an example entity definition if there is interest. Oh yes, please. Andi |
From: John D. <jo...@we...> - 2001-08-19 17:50:33
|
On Sun, 19 Aug 2001, Andreas Aderhold wrote: > > OK, will that work for the 4NF ? > > i.e. "get all interest names for user with this id" > > user_id > user_interests -> userinterests > > userinterests: > user_id > interest_id-> interests > > interests: > interest_id > interest_desc > I believe so, although I've never actually done it, so maybe John C. or Odysseas can answer this one. > [entities that span tables/part of tables] > > It does support that; you have to specify the joins in a > > hierarchical array structure in the entity definition (that syntax could > > use some rethinking > > before we release as it was imported from an earlier abstraction > > layer). I can supply an example entity definition if there is interest. > > Oh yes, please. > On its way -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD |
From: John P. C. <jp...@jp...> - 2001-08-19 21:46:06
|
On Sun, Aug 19, 2001 at 01:49:25PM -0400, John Donagher wrote: > On Sun, 19 Aug 2001, Andreas Aderhold wrote: > > > OK, will that work for the 4NF ? > > i.e. "get all interest names for user with this id" > > > > user_id > > user_interests -> userinterests > > > > userinterests: > > user_id > > interest_id-> interests > > > > interests: > > interest_id > > interest_desc > > This seems like an example of a multi-lined "owned object". I didn't go back and read the original mail, so I hope this is useful. There would be 3 entities: user, userinterest, interest. The owned object would be "userinterest", with a parententity of user. In the parent entity, you define how a parent relates to it's "owned objects" like this: 'ownedobjects' => array ( 'fkey' => 'PATH1', // from userinterest 'invfkey' => 'PATH2', // from user 'entity' => 'userinterest', // the ownedobject entity 'path' => 'USERINTERESTS', // how to reference from the parent object ) and in the owned object entity: 'parententity' => 'user' Once all the meta data work is done, then all the linking of user and userinterests will be done automatically (thanks to ent2qry). There will also be a ready made multiline UI for choosing interests to associate with this user (assuming the user layout file is correct). More concrete examples can be given as needed. HTH, jpc |
From: Andreas A. <a.a...@th...> - 2001-08-20 22:27:44
|
Hi John, > This seems like an example of a multi-lined "owned object". I > didn't go back and read the original mail, so I hope this is useful. > There would be 3 entities: user, userinterest, interest. Jepp, exactly. > The owned object would be "userinterest", with a parententity of user. > In the parent entity, you > define how a parent relates to it's "owned objects" like this: > > 'ownedobjects' => array ( > 'fkey' => 'PATH1', // from userinterest > 'invfkey' => 'PATH2', // from user > 'entity' => 'userinterest', // the ownedobject entity > 'path' => 'USERINTERESTS', // how to reference > from the parent object > ) Cool. > Once all the meta data work is done, then all the linking of user and > userinterests will be done automatically (thanks to ent2qry). There will > also be a ready made multiline UI for choosing interests to > associate with this user (assuming the user layout file is correct). Absolutely fantastic. Andi |
From: Alex B. <en...@tu...> - 2001-08-20 19:33:34
|
>> I don't see why not. I don't _think_ entityManager supprts that currently >> but I have no problem with the idea as long as its implemented properly :) >> > > It does support that; you have to specify the joins in a hierarchical array > structure in the entity definition (that syntax could use some rethinking > before we release as it was imported from an earlier abstraction layer). I can > supply an example entity definition if there is interest. That would be great. >> Actually, along these lines: does anyone have any qualms about making this >> assumption?: >> >> -Entity Field names must correspond exactly to table field names (we >> could get rid of the schema map if we did this) >> > > The schema structure is optional; if it's not present, we use the object > structure, which is single-dimensional, instead. Odysseas or John C. will > probably have better rationale for this than I do, but at least one example of > where the schema mapping comes in useful is in building a generic public data > access structure which could be used to automatically generate, for example, > dtd's for XML access to these objects. Having a degree of independance between > your data access structure's element names and your database field names could > prove useful for cases like this. Agreed. _a |
From: John P. C. <jp...@jp...> - 2001-08-18 09:44:44
|
> Actually, along these lines: does anyone have any qualms about making this > assumption?: > > -Entity Field names must correspond exactly to table field names (we > could get rid of the schema map if we did this) The only problem with this is that the schema fields are the "exposed" fields. A name like userreckey is a reasonable db field name, but isn't a great exposed field name. Also I may have two fields that map to a single db field. I may have, for example, ZIPCODE and ZIPCODE_EXTENDED that end up being concatenated and stored in the db. Or in the case I gave earlier with entities mapping to multiple records in the same table. I may have USERPREF1 and USERPREF2 that get translated to two records in the preference table by ModuleSetupManager. There's more, but I think that gets the point across. jpc |
From: John P. C. <jp...@jp...> - 2001-08-18 09:44:43
|
> Another question. Can a entity span say parts of one or more tables? Yes, it can span 0 or more tables. They have many uses. Some are by design and others were just discovered. > Something similar like a view in SQL? Yes. > In the example the complete db entitys are mapped in the definition. And so > querys are genearated for all fields. But that might me overhead. So I would > like to define a entity that spans parts of tables. Your queries should be generated only for those fields in your 'object' section of the entity and in the dbschema.inc file. > E.g. If I have a enty defined called "Subscriptions" that span the > tables.fields: > > user.userId > user.login > smssubscriptions.userId > smssubscritpions.serviceId > emailsubscriptions.userId > emailsubscriptions.serviceId > > but the tbl user has more fields I do not need to query for this entity. But > for this one it's just fine. This is fine. I use the entities for single tables, combinations of tables (e.g. contact with associated mailaddress), and multiple records of the same table. The latter can be done, for example, in the case of preferences. Each "field" in the entity may map to an entire record in a preference table. The possibilities aren't endless, but sometimes it seems that way. :-) jpc |