On Wed, 5 May 2004, Michiel Meeuwissen wrote: > Johannes Verelst <[EMAIL PROTECTED]> wrote: > > Any comments? > > It's probably a good idea. The only remark that I would like to make is that > the possible values of a certain field, are actually not related to > editwizards. The field-types project was a.o. started to be able to define such a > thing more generally. If e.g. the possible values of one field follow from > the result of some query, I'd say that you should define that query inside > the definition of the field itself, somehow. That would of course also imply > changes to dove and editwizard, because the concept of 'possible values' > must be transferable by the dove-protocol.
While I agree that this would be the most elegant solution, I don't think it's workable. Sometimes the possible values for a field depend on a lot of outside variables. For example; say you want to define newstypes within a site: for the field value 'type' of a the 'news' builder you will need to know the site this newsitem is related to. When asking a 'Field' for possible values, this class needs to know about the context it is called from. > When this is finished, all optionslist can be removed from editwizards, > because everything is automaticly determined by the field's specialization > definition. It will then of course also be available to other editors, like > taglib-editors or so. I disagree, since it might be very well possible to have a specific editwizard where a subset-optionlist is shown. > So, my hope is that every change on this field might soon become > deprecated... We do need a good inventory of what kind of lists of possible > values there are, becasue those need be 'definable', preferabbly without to > much of java-coding. This will also imply other constraints like minvalue > and maxvalue for floats and so on (The possibilities are endless so the > trick will be to find something reasonably simpl, yet feasible enough to > cover most things one might want). I think it's a very good idea to put more logic into fields, but I don't think that everything can be done there. When for instance possible values depend on a context, this creates a lot of overhead in the Field implementation. Putting it inside an optionlist-query is not such a bad solution in my opinion. Johannes -- [EMAIL PROTECTED] | It is always possible to agglutinate multiple [EMAIL PROTECTED] | seperate problems into a single complex inter- PGP ID: 0xFED127BD | dependent solution. In most cases this is a Tel: 035-6474202 | bad idea. (RFC 1925, Truth 5)
