Menu
▾
▴
Re: [Mantisbt-dev] RE: [Mantisbt-cvs] mantisbt/lang strings_english.txt,1.104,1.105
|
From: Julian F. <ju...@be...> - 2003-01-20 21:26:49
|
Chr...@he... wrote: > From: ju...@be... [mailto:ju...@be...] > >>Chr...@he... wrote: >> > Hi, >> > >> > great that people are picking up the development from the >>custom fields. >> > >> > Can somebody tell me what the status of the custom field >>collections >> > is? >> >>I've been wondering that a bit myself. I have your patch in >>my list to >>review, but it seemed that we began a bit of a discussion >>about a more >>generic mechanism and never really reached a concensus out of >>it. [...] >> >>Ok, I looked back through the archives and I was thinking of >>the thread >>"New feature proposal: test sheet management". In particular >>look at my >>request for more information in: >> >>http://sourceforge.net/mailarchive/message.php?msg_id=2680073 >>[...] > > > Hm, those links don't work - but I've got 2 older messages with that > topic still in my inbox, and I think it's those two messages... Really? Hmm... just tried them again and they work from here... weird. > > >>-----------snipped suggestion-------------------- >> Yes. How about if we have several functions: >> >> - one would take the custom field id (just for kicks) and return an >> associative array of possible values (in the LDAP example: >>{'jfitzell' >> => 'Julian Fitzell', 'vboctor' => 'Victor Boctor'} ) These values >> would be used when rendering the select box. You could >>return false or >> something if you just wanted an edit box. >> >> - one would take the current value (the key stored in the >>db) and the >> custom field id (for consistency - again, why not?) and would return >> HTML that provides the output description. It might just >>be a string, >> it might be a link to the test sheet, whatever. >> >> - one would take the custom field id and the new assigned >>value (when >> the value changes) and would allow something else to happen when the >> value is changed. We would always store the value in the >>custom field >> ourselves but you could change something else here. >> >> - anything else? >> >>[...] >> >> We might actually be able to do without this. What if we >>allowed any >> type of field to define the three methods I propose. That >>way we still >> retain the information of whether it should be an input >>box, a select >> box or what. >> >> If any of the columns that specify the methods to call were NULL we >> just wouldn't call that one. >>------------end snipped suggestion---------------- >> >>Anyway, don't reply to this without reading the references >>messages, and >>there is much more detail, but this is the core of what I was >>suggesting. If it needs clarifying I will try to provide it. >> If we can >>actually come to a consensus on all this, we can at least get the DB >>changes done for 0.18 and the code could be done soon after >>(particularly if you have time to work on it). >> >>Thoughts? Does this seem like a more general solution that >>would still >>solve your problem? > > > As I understand thos suggestions you want to create the posibility to > have a custom user defined function that looks data up and creates a > dropdown-list (or something similar) for you. > > But this is only one part of the problem that the collections do save. > What I need is a way to fill in (in my case) 3 different fields at the > same time, based on data that got looked up somewhere else. > > So the custom functions are both: not enough for my case (i.e. my > solution is more general) as well as an improvement for the colletions > (i.e. an additional data source). Well, as I see it you could do this two ways: 1) define only a field for the drop down list - the first function would return an array of selections that it gets from LDAP - the second function would return html that just displays the complete data from LDAP based on the value of the key (so you'd see a list box when editing, but several fields of straight text when viewing) - the third function wouldn't need to do anything 2) define a field for the drop down list and the other fields - the first function for the drop down would be the same as above - the second function of the drop down wouldn't be needed - the third function for the drop down would take the selected key, and if it was different from the old value, would look up data in LDAP, and store it for the other custom fields you defined. - none of the other fields would need custom functions (1) gives you dynamicly updated data from LDAP (ie you just store the key). (2) gives you one-time data setting from LDAP that is stored in the local DB - you could override it if you wanted. So, as I understand what you need, I think you *can* implement with what I'm proposing. And all we need in the core code is some simple code to call custom hooks, rather than ldap-specific DB fields, ldap-specific code, and more switch statements to deal with all the type of fields. > So let us add both together and then we've got collections and the data > for a collection (which can consist of a single custom field) can come > from a database (already implemented), ldap (already implementd) or a > custom function (i.e. your suggestion; has to be implemented) But getting data from ldap could be implemented in terms of custom functions... that's why I say it's more general. Having special code to deal with LDAP seems like an unecessarily specific thing to do. Does that clarify at all? Do you still think it won't do what you need? (it's possible I'm unclear on exactly what that is - in my head this can solve both your problem and the "test sheet" functionality, which makes this more general). Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |