Closed dantleech closed 11 years ago
I also think that these commands are wanting to be a complete CLI interface to PHPCR. I wonder what the possiblities are there? e.g. an interactive shell for phpcr.
i like this, thanks. and i agree with the rename to type:register (did you check if we mention that command anywhere?). when merged, we should update the phpcr-bundle commands as well.
an interactive phpcr shell sounds really cool, but like a rather extensive project. i would vote to postpone that until we have the cmf 1.0 released ;-)
when i merged the move command, this went into conflict. can you do a rebase on master?
Updated. If we are adding the "type" namespace, then should we also introduce "node" ?
phpcr:node:move
phpcr:node:touch
phpcr:node:purge
phpcr:type:list
phpcr:type:register
[...]
What would the eventual scope of this command be? Should we expose all the properties of the NodeTypeInterface for inspection? I guess it follows that there should also be a command for "touching" node types :)
Also.. updated docs for all three new commands: https://github.com/symfony-cmf/symfony-cmf-docs/pull/129
printing more details about nodes could make sense, yes. and we could also do some export to cnd. about creating nodes i think that is a lot less important, we do have type:register. not sure how often people want to rather do that interactively, or even less with cli arguments.
moving things into the node namespace sounds correct. i think we should have a node:remove command and leave the purge where it is, but remove the path option from it. so purge would be sort of "drop database" and node:remove "delete from..." (but in the implementation purge can extend from node:remove and just hardcodes the path to delete and so on.
ok... then my next PR will move the node stuff to :node:
and do as you say with purge, and also maybe refactor the classnames to better reflect their CLI names.
thanks a lot!
So this is an RFC for the list node types command because I'm not sure if we can add anything extra. I have also taken the liberty of moving "register-node-types" to "type:register".