[cvs] [Wiki] changed: NewFieldType

[Wiki Guest]

guest [65.19.150.231]  Sun, 21 Aug 2005 20:07:45 -0700

Modified page: http://wiki.horde.org/NewFieldType
New Revision:  16.0
Change log:  Revert

@@ -1,91 +1 @@
-+ 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>