Feature Request #834
jcom.cuemanager "addresses" message
|Assignee:||Théo de la Hogue||% Done:|
|Target version:||MVC for 0.6|
I have some ideas about how the addresses message to jcom.cuemanage should work. One is to include a ".*" type wildcard. For example, sending /modelname.* in the address list to jcom.cuemanager should include all instances of /modelname in the jcom.cuemanager namespace.
Also, the list method of entering the addresses into jcom.cuemanager will be a problem for long lists. There should probably be other messages for "append" type listing. For example, addresses/clear could "clear" the list of addresses, addresses/append could append and address into the list of addresses. The message "addresses" as is could still handle lists.
Other, more sophisticated namespacing should probably be reserved for jcom.namespace to avoid redundancy. This could include searches for "model", "view", "parameter", "return", and even combinations like "model parameter" or "model return" to get all parameters of all models, or all returns of all modules respectively...
#1 Updated by Pascal Baltazar almost 6 years ago
+1 for wildcards !
+1 also for filters, but I guess we should specify this a bit more - I have already started an issue (#793) for excluding parts of the namespace, I'll create a new issue with both of our requests. Let's try to make up something good !
concerning list management, this is already something we can do very easily by patching, e.g. patch below for append
and it also allows to add addresses in other ways than just appending (because the order of the elements in the list is important, equivalent to priority)
do we really need to have this happening inside jcom.cuemanager ? I would say no, but your mileage may vary...
so... maybe we should break this down, and create a new issue for wildcards... and also for address management, if you have good arguments ;-)
#2 Updated by Pascal Baltazar almost 6 years ago
BTW, is the third part of your comment relevant to jcom.cuemanager ? or only to jcom.namespace ?
because, anyway, AFAIK, jcom.cueManager is only able to fetch parameter values, because messages and returns don't have persistent values... maybe I misunderstood something, though....
#3 Updated by Théo de la Hogue almost 5 years ago
- Status changed from New to Resolved
is this topic still open now there is no more "addresses" attribute ?
Now it's possible to edit a namespace (using filters) with the jcom.namespace and to use this namespace with the jcom.cue.
So I think many of your needs are cover by this new feature.
what's you're opinion ?
#4 Updated by Pascal Baltazar over 4 years ago
- Status changed from Resolved to Closed
The set of features now seems to be complete
The only potentially missing one would be to be able to retrieve the complete list of addresses that will be stored by jcom.cue - but that might be very complex (and can be seen by just opening the cue in an editor), so I'm closing this issue, until someone really has this need... (and then creates a new issue)