Closed
Bug 291206
Opened 19 years ago
Closed 19 years ago
Verbose Template Rule format does not support parsetype="Integer" for literal match conditions
Categories
(Core :: XUL, defect)
Core
XUL
Tracking
()
RESOLVED
FIXED
People
(Reporter: bugs, Assigned: bugs)
References
Details
Attachments
(1 file, 1 obsolete file)
6.83 KB,
patch
|
Details | Diff | Splinter Review |
I wish to conditionally construct content using a verbose template condition set based on the value of a literal... if my literal is a string I can do: <template> <conditions> .. <condition subject="?item" predicate="http://foo/bar#goat" object="goat_must_be_this_value"/> </conditions> ... </template> But if FB:goat is not a string, if it is a RDF Int literal, I can't do this: <template> <conditions> .. <condition subject="?item" predicate="http://foo/bar#goat" object="42" parsetype="Integer"/> </conditions> ... </template> This works with the old style simple <rule>s though!
Assignee | ||
Comment 1•19 years ago
|
||
Assignee | ||
Updated•19 years ago
|
Attachment #181329 -
Flags: review?(vladimir)
Assignee | ||
Updated•19 years ago
|
Comment on attachment 181329 [details] [diff] [review] simple patch to make all roads lead to rome, that is, unify parsetype handling on new/old template condition types. r=vladimir, looks sane to me; Integer-with-a-capital-I looks too verbose, but I guess that's the way the Romans have been doing it for a while...
Attachment #181329 -
Flags: review?(vladimir) → review+
Assignee | ||
Updated•19 years ago
|
Attachment #181329 -
Flags: superreview?(bryner)
Comment 3•19 years ago
|
||
Comment on attachment 181329 [details] [diff] [review] simple patch to make all roads lead to rome, that is, unify parsetype handling on new/old template condition types. > nsresult >+nsXULTemplateBuilder::ParseLiteral(const nsString& aParseType, >+ const nsString& aValue, >+ nsIRDFNode** aResult) >+{ ... >+ else { >+ nsCOMPtr<nsIRDFLiteral> literal; >+ gRDFService->GetLiteral(aValue.get(), getter_AddRefs(literal)); >+ rv = CallQueryInterface(literal, aResult); If |literal| can ever come back null here, this will crash (CallQueryInterface doesn't null check). Does that happen if object is not set, or in some other case? If so, please do error checking here. Looks ok otherwise.
Attachment #181329 -
Flags: superreview?(bryner) → superreview+
Assignee | ||
Updated•19 years ago
|
Attachment #181329 -
Flags: approval-aviary1.1a?
Comment 4•19 years ago
|
||
Comment on attachment 181329 [details] [diff] [review] simple patch to make all roads lead to rome, that is, unify parsetype handling on new/old template condition types. a=me for 1.1a. Using 1.8b2 for good measure cuz this is core code. /be
Attachment #181329 -
Flags: approval1.8b2+
Attachment #181329 -
Flags: approval-aviary1.1a?
Attachment #181329 -
Flags: approval-aviary1.1a+
Assignee | ||
Comment 5•19 years ago
|
||
Attachment #181329 -
Attachment is obsolete: true
Assignee | ||
Comment 6•19 years ago
|
||
landed 1.8b2/1.1a
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•