> On Mon, Jul 27, 2009 at 10:54 PM, David Maxwell <[email protected]> wrote:
> > While it's not absolutely critical, it would be nice if there was a
> > way to implement a form with multiple Submit actions, and a way for
> > the form processor to distinguish them. This is very similar to a
> > common problem encountered in designing HTML forms - except in
> > XMPP, the Submit isn't a form element, it seems to be implicit.
> >
> > The workflow I'm thinking of is queue processing, where you get a
> > queue item - fill out the form, and then want to do either Cancel,
> > Submit, or 'Submit+Next'.
> >
> > While the '+Next' could be implemented as a checkbox, that still makes
> > it two clicks instead of one, and is a bit artificial.
> 
> You should check out XEP-0050 Ad-Hoc Commands.  It sounds like this spec
> will cover your use case better.  It builds on XEP-0004 to provide a user
> workflow for forms with actions for submit, next, cancel, prev, finish.
> While not as flexible as say HTML Forms, it should cover your use case fine
> and if not, just have a list field for selecting a custom action type.

I've read that - but I don't think it addresses the case I described.

The form-server can <actions execute="next">, in which case you get
a 'Next' button, but no 'Submit and don't take another' button.

Or, you can send execute="submit" for the opposite case.

If you do use Next, the server will accept a client's request for
action="prev" - and let you go back, which wouldn't make sense in a
'Submit+Next' form environment, since you can't logicall 'undo' your
Submit.

> Ad-Hoc Commands is in widespread use for server, component, and bot
> administration as well as other uses.

I'm sure it works just fine, and I can see cases where it makes
perfect sense - I just don't think it does for mine.

I know I could build a custom client plug in to get what I want, but
I'm trying to avoid that in order to support all XMPP clients, by
just using standard functionality.  

I guess I'll live without that feature for now (or write a plug in
to add it on the client end, for the usability benefit to those who
run the client I choose to write it for.

I'd like to suggest that multiple submits be considered for the next
revision of Data Forms. It would broaden the potential applications
greatly, I think.

Thanks.

--
David Maxwell, [email protected]|[email protected] -->
If you don't spend energy getting what you want,
        You'll have to spend it dealing with what you get.
                                              - Unknown

Reply via email to