Closed dantleech closed 9 years ago
indeed. i would opt to not attempt to guess types (like "5" is number, but "5 tests" is a string....) but having an optional argument to force a type makes sense. the options would be the type names of PHPCR.
I wonder about the syntax however:
--set-prop=foobar=(boolean) 0
// or
--set-prop=foobar=0 --set-prop-type=foobar=boolean
On Fri, May 24, 2013 at 12:17:47AM -0700, David Buchmann wrote:
indeed. i would opt to not attempt to guess types (like "5" is number, but "5 tests" is a string....) but having an optional argument to force a type makes sense. the options would be the type names of PHPCR.
— Reply to this email directly or [1]view it on GitHub.
References
Visible links
i prefer the later. its an edge case anyways and parsing input is painful. and what if i want a string property "(boolean) hello"? i would have to do "(string) (boolean) hello" and that is rather unexpected.
Another way to handle this and reduce parsing complexity (but increase UX complexity) might be to do the following:
./bin/phpcr phpcr:foo -f=field1 -f=field2 -f=field3 --type=string --type=string --type=string --value=val1 --value=val2 --value=val3
That would also allow setting multi-values by specifying a field multiple times. I can't say I like it, but its an option.
could we also specify fields without options? as in touch /path foo=bar this=that
? and then touch /path foo[]=bar foo[]=baz
? and for the type touch /path foo=2 --type=foo=string this=that
and touch /path foo[]=1 foo[]=2 --type=foo=string[]
?
@dantleech is this handled by phpcr-shell now?
yep
PHPCRSH > node:property:set --help
Usage:
node:property:set [--type="..."] path [value]
I guess I will close.
should we deprecate node:touch and drop it in 2.0?
Would be nice to be able to force type when setting a property, for example, (boolean) 0, (integer) 5. At the moment all are evaluated as string.