trying to figure out the best way to enable editing of images

            using horde_form image type

because at the moment form data being edited and containing an

            image field type, drops the image

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.

seems reasonable enough...

the type should be able to create the /tmp file, and then

             return the final data, but not do the final write-back,

             right?

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.

right

hmm.

I'm not entirely happy with the VarRenderer setup right now.

we still have the functions for rendering all the types off

             in one file, which seems clunky

and there are too many places you need to edit to add a new

             type - not intuitive at all.

i was just talking about bracking up horde_form into multiple

            files with jan earlier today

braking even

the hunch being that for each form you only need a handful of

            types right?

breaking :)

right.

which could be better efficiency that including 100k+ files

yeah. and there are probably other places we can reduce

             overhead in the form libs.

hm, no wonder "braking" looked weird too :)

like, do we really need Horde_Form_Type and

             Horde_Form_Variable? might be more efficient have variables

             just be instances of types.

(instead of having two instantiated objects for each)

i think it could all be folded into horde_form_variable

huh, I was thinking the other way around :)

dunno... either way i guess. was just following some language

            logic

true, yeah.

eh, I still think Type makes more sense? dunno.

variables have types, but ...

:)

back

Can I put in my $.02 re Horde_UI_VarRenderer:: ?

no, it will cost you $.04...

inflation

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.

hm?

For example, 'enum' and 'radio' are really different presentations

       of the same type.

And 'multienum' and 'checkboxes'.

And the various different date fields.

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).

We can pass options to field type and construction type and we use

       that for different representations.

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.

er s/and construction type/at construction time/

(using our packages to not break BC :)

but I agree that it could be organized more usefully.

works for me.

Would my login work for the wiki?

I want to post my Field:: class and a derived class for examples of

       what to do (and what not to do :).

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?)

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