jdev - 2021-05-19

  1. Sam

    I know there was a discussion on ordering of XML elements recently, and I don't see how this makes sense any other way (but also see nothing making it a requirement), but do <action>s in ad-hoc commands have to come first? It would make everything so much easier if they did…

  2. Sam

    > The result for each stage (other than the last) of a command's execution SHOULD include an <actions/> element. The user-agent can use this information to present a more-intelligent user interface, such as a "druid" or "wizard". Also does anyone have any idea what the hell that means?

  3. Zash

    A wizard dialog thing?

  4. Sam

    I guess? I have no idea what it's trying to say though

  5. jonas’

    Sam, like this? https://cdn.dribbble.com/users/1456587/screenshots/3817924/wizard-steps.gif

  6. Zash

    Like back in the olden days when you'd double click installer.exe and then click next, next, next, complete

  7. Sam

    I know what a wizard is; is a "druid" a thing too (I searched for it but couldn't find anything)?

  8. Zash

    `<actions/>` tells you which buttons to enable

  9. Sam

    That sentence immediately puts me out of context and made me think they were button names or something, I dunno, I was very confused.

  10. Sam

    I guess it doesn't matter if it's just talking about some obscure UI pattern though

  11. Zash

    Yeah no idea about "druid", I would have guessed either a DnD joke or a term that has died since the 90s.

  12. Sam

    More importantly, does <action> have to come first? If not I don't see how I could display the buttons in any forms that I create (although it still feels weird to get a form and also mix in some other element), although also it sounds like there can be multiple forms, so maybe I shouldn't display the buttons either way

  13. Sam

    Also if it came first I could immediately detect whether this was a multi-stage command or not

  14. Sam

    So I don't think it makes sense that it would come later, but also I see nothing preventing it.

  15. Sam

    I think I'll just operate under the assumption that it comes first until something breaks. It would make everything so much easier.

  16. Zash

    Unless it says so explicitly somewhere, assume that order gets randomized by every implementation 🙂

  17. jonas’

    what Zash says.

  18. Sam

    This says that payload order matters eg. when you display multiple forms, but it doesn't mention action.

  19. Zash

    Order of array-item-ish things matters, of course. Otherwise I don't think it need be that strict

  20. Sam

    But it also isn't really clear about whether you can have multiple forms except one sentence that suggests you might have both a form and an OOB thing in the same command, which I suppose suggests you can have multiple children. I really hate this spec.

  21. jonas’


  22. jonas’

    it’s not quite as terrible as '4, but it’s close

  23. Zash

    I _believe_ you can have anything you want as command payload

  24. Sam

    Right, so if you can have multiple of anything you want and order matters for them, presumably it matters for actions too so that you know whether you need to display a next button up front? Or maybe you are just expected to decode every single form first before displaying anything

  25. jonas’


  26. jonas’

    (the latter)

  27. jonas’

    after all, there could be an error down the road :)

  28. Sam

    Well that's unfortunate. I definitely can't decode everything up front because I don't know what they are up front, I hand the forms and OOB and whatever off to the user to decode (so they can put in their custom extensible payload or whatever)

  29. Zash

    Are you using a pull parser?

  30. Sam

    But actions need to be handled by the ad-hoc commands package.

  31. Sam

    Zash: more or less

  32. Sam

    I guess I can buffer the entire payload, extract out the stuff the user has to care about without the <action>, then hand them the decoded action and the buffered tokens and say "do some stuff with this" (which in the case of a form might be decode and display the form, append the actions as buttons to the end, then submit the response) but that feels jank

  33. Sam

    Or maybe I should just treat actions like any other payload and forms don't get nice buttons at the bottom.

  34. Sam

    Although I know nothing else does that; it's not very nice UI wise.

  35. jonas’

    that’s the impression I got from parsing dynamic nested structures with Golang, yes

  36. Sam

    *sigh* the whole point was to avoid parsing dynamic nested structures. Oh well.