Closed
Bug 325566
Opened 19 years ago
Closed 9 years ago
Expose interface for instance nodeset work
Categories
(Core Graveyard :: XForms, enhancement)
Core Graveyard
XForms
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: surkov, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051212 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051212 Firefox/1.6a1
I have a foggy idea. Perhaps you can make clear it :).
nsIXFormsAccessors works with a single node. I can see the utility of interface for work with nodeset. Possible tasks for interface are:
1) enumerating nodes/getting nsIXFormsAccessors interface for node
2) appending/removing nodes
I guess I cant use xpath evaluator (like XPathEvaluator javascript object) because xpath for xforms is wider than just xpath.
The idea is casted by distensible list control. It should be used for list view, should be intitialized by nodeset and have new items adding/removing possibilities. It means the next.
I have instance data:
<test>
<item>
<field1>Item #1. Field #1</field1>
<field2>Item #1. Field #2</field2>
</item>
<item>
<field1>Item #2. Field #1</field1>
<field2>Item #2. Field #2</field2>
</item>
</test>
My list control should be able to show the instance data:
|--------------------|-------------------|
| Item #1. Field #1 | Item #1. Field #2 |
|--------------------|-------------------|
| Item #2. Field #1 | Item #2. Field #2 |
|--------------------|-------------------|
It should be able to append new items and remove items too.
Now if I want to realize the control then I should use a couple of repeat/insert/delete xforms controls. I think it is not a nice way.
I need in your opinion about interface and list control.
Reproducible: Always
So I think what you are looking to do is create your own control that behaves like a xforms control (ties in with the MDG for automatic refreshing, etc.) and that has a nodeset attribute. Right?
I assume that most of what you are looking for will evolve when xf:repeat is xbl-ized (bug 306247). You might want to make sure that you are cc'd on the bug.
Reporter | ||
Comment 2•19 years ago
|
||
(In reply to comment #1)
> So I think what you are looking to do is create your own control that behaves
> like a xforms control (ties in with the MDG for automatic refreshing, etc.) and
> that has a nodeset attribute. Right?
For sure.
> I assume that most of what you are looking for will evolve when xf:repeat is
> xbl-ized (bug 306247). You might want to make sure that you are cc'd on the
> bug.
>
Yes, you're right. I guess I can do it by repeat/insert/delete using. But I'm confused with the following reason. If xforms control has ref attribute then there is nsIXFromsAccessors interface. If xforms controls has nodeset attribute then what thing instead of nsIXFormsAccessors interfaces should be? Is the answer nothing? There is other side. I guess nsIXFormsAccessors will be without delegate (bug 312956). It means nsIXformsAccessors will be for instance node, but there is no interface for instance nodeset. I have a feel it's needed but now I can't see the utility for it.
Comment 3•19 years ago
|
||
I agree with Aaron that an XBLized repeat will solve some of it. Let's see what it ends up like, and take it from there.
A good thought though. We might need something for controls that are bound to nodesets.
Depends on: 306247
> Yes, you're right. I guess I can do it by repeat/insert/delete using. But I'm
> confused with the following reason. If xforms control has ref attribute then
> there is nsIXFromsAccessors interface. If xforms controls has nodeset attribute
> then what thing instead of nsIXFormsAccessors interfaces should be? Is the
> answer nothing? There is other side. I guess nsIXFormsAccessors will be without
> delegate (bug 312956). It means nsIXformsAccessors will be for instance node,
> but there is no interface for instance nodeset. I have a feel it's needed but
> now I can't see the utility for it.
>
I'm sorry, I think that you misunderstood what I was trying to say, so I must have said it poorly. What I meant to say is that we'll probably have to change nsIXFormsAccessors to do a lot of what you are looking for in order to get xf:repeat properly XBL-ized since it relies on @nodeset. Once xf:repeat is XBL-ized, see if nsIXFormsAccessors is still missing something that you need.
Reporter | ||
Comment 5•19 years ago
|
||
(In reply to comment #4)
> I'm sorry, I think that you misunderstood what I was trying to say, so I must
> have said it poorly. What I meant to say is that we'll probably have to change
> nsIXFormsAccessors to do a lot of what you are looking for in order to get
> xf:repeat properly XBL-ized since it relies on @nodeset. Once xf:repeat is
> XBL-ized, see if nsIXFormsAccessors is still missing something that you need.
>
Sorry, I really misunderstood you. Now it's ok.
Comment 6•19 years ago
|
||
One of the things that might, or might not, have gotten through in my comments in bug 316895, is that I think we should create specific accessor interfaces if controls need new functionality. That is, imho, setContent() should only be implemented by select/select1, and nodeset functionality should only on repeat. Just like for range:
http://lxr.mozilla.org/seamonkey/source/extensions/xforms/nsIXFormsRangeAccessors.idl
Updated•19 years ago
|
Severity: normal → enhancement
Updated•18 years ago
|
Assignee: aaronr → xforms
Reporter | ||
Comment 7•18 years ago
|
||
Some thoughts about accessors interfaces.
interface nsIXFormsContent : public nsISupports {
const unsigned long SIMPLE_CONTENT = 0x01;
const unsigned long COMPLEX_CONTENT = 0x02;
const unsigned long NODESET_CONTENT = 0x03;
readonly attribute unsigned long contentType;
};
interface nsIXFormsSimpleContent : nsIXFormsContent {
// usual nsIXFormsAccessors
};
interface nsIXFormsComplexContent : public nsIXFormsContent {
// return xforms content object by relative xpath expression
nsIXFormsContent getContentByExpr(aXPathExpr);
};
interface nsIXFormsNodesetContent : public nsIXFormsContent {
// navigation methods for nodeset
};
Usually xforms elements will implement nsIXFormsSimpleContent. If we will have elements bound to complex content then nsIXFormsComplexContent will used. For repeat elements nsIXFormsNodesetContent will be used. Any thoughts?
Reporter | ||
Comment 8•18 years ago
|
||
(In reply to comment #6)
> One of the things that might, or might not, have gotten through in my comments
> in bug 316895, is that I think we should create specific accessor interfaces if
> controls need new functionality. That is, imho, setContent() should only be
> implemented by select/select1, and nodeset functionality should only on repeat.
> Just like for range:
> http://lxr.mozilla.org/seamonkey/source/extensions/xforms/nsIXFormsRangeAccessors.idl
>
nsIXFormsComplexContent will expose setContent() method.
Comment 9•9 years ago
|
||
RIP xforms
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•