Proposal for Implementation of New Package to Replace Horde_Form_Type:: and Horde_Form_Variable::

Notes

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