+ Proposal for Implementation of New Package to Replace Horde_Form_Type:: and Horde_Form_Variable:: ++ Notes <code> oo> trying to figure out the best way to enable editing of images using horde_form image type <oo> because at the moment form data being edited and containing an image field type, drops the image <oo> the idea i'm following right now would be that the image data is copied from the vfs store to the /tmp dir for display/modification by the image field. then upon submission copied back. <cjh> seems reasonable enough... <cjh> the type should be able to create the /tmp file, and then return the final data, but not do the final write-back, right? <oo> only thing is, this would have to be triggered by the renderer. because the form type doesn't know about the old data being loaded until it is rendered. <oo> right <cjh> hmm. <cjh> I'm not entirely happy with the VarRenderer setup right now. <cjh> we still have the functions for rendering all the types off in one file, which seems clunky <cjh> and there are too many places you need to edit to add a new type - not intuitive at all. <oo> i was just talking about bracking up horde_form into multiple files with jan earlier today <oo> braking even <oo> the hunch being that for each form you only need a handful of types right? <cjh> breaking :) <cjh> right. <oo> which *could* be better efficiency that including 100k+ files <cjh> yeah. and there are probably other places we can reduce overhead in the form libs. <oo> hm, no wonder "braking" looked weird too :) <cjh> like, do we really need Horde_Form_Type *and* Horde_Form_Variable? might be more efficient have variables just be instances of types. <cjh> (instead of having two instantiated objects for each) <oo> i think it could all be folded into horde_form_variable <cjh> huh, I was thinking the other way around :) <oo> dunno... either way i guess. was just following some language logic <cjh> true, yeah. <cjh> eh, I still think Type makes more sense? dunno. <cjh> variables have types, but ... <oo> :) <Eraserhd> back <Eraserhd> Can I put in my $.02 re Horde_UI_VarRenderer:: ? <oo> no, it will cost you $.04... <oo> inflation <Eraserhd> hehe. I agree with pretty much everything. I keep thinking that we have too many types. We need to coalesce different representations of the same type. <oo> hm? <Eraserhd> For example, 'enum' and 'radio' are really different presentations of the same type. <Eraserhd> And 'multienum' and 'checkboxes'. <Eraserhd> And the various different date fields. <Eraserhd> Part of the reason I think that, though, is because we have a similar thing in our old framework, but it has slightly different semantics which make it much more useful. They represent *data* types not *field* types in our system, and the result is that a data type knows how to draw itself, accept form input, accept "query" input (like a range for the value for ints or a keyword expression for strings). <Eraserhd> We can pass options to field type and construction type and we use that for different representations. <cjh> I kind of think that we need to start this as a new package of some sort, so that we can develop it and *then* selectively migrate existing apps to it. <Eraserhd> er s/and construction type/at construction time/ <cjh> (using our packages to not break BC :) <cjh> but I agree that it could be organized more usefully. <Eraserhd> works for me. <Eraserhd> Would my login work for the wiki? <Eraserhd> I want to post my Field:: class and a derived class for examples of what to do (and what not to do :). <Eraserhd> The other thing was that I was thinking about this export definition thing, and I think you should be able to query a Field::-derived class for different representations (e.g. Do we want to export as UNIX timestamp or mm/dd/yyyy?) <cjh> you can do that with the date type in Horde_Form now, I believe. <oo_> correct <oo_> plus don't know what i missed but enum/radio are only different in how they are rendered.. in the horde_form_type classes one inherits from the other </code>