Inline Edit: Single line/multi-line?

Antranig Basman antranig at
Tue Jul 15 17:51:26 UTC 2008

I am wondering whether we should not proceed more DOM-agnostically about this. I would 
await a steer from Colin, but I would imagine that we position the users 
of this widget as "reasonably competent" HTML developers who would be capable of more
easily specifying the HTML form of the "editable" version of the widget in-line
more directly, rather than having to wrap every possible form of HTML editability
within our own Fluid API. I imagine this will be the sort of thing we will chat
about on Thursday, but the demo we showed at Paris for an inline-editable table of
cells, had markup like the following:

      <td class="quantity-container">
        <span rsf:id="quantity">9</span>
        <input rsf:id="quantity" type="text" size="3" style="display:none" />

So we would position for any more "complex" operations like the ones below,
(single/multiline/autowrapping) etc. we would expect the component user to
simply write the markup they require as above, and either let the markup
stand in place, or else perhaps let the renderer take the slack if 
multiple instantations were required.



Anastasia Cheetham wrote:
> On 14-Jul-08, at 2:33 PM, Daphne Ogle wrote:
> > Are we in need for a conversation about this?  It seems like this is
> > quite a complicated conversation to have asynchronously.
> A conversation is probably a good idea, we should definitely do that.
> At the same time, an email thread acts as a record of a conversation,
> which my aging brain appreciates ;-)
> > As far as defaults, can we specify based on the field type?
> Just thinking aloud here...
> I imagine that we could have a single configurable components that
> comes with several different API methods depending on the use. The
> idea would be that the name of the function call would make it pretty
> obvious what the purpose is, so for example:
>      fluid.createSingleLineEdit();
>      fluid.createMultiLineEdit();
>      fluid.createAutoWrappingEdit();
> or some such thing. Technically, the internals of the components would
> configure different defaults based on the implied context for each of
> these cases (which would, of course, be clearly documented), and in
> any case, the defaults could be overridden.
> > This conversation makes me wonder about display while editing versus
> > display once edited.  Does the component control both?
> That's a very good question. We'd probably benefit from some
> wireframes illustrating what the ideal interaction would look like in
> the various contexts.

More information about the fluid-work mailing list