Closed
Bug 74927
Opened 24 years ago
Closed 23 years ago
Need a generic way to pass arguments to commands
Categories
(Core Graveyard :: Embedding: APIs, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.0.1
People
(Reporter: sfraser_bugs, Assigned: mjudge)
References
Details
(Keywords: embed, topembed-)
Attachments
(3 files)
We need a generic way to pass arbitrarily complex sets of parameters to commands, for the following reason: We've decided that it's a Good Thing to provide to embedders a simple way to 'execute' user-level commands ("Make bold", "Insert table"), via a simple DoCommand/IsCommandEnabled interface. However, many such commands need to bring up UI to get further input from the user (e.g. rows and columns for table insertion). Unless we provide some way to package up command paramters, embedders would not be able to use the simple DoCommand API to execute such commands. This would force them to use different APIs for different types of commands, which would suck. So nsICommandParams provides a way to package up a set of parameters as name- value pairs, where values can be of a number of primitive types. Of course, as well as documenting what commands are supported by a component, we'll also need to document the require and optional paramters that those commands require. We can also use nsICommandParams to allow the embedder to communicate to us what kinds of command state it cares about (embedder hands us an nsICommandParams with entries for the values it cares about [e.g. "enabled", "bold"] and we can fill in the values and return it.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 years ago
|
||
Reporter | ||
Comment 4•24 years ago
|
||
This stuff lives in mozilla/embedding/components/commandhandler. Looking for r=, sr= I'll be adding an nsICommandManager interface that takes this command params soon.
A couple of comments: o No comments in IDL o Why is DOMString being used in the IDL for the name of arguments and string values? Shouldn't we use string for names and wstring for values? o nsCommandParams::GetLongValue sets _retval to PR_FALSE, should be 0
Comment 6•24 years ago
|
||
since it is getting reviewed now, setting to moz0.9
Priority: -- → P3
Target Milestone: --- → mozilla0.9
Reporter | ||
Comment 7•24 years ago
|
||
> o No comments in IDL I have a more recent version of the file with comments > o Why is DOMString being used in the IDL for the name of arguments and string > values? Shouldn't we use string for names and wstring for values? DOMString (which provides nsAReadable/nsAWritable strings in the C++ headers) is used because it allows for more efficient string usage, and avoidance of excess copying and allocation, yet can be used from JS just like string/wstring. As to whether value names should be ASCII or Unicode, I don't see a strong argument either way. Keeping everything as Unicode simplifies the interface, but I can see the value of using narrow strings. > o nsCommandParams::GetLongValue sets _retval to PR_FALSE, should be 0 Oops, thanks for that one.
nsICommandParams.idl should probably use nsAString instead of nsDOMString since this isn't really related to the DOM. The XPIDL compiler will generate the same nsAReadableString/nsAWritableString types so you shouldn't have to change anything in your implementation.
Comment 10•24 years ago
|
||
Correction: Changing QA contact for the Embed API bugs to David Epstein.
QA Contact: mdunn → depstein
Comment 12•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Updated•23 years ago
|
Reporter | ||
Comment 14•23 years ago
|
||
This landed with the editor embedding stuff.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 15•23 years ago
|
||
verifying against Mozilla 0.9.9 3/22/02: * nsICommandParams.idl. verifying change from DOMString to AString type. * nsICommandParams.cpp. verifying change from DOMString to AString, also nsAReadableString to nsAString type in various methods.
Status: RESOLVED → VERIFIED
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•