Previous Entry Share Next Entry
What's the syntax for "edit a property value"?
device
jducoeur wrote in querki_project
Quick question looking for opinions --

One of Friday's jobs was figuring out how AJAX works in the Play/jQuery Framework -- in particular, how do we set things up to edit a field and have the change sent back to the server without an explicit "Done" button and page reload. This turns out to be delightfully easy -- indeed, arguably easier than traditional forms -- so we're going to use it for the RSVP buttons in the wedding invites, and that's today's task.

But this being Querki, we're going to do it in the appropriately general way: you can place an edit field on any page, with live updating back to the server. "Done" or "Save" buttons should become more the exception than the rule (really, only for relatively transactional data, when it is important to save everything at once), which I think matches folks' usual expectations nowadays.

So the question is, what's the syntax for saying "put an edit field here"? Remember that the syntax to display My Property is
[[My Property]]
Following that model, I've thought of a few options so far:
(1) [[!My Property]]
(2) [[<>My Property]]
(3) [[My Property.edit]]
I can make decent arguments for any of these, and probably more besides. The first two treat this as a first-class syntactic construct in QL, which is fair since I expect it to be *extremely* common. The third treats it as simply a method on "My Property" -- basically a meta-method that applies to anything that derives from "Property". I like the second aesthetically (the sigil emphasizes the "in-out" nature of it), but the third may be more obvious, and does provide the obvious ability to introduce parenthesized parameters to tweak the edit controls.

I don't think I have any passionate opinions yet, though, so I'm looking for any additional suggestions or preferences. Anybody care to venture an opinion before I go implementing?

ETA: Okay, responses seem to clearly prefer #3, and I think the arguments have convinced me. So next, I'll post a little about what that actually *means* -- it scratches the surface of a whole new area of concepts and syntax that I'm implementing today...

  • 1
I read #1 as "Not My Property".

#2 just looks odd, as if you were prefixing My Property with a degenerate HTML tag. Maybe something that encloses My Property? {My Property}?

I like #3's obviousness, and I think you're right that it provides a good way to add params.

I favor #3's obviousness as well. It becomes much clearer for someone to read and understand what it means/does. Syntactic sugar should make things easier, and the first two don't actually do that. There may be some reduction in characters typed, but at the expense of clarity.

Likewise. 5 characters isn't too bad. If you want it more concise, .ed is OK, but not as obvious and more easily overlooked.

(And that ability to add parenthesized parameters is big - there are *loads* of things one might wish to specify about "how this property should be edited", and parameters are going to be a lot cleaner than developing some sort of "...but a *colon* means use radio buttons" PERL-like soup of symbols.)

For me I'd like to see being able to fill in 'defaults'. Maybe from information already available elsewhere, maybe in the faded 'prompt' style some websites us in forms to maximize clean design. Parenthetical optional parameters are great for the more power user type, and easily ignored by the novice user.

Actually, both of those concepts already exist at the Property level. One of the reasons for Querki's rule of "everything is a Thing" is that is makes meta-Properties very straightforward. So there are a host of meta-Properties you can use already, including default value and "placeholder" (the "faded prompt" you're talking about).

That said, it's true that being able to pass situation-specific prompts and defaults is likely useful, and some of that may want to happen with parameters...

So there are a host of meta-Properties you can use already, including default value and "placeholder" (the "faded prompt" you're talking about).

Oh, very nice.

That said, it's true that being able to pass situation-specific prompts and defaults is likely useful...

Yesyes. Last place I worked we had a widget library where you could specify "for data item X, use an edit-field of (eg) this width, this prompt, this default value, this styling, this data validation (etc etc ad infinitum)" - and even with that level of customizability, there were plenty of pages which needed to override. (Perhaps their GUIs worked slightly differently, perhaps they were space-constrained, perhaps they had context - eg: part of a wizard - which made the usual prompts and labels incorrect, etc.)

  • 1
?

Log in

No account? Create an account