I think maybe Eaton's experise could be precious on that ? *expertise There were several questions that came up as I did that patch, and yes definitely would like to hear Eaton's thoughts, too * eaton takes a look at it... One question, do we have widgets use hook_elements? And if so, does each widget call their own, or does CCK do it for all widgets I would tend to think : KarenS: that was the focus of all the stuff dopry did with the values related stuff. - If we can avoid hook_elements, the better for contrib fields developpers - the more we can centralize in content.module the better * cdraptor (n=cdraptor@65.163.209.71) has joined #drupal-cck-stuff (general ideas, you obviously took a closer look than I did) Hm. How would using hook_elements prevent things from happening in CCK? If we use hook_elements, we go in the direction of creating widgets that any module can use, more toward CCK in core current discussion on http://drupal.org/node/167945 well, the code in #process #afterbuild etc will have to be CCK-specific of some sort, does't it ? If we standardize that #field will contain field info, then any other module that provides that could use the widget yched: I'm not *extremely* familiar with the processing and afterbuild related stuff, but now elements can have #value_callback, which is used to determine what the form value that comes in should be. Oops, sorry, I pasted the wrong link - FAPI port is discussed at http://drupal.org/node/157176 I have question that maybe someone may be able to help me with - to setup what I have, I am using Flex 2 with the services module, I am doing a node.save service and running into a problem with the Date Module CCK field in particular if process and afterbuild are being used by CCK to convert raw form values to 'stuff that CCK expects,' #value_callback could do the trick. Which is how dopry designed it IIRC cdraptor: sorry, not the right channel. please use #drupal ? cdraptor, we are discussing the 6.x port here, nothing else right now okay but the title is CCK stuff KarenS : you wrote "I also originally thought we could do this with only #value_callback, but I'm not so sure, and #process is more flexible I think" cdraptor: KarenS , yched , and eaton are in the middle of planning out the next version of CCK. Please don't distract them. can you expand ? Let's back up a bit and talk about the big picture, then the details... OK Do we want any of the widget code to be useful to anything but CCK? no problem, off to the drupal-dev I would say 'not a priority', compared to having sound CCK- related features and simple tasks for contrib fields authors (but maybe that's only me lacking a 'CCK in core' vision yched: I think that right now, widget code is the most complicated part of CCK. One way to think about this is that CCK is sort of a UI for end users who need help creating fields, but developers who don't need the UI could also use this If we make widgets that use standard FAPI constructs, they could be used by any module that understands what info they need But maybe I'm making this too complicated This is what I was thinking as well. If the extra handling code for a given widget is attached to #value_callback, #after_build, and so on, and CCK puts the burden of responsibiity for returning form values that make sense onto the widget developer... It means that at least only one system -- hook_elements plus processing callbacks etc -- is being used for complex form-related trickery. * cdraptor has quit ("Snak 5.2.1 IRC For Macintosh - http://www.snak.com") well, only the widget developper knows how his widget should massage the data ? yched: I think that's the idea. My impression is that the 'preprocessing the form values and getting them ready for CCK' step in CCK submission handling is the one that is most 'unlike' normal FAPI workflow, is that correct? eaton : probably - it's about : translate this widgets specific input into the format expected by the (widget agnostic) field I think both pre-processing and post-processing are different actually, I think most of this is currently 'deal with multiple values' Also the themes -- which need to combine multiple values into a single form element and the current goal is to abstract as much of that out of field modules and into content.module Except that if we abstract everything into the content.module, then CCK in core means starting over again maybe, but if widgets become stand-alone FAPI elements we can do CCK in core more easily not sure : multiple values is precisely one of the CCK-specific notions leaving them out of the hands of field auithors should be a good step towards 'stand-alone FAPI-like' elements multiple values is currently all in the hands of widget authors, isn't it? * tourguide What is FAPI the FAPI stuff only relates to widgets. k tourguide: this isn't a general discussion channel, it's a meeting for the Drupal 6 port of CCK :) tourguide: please domn don't interrupt. im aware - quietly listening "multiple values is currently all in the hands of widget authors, isn't it?" Yes - Bad Not sure about that, if CCK takes it over completely, much flexibily is lost Why do widgets need to do that, btw? Just because we want to do things like wrapping them in a fieldset if there are multiple values? and CCK doesn't do that automatically? This is the only sound way to add 'JS button to ajax-add new empty fields' Because widgets can be completely different kinds of animals -- optionwidgets multiple values create option lists, other widgets create multiple elements this gets requested every other week or other 'limit # of multiple values' KarenS: OK. How about this. and multiple values handling is the main area were contrib field modules are buggy eaton, yes?? Form elements as the baseline... with an optional flag in the widget definition hook that says, 'call function X when building the multi-value widgets, it will return the chunk of the form for you.' otherwise, CCK just puts multiple versions of an element in the form. just like CRUD is done now -- 'don't make me any tables, just give me the CRUD hooks.' eaton : yes, that's basically how I see it. widgets like select lists, who allow multiple selection in 1 widget, need to have a way to say 'I'm handling multiple all by myself' or stuff like google map 'point and click' locations (er, this might be Sci-Fi) but the default would be widgets saying to content.module 'here is the widget for 1 value, repeat it as you like and deal with the storage' I think that could work, so long as there is a way to opt out of the default handling For the current state of FAPI rework (leaving multiples for now) I have to admit that #after_build and #process makes me sort of nervous - this _is_ advanced FAPI stuff I mean, even eaton admits he does not fully gets them :-) The code in #process and #afterbuild is exactly the same as is now in hook_widget The way I saw it #value_callback could handle both 'prepare' and 'process' steps, but maybe I was wrong ? yched: well, I meant that I wasn't sure how #after_build and #process are used in CCK.... :> * eaton grins. ah, OK, sorry :-D but yeah, a lot of the after build and process stuff was just so that the value in $form_values could be finessed properly well, the 3 of us + dopry sold the #value_callback to Dries ;-) heh, yes yes, but that was before actually trying to write any code :) heh and maybe still the way to go, not sure the main difference is the arguments and what is returned "but that was before actually trying to write any code" : sure :-) KarenS: what arguments? I guess I should try to catch up and look at the actual code here. heh. eaton, I mean the arguments and return values for #value_callback versus #process #process gets $element and $form_state, I don't think #value_callback gets $form_state * eaton checks Yes, I see. value callback just gets the element itself. I'm not sure why process gets the entire form state actually. * yched sits silently and listens OK. So. in the context of CCK, am I correct in assuming that we want: Also, #value_callback happens before #process, so can't be used to change anything done by #process o OK, nevermind. I forgot where I was going with that thought. sorry. carry on ;) one of my questions as I wrote the code is where the form multiple values should actually get build, if built in hook_widget, it happens before both #value_callback and #process but looking at the way the system date and checkboxes fields work, the fields get expanded in #process, so I build the form element in #process instead then I can't use #value_callback, too late Well, just a moment. Why are we avoiding #process? That's not CCK-specific, is it? Or is the issue that things that use process can't take advantage of #value_callback? at least, not cleanly I didn't avoid #process, I used it, but it happens after #value_callback but a (CCK) widget knows how it should expand multiple values, right ? That's the idea, I think. so keeping 'multiple values' expansion in hook_widget for now could be OK, right ? I believe it would. And that leaves us more freedom of actually factroizing this in content.module if we decide to. Keep in mind that cck can still add its own #process that would run after the element's #process This is true. that would be 'field-level process', right ? or am I missing smthg ? I'm... not sure. could be either field or form level, depending on where we add it My brain went a few minutes ago. ;D if CCK takes the form element created by the widget, it can append another callback to #process that should run over just the field do you have an example ? date ? And cck can add its own #value_callback, if it has any reason to, but we still have the problem that #value_callback happens too early to help here no example, but should work (sorry, phonecall) What I ran into in writing the code I already did is that this is so darn complex that discussing it in theory is really hard, you kind of have to try to write code and get it working to see what will happen KarenS: my impression was always that value_callback would be used by the element itself more than CCK, to do proper finessing. eaton, yes I know, just making the point that CCK can add any callback it needs to * eaton nods. yep. this is true. :) eaton, and it was really *smart* for you to make all those callbacks arrays so we are not limited to just one :) well... er... admittedly, #value_callback is NOT in fact an array ;) Well, CCK shouldn't need to add anything to #value_callback, no ? - it does not know anything about the widget true but that's because, like #redirect, you can't really have duelling values also true yched: right. value_callback is mostly useful as a way for single-element stuff to do tricky business without having to use #process. #value_callback is a screwdriver and #process is a jackhammer. Or... something. ;) heh :-) I kind of think the screwdriver is not quite enough for CCK, but it still may be useful in other places er, not sure where that leaves us ? Well, what is the consensus about using hook_elements() here? What advantages or disadvantages are there? It's a bit more complex for module developers, but not much, and module developers need to understand FAPI anyway. Well, I sort of find they make a more complicated code for widget modules... oops - right It might even be a good tool -- example on how to use FAPI to create custom elements maybe that's not important though :) And long term, the advantage too is that CCK widgets would become more usable in other page types. er, form types. your example might be with the Services module - #value_callback ??? still quiet Karen : maybe, but if you add the CCK specific multiple values handling, it stays rather confusing I think we can still incorporate your idea about multiple values -- let CCK do it by default somehow Then 'normal' widget modules only create a single element Well apart from this 'multiple' thing, I probably don't have a strong feeling about hook_elements or not, aside from my (current) impression that the new code is somewhat complicated and that impression might fade away with time :-) I actually think the new code is less complicated, but that's probably because I wrote it :) but, well, we ask more from contrib developpers, and the general idea is that CCK API is already not easy to grasp yched: the complication, IMO at least, is due to several things 1) the fact that there is a lot of little-understood boilerplate copy and paste code that revolves around multivalue fields, even when the use cases are very simple and don't need the complex handling. true 2) It adds a layer of 'different-ness' on top of straight FormAPI development. widget development, that is er - what is "it" (in "it adds..." the advanced CCK cases are complicated, and the advanced formapi cases are also complicated, but if we can at least make both of those cases *the same kind of complicated* we have saved people some difficulties also true If we move multiple values handling back to CCK, the instructions for creating a widget module are pretty straight forward and much simpler than it is now Yep KarenS: and those who desperately need control can set the 'No, let me handle multiples' flag? eaton, as I will have to do with the Date module :) that's how fivestar works. it's not SUPER complex, but it implements an element type, which can be used anywhere, and then implements a widget that just uses that element type when CCK comes calling. multiples in imagefield is teh awesome :) KarenS: heh. yes... as per #process #afterbuild vs #value_callback : me being dumb would be 'if we can do with one FAPI callback instead of 2, sounds tempting to me' - I'm still unclear on the features we might miss with that I'm not sure how a widget that consists of multiple FAPI elements could be replaced by a "normal" single FAPI element -- a single FAPI element can be expanded quite easily to multiple elements, but AFAIK it's not easy to let that single expanded FAPI element return a value that's calculated from the values of those multiple elements. I failed while trying so, but then again I'm not a FAPI expert. That's why I liked CCK widgets, they provide another layer of abstraction and allow you to keep it simple. WimLeers, I think that's what we're saying -- the widget module will define a single value and CCK can expand it into multiple values as needed KarenS: that's not what I mean. yched, I'm not sure we need #afterbuild, the one place it might be needed is in nodereference and not sure it's needed there either, didn't really get that far KarenS: suppose you have a date field. The widget consists of 3 dropdowns: one for the day, one for the month, one for the year. Width a CCK widget, this is super easy. When you define a CCK widget as a single FAPI form element, you would have to expand that form element into three select form items and then make the "real" form element aggregate the input data from those 3 select form items. WimLeers, date module will be an exception anyway, but in your example, the 'single value' in this case is an array with the month, day, and year. Multiple values would be more than one date, each with its own month, day and year KarenS: exactly. But it seems you don't see that as a problem, so I'm probably looking at this from the wrong perspective. I'll shut up now :) WimLeers, well I haven't written the code yet, so maybe I'm missing something, but I don't think so Karen : So all in all I think we can go with the current approach you took :-) You probably should commit it when you think its ready, then we can polish / test / debug, Why don't I update my code to pick up your Schema API changes, then I'll rewrite it a bit to move multiple value handling back to CCK and see what it looks like and keep it as a patch for now, you mean ? either way, we cross-posted so I didn't see what you had said But if you're in agreement about the general direction, it's probably going to be easier to debug and modify if I go ahead and commit it well, I'd say commit the thing, and we'll - er yes, agreed ;-) Congrats for the great work :-) and you too, on Schema API (and everything else) :) Just released 1.6-1 hotfix releases, BTW 1.6 was screwed by a stupid typo. Bleh. :) I never make typos :) OK, back to work... I do more often than I should. Esp. for a security release. Double bleh yep - loads thx Eaton :-) no sweat glad to be whatever help I can ;) * eaton dashes :)