From: Alex B. <en...@tu...> - 2001-08-21 01:39:46
|
hi all, have a look at the attachment, I've made some revisions to the declaration xml for the entity. you'll notice some 'major' changes, in particular: <!-- the manager which should be imported by EntityManager. the role of an individual Entity Manager is to check the data before a post to the DB happens. It allows developers to write complex rules for an entity into a class. --> <entity:manager>FurbeesManager<entity:manager> I think that explains it: basically a class that will house complex rules (inter-field relationships) for an entity. Not necessary in most cases, so it's optional. I've changed the field definition, it's more simple now because some things have been 'moved out': <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> <!-- is this the default field in the db table? --> <default>0</default> <!-- can the field be null? --> <notnull>1</notnull> *** note that 'type' is no longer an array, but is now just the <dbtype> tag renamed. <!-- what is the simple, 'database' type of this field? --> <type>int</type> <!-- the maximum number of chars allowed in input fields and posts --> <maxlength>20</maxlength> <!-- should whitespace be trimmed from the input before it is validated and processed? --> <trim>true</trim> <!-- a regex pattern which will be run against input --> <format>/[\s\w_\-\.]{1,20}/</format> *** hopefully this is clear: processor classes will be passed field contents, and return the contents of that field after running it through some conditioning code. <!-- Processors are classes which will contidion the input somehow. In this example, the class CharEntitiesProcessor would be imported by EntityManager and passed the input for this field. It would return the input run through htmlspecialchars() or maybe a custom method for encoding xml/html character entities. --> <processors> <processor>CharEntitiesProcessor</processor> </processors> *** Validators allow devs to write complex application specific validation classes for input, and allow "us" (binarycloud core) to build a complete set of simple 'normal' validators for things like email addresses, phone numbers, dates, etc. A lot of that code exists already, of course. <!-- Validators are classes which are imported by entityManager as requested and run again input. There will be a default set of validators like EmailValidator, DNASequenceValidator, etc. These validators will be passed the input of the post in the sequence they are declared. Each validator will be run against the input, and return true or false. If false, entitymanager will return an error. --> <validators> <validator>FASTA_DNASequenceValidator</validator> <validator>NoTagsValidator</validator> </validators> <!-- This is the UI control that will be used by the FormBuilder class as a default. In this case, an <input type="text" size="20"> would result. --> <uicontrol> <name>TextField</name> <params> <size>20</size> </params> </uicontrol> </field> I'm liking this now because it has a nice set of default 'simple' validation rules (maxlength, trim, regex, etc) and plugs for validation of any complexity in the form of classes. That combined with 'processors' I think makes this as flexible as it needs to be. Now's the time for suggestions/comments/flames/rants/etc :) best, _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: John D. <jo...@we...> - 2001-08-21 01:56:18
|
On Mon, 20 Aug 2001, Alex Black wrote: > > <!-- > This is the UI control that will be used by the FormBuilder class > as a default. In this case, an <input type="text" size="20"> would > result. > --> > <uicontrol> > <name>TextField</name> > <params> > <size>20</size> > </params> > </uicontrol> > > </field> > Overall I like it a lot. Things like validation functions I would like to see optionally associated with (user-defined) types for reusability's sake. Also, I'm unclear on the above uicontrol element. You shouldn't need anything like that since it can be determined based on your field descriptions.. John -- 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: Alex B. <en...@tu...> - 2001-08-21 02:04:19
|
> On Mon, 20 Aug 2001, Alex Black wrote: > >> >> <!-- >> This is the UI control that will be used by the FormBuilder class >> as a default. In this case, an <input type="text" size="20"> would >> result. >> --> >> <uicontrol> >> <name>TextField</name> >> <params> >> <size>20</size> >> </params> >> </uicontrol> >> >> </field> >> > > Overall I like it a lot. Things like validation functions I would like to see > optionally associated with (user-defined) types for reusability's sake. Exactly: I want a set of 'default' validation classes that come with the system, but if you want to make your own, you can. >Also, > I'm unclear on the above uicontrol element. You shouldn't need anything like > that since it can be determined based on your field descriptions.. What about, for example, a password field? You're putting that in a text field in the database, and doing some simple validation on it like "can't contain tags or +8bit chars" but you aren't explicitly marking it as "password" _a |
From: John D. <jo...@we...> - 2001-08-21 02:23:05
|
On Mon, 20 Aug 2001, Alex Black wrote: > > I'm unclear on the above uicontrol element. You shouldn't need anything like > > that since it can be determined based on your field descriptions.. > > What about, for example, a password field? > You're putting that in a text field in the database, and doing some simple > validation on it like "can't contain tags or +8bit chars" but you aren't > explicitly marking it as "password" > Right .. so the way we have dealt with that thus far is you leave type set as 'text' and you have another type field (ptype) set as 'password', which means that the password control will be used as opposed to a generic text control for display/editing purposes, but internally the data is still stored as text. John -- 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: Alex B. <en...@tu...> - 2001-08-21 02:29:47
|
> On Mon, 20 Aug 2001, Alex Black wrote: > >>> I'm unclear on the above uicontrol element. You shouldn't need anything like >>> that since it can be determined based on your field descriptions.. >> >> What about, for example, a password field? >> You're putting that in a text field in the database, and doing some simple >> validation on it like "can't contain tags or +8bit chars" but you aren't >> explicitly marking it as "password" >> > > Right .. so the way we have dealt with that thus far is you leave type set as > 'text' and you have another type field (ptype) set as 'password', which means > that the password control will be used as opposed to a generic text control > for > display/editing purposes, but internally the data is still stored as text. Is there any other place that ptype is used? I like having the control definition in there, I think it's nice and convenient (and it gives you iron fisted control over default presentation) _a |
From: John D. <jo...@we...> - 2001-08-21 03:24:44
|
On Mon, 20 Aug 2001, Alex Black wrote: > > Is there any other place that ptype is used? > I don't think so. > I like having the control definition in there, I think it's nice and > convenient (and it gives you iron fisted control over default presentation) > The entity definition really has nothing to do with presentation. I think even the ptype is in the wrong place. These things are all meaningless to an XML client, for example. Also, having a control definition inline like that means it cannot be reused. I think that's evil :) John -- 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: alex b. <en...@tu...> - 2001-08-21 07:50:04
|
> > > I like having the control definition in there, I think it's nice and > > convenient (and it gives you iron fisted control over default presentation) > > > > The entity definition really has nothing to do with presentation. I think even > the ptype is in the wrong place. These things are all meaningless to an XML > client, for example. Also, having a control definition inline like that means > it cannot be reused. I think that's evil :) How would you do it? Assume the following: -You want a default ui control assigned to each entity field -you want to be able to assign them easily where :)? _a |
From: John D. <jo...@we...> - 2001-08-21 08:32:30
|
I think it makes most sense in the lister/editor definition for that entity. These are presentation-oriented, whereas the entity definition was never really meant to be. I'm not quite sure what you mean by default, every field has only one control associated with it, which is determined based on the type. I could see associating user-defined controls with user-defined types, or assigning a custom control to a certain field. But in general it seems like type controls aren't something people will have to do anything for when writing their editor, only overriding with their custom field controls if necessary. My $.02 John On Tue, 21 Aug 2001, alex black wrote: > > > > > I like having the control definition in there, I think it's nice and > > > convenient (and it gives you iron fisted control over default > presentation) > > > > > > > The entity definition really has nothing to do with presentation. I think > even > > the ptype is in the wrong place. These things are all meaningless to an > XML > > client, for example. Also, having a control definition inline like that > means > > it cannot be reused. I think that's evil :) > > How would you do it? > Assume the following: > -You want a default ui control assigned to each entity field > -you want to be able to assign them easily > > where :)? > > _a > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > > -- 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: alex b. <en...@tu...> - 2001-08-21 16:32:27
|
> I think it makes most sense in the lister/editor definition for that entity. > These are presentation-oriented, whereas the entity definition was never really > meant to be. I agree here, but I was thinking along the lines of establishing defaults, so theoretically you could just ask the editor to build you a form for a particular entity, and not have to do anything else. Of course if you _wanted_ to, you could do all kinds of fancy things like custom layouts, special ui controls, etc etc. > I'm not quite sure what you mean by default, every field has only one control > associated with it, which is determined based on the type. I could see Ok, but how do you assign a textarea to a text field? (as opposed to just a text box) - from maxlength? What if you want to have an 'address' field be a textarea instead of an input field, but it still only accepts < 255 chars? > associating user-defined controls with user-defined types, or assigning a > custom control to a certain field. But in general it seems like type controls > aren't something people will have to do anything for when writing their editor, > only overriding with their custom field controls if necessary. I agree with that - I want to establish defaults which can be overridden, but that most people will have no interest in changing... I think the issue here is, do we need to explicitly declare those defaults (I don't mind doing that, I think it's clean because it's just more metadata that you can use or discard as you see fit). _a > My $.02 > > John > > On Tue, 21 Aug 2001, alex black wrote: > > > > > > > > I like having the control definition in there, I think it's nice and > > > > convenient (and it gives you iron fisted control over default > > presentation) > > > > > > > > > > The entity definition really has nothing to do with presentation. I think > > even > > > the ptype is in the wrong place. These things are all meaningless to an > > XML > > > client, for example. Also, having a control definition inline like that > > means > > > it cannot be reused. I think that's evil :) > > > > How would you do it? > > Assume the following: > > -You want a default ui control assigned to each entity field > > -you want to be able to assign them easily > > > > where :)? > > > > _a > > > > > > _______________________________________________ > > binarycloud-dev mailing list > > bin...@li... > > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > > > > > > -- > > 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 > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
From: jason <ja...@gr...> - 2001-08-21 02:06:05
|
> Now's the time for suggestions/comments/flames/rants/etc :) You left out compliments. This is looking nice and creamy. |
From: Alex B. <en...@tu...> - 2001-08-21 02:24:02
|
>> Now's the time for suggestions/comments/flames/rants/etc :) > > You left out compliments. This is looking nice and creamy. :) |