Re: Re: Subforms, Eh? Part I of III

Michael Cortez wrote:
> ...
> Lets say I just want to have two pubtypes, that use the same DD Object
> (perhaps the DD Object is subscribers or something.)  One of those pubtypes
> will want add/edit/delete control.  And the other is to only have "pick from
> a list" support.
> 
> How do I get <xar:data-list /> to display using different templates?  Can I
> pass an overiding template into it via an attribute?
> ...
I would say simply by adding another configuration option in the
validation thing, e.g. if it's a list of children, in what format
do you want to present that list in the input form : "input" or
"output" ?

When you define the subform property for one pubtype, you specify that
it's "output" format, and when you define the subform property for the
other pubtype, you specify that it's "input" format, etc.

Then in admin-showinput-subform, you either use xar:data-list or
xar:data-view depending on the selected format.

As a further refinement, you could also make the layout configurable,
and pass that to xar:data-list / xar:data-view as well instead of
using the generic layout="subform" there.

And of course showInput() could support $format and $layout as
arguments directly too, so that you could specify them directly
in xar:data-input tags as well (and the same for showOutput(),
with $layout and xar:data-output).

> And a different, more difficult problem :
> 
> I'm also going to need help on the array of properties being displayed when
> editting.  For example, my code right now will NOT work for complex
> datatypes like ComboBoxes and Uploads properties, because I had to manually
> massage the data slightly using xarvarfetch() and putting  it into arrays to
> be passed to createItem() and updateItem().
> 
> The main problem is that when using <xar:data-list /> to display that table
> of properties we end up with things like dd_123[0], dd_123[1], dd_123[2],
> etc.  The properties themselves don't know how to handle that, and even just
> the simple ones like Text Box just grab dd_123 -- assume that it's a string,
> and pass that along to the datastore for storage (which then blows up with
> an Array to String conversion error.)
> 
> So I had to build some code that goes out and figures out the fact that
> there is an array of them out there, and martial them into the properties in
> a way that they could handle the data.  The problem though, is that I only
> check for the main dd_123 variable, and not any secondary variables that the
> property may have -- for example, the combo box property puts two separate
> input fields out there (a dropdown and a text box.)
> 
> --
> Mike C.
> 
Yeah, I know - that's one of the reasons why I didn't finish the
"cells" layout for object lists either, because it requires a bit
more tweaking to process the input for multiple items. We'll get
there eventually - but it may require some more evil thoughts :-)

Mike.