Johannes Verelst <[EMAIL PROTECTED]> wrote: > 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.
A bit tricky, but I won't rule it out, that it is possible to implement such a thing. I do think it is a bit strange however that values of a field depend on the context of the node. What happens if you reuse the node on different spot. The field-values can become impossible then, at once. > > > 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. Ok, I can agree with that. > 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. Perhaps then optionlist-queries chould not be deprecated, but only discouraged :-) Or perhaps it must be possible to somehow limit an existing possible value set. Or perhaps you could think of named subsets of possible value sets, or whatever. Michiel -- Michiel Meeuwissen Mediacentrum 140 H'sum +31 (0)35 6772979 nl_NL eo_XX en_US mihxil' [] ()
