Closed Bug 14273 Opened 25 years ago Closed 25 years ago

XUL templates: problems with containment

Categories

(Core :: XUL, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: alecf, Assigned: waterson)

Details

(Whiteboard: back to originator for verification)

I have some problems creating content with XUL templates, specifically with
containment.

This problem shows up in many places in messenger:
- the Move and Copy menus - very often the menu items won't show up until you
pull the menu down a number of times.
- The "<html:select>" widget in the New Folder dialog - you only get the
toplevel list of servers, no subfolders
- trees with the persist="open" option, or add open="true" to your treeitems
(bug #13252)


Here's an example of what we're trying to do (from the new folder dialog)
		<html:select id="selectedparentfolder"
          datasources="rdf:msgaccountmanager rdf:mailnewsfolders"
          ref="msgaccounts:/">
          <template>
              <html:option uri="..." value="...">
                <text value="rdf:http://home.netscape.com/NC-rdf#Name"/>
              </html:option>
          </template>
        </html:select>

What you end up seeing is
+---------+-+
| server1 |V|
+---------+-+
| server1   |
| server2   |
| server3   |
+-----------+

but I expected
+---------+-+
| server1 |V|
+---------+-+
| server1   |
| Inbox     |
| Trash     |
| (etc)     |
| server2   |
| (etc)     |
| server3   |
| (etc)     |
+-----------+

In another case, I'm trying to use the <html:optgroup> tag, which allows for
hierarchical combo boxes

I have a folder structure like this:
server1
  Inbox
    subinbox
  Trash
  Anotherfolder
    folder3

And when I use this template:
<html:select name="identity.fccFolder"
         onchange="dump('value=' + event.target.value + '\n')"
         rdf:datasources="rdf:mailnewsfolders rdf:msgaccountmanager"
         ref="msgaccounts:/">
    <html:optgroup/>
    <template>
      <rule iscontainer="true" isempty="false">
          <html:optgroup uri="..."
label="rdf:http://home.netscape.com/NC-rdf#Name">
              <html:option value="..."
label="rdf:http://home.netscape.com/NC-rdf#Name"/>
          </html:optgroup>
      </rule>
      <rule>
        <html:optgroup>
          <html:option value="..." uri="..."
label="rdf:http://home.netscape.com/NC-rdf#Name"/>
        </html:optgroup>
      </rule>
    </template>
    </html:select>

(When I tried rooting the server at msgaccount:/, I got results similar to the
first example. You'll notice in the above example that I rooted it at one of the
servers)
This is what I get:
+---------+-+
| server1 |V|
+---------+-+
| Trash     |
| Drafts    |
| Inbox     | <html:optgroup> element
|   Inbox   | (first sub-item of optgroup)
| AnotherFol| <html:optgroup> element
|   AnotherF| (first subitem of optgroup)
+-----------+

I was expecting this:
+---------+-+
| server1 |V|
+---------+-+
| Inbox     | <html:optgroup> element
|   Inbox   |   (first subitem of optgroup)
|   subinbox| <html:optgroup> element
|     subinbox| (first subitem of subinbox optgroup)
| Trash     |
| Drafts    |
+-----------+

I've looked at the DOMs for each of these situations, and the DOM exactly
matches the UI, so this isn't a problem with the combo box.

What this means:
- the template is searching the RDF graph and LOOKING at containment, so it is
matching the iscontainer="true" attribute in the rule, however, it is not
actually building up content from the children, unless it is queried a few
times. Menus are the only thing that seem to be able to requery the datasource
though.
- it seems to match the isempty="false" rule, as seen in the menus (because File
Here only appears on non-empty menus)
I forgot the last part of the last example,
add
| AnotherFolder| <optgroup> element
|   AnotherFolder| (first subitem of optgroup)
|     folder3  | (second subitem of the optgroup)
if someone will point me at the place that content is added to the DOM using a
template, I'll look into fixing this myself.
Chris, want some luv, i.e. this bug?  (I'm wondering if any of the optimizations
that have gone in lately have broken this?)
Assignee: rjc → waterson
Okay.

- The "move and Copy" menus stuff is a logged bug vs. XPMenus, it is not a
problem with templates. See bug 11661.

- The "<html:select>" problem is pilot error: your template has no way to
specify recursive hookup -- the datasource reveals the servers at the top
level; how are we supposed to know that we need to "flatten" the list to
include the folders below each server? Try writing the HTML first, and then
figure out how to "back" that in to a template. (It may be that you can't in
which case, we should file that as a separate bug.)

In your second example, uh, yeah, the template is working the way you told it
to. I think you need to factor it in to a couple more rules maybe.

- The persist-with-trees is a bug with the tree control, not templates. As you
note, bug 13252.

So let's concentrate on the second issue and say the other two are INVALID or
are already logged as separate bugs.

I may have screwed up something with HTML. Alecf, if you could point me to a
test case, I will happily look at this.
ok, I was theorizing that the odd problems all rooted from templates. I agree
then, too - I'll count the other stuff as INVALID..

Anyhow, I'll check in the example above into
chrome://messenger/content/am-copies.xul now
Status: NEW → ASSIGNED
Target Milestone: M11
alecf: could you re-pull nsRDFGenericBuilder.cpp and try this? There _were_ a
number of problems with the 'containment' property.
there were some problems with containment that i fixed, but this is different.
we discovered tonight that we're missing a "match" phase after we create the
HTML content, so that other rules can recursively apply. will try to fix
tomorrow...
Talked with waterson on IRC.
I'm going to theorize here, just because I'm curious if I'm getting this: when
we actually create the new nodes when we match a template, we're not continuing
to descend into the graph. This means we only get toplevel children....

so when we call CreateWidgetItem, we then need to go through that item as a
container, and create all it's elements.
I fiddled around in my tree to see if I could get it to do something.. I did
manage to get it to create all the children, but it actually added all the
children of all the nodes as children to all the siblings of the parents of
those child nodes. (That makes sense if you really think about it :))

..but then the combo box started acting really wierd, I think I put some bogus
content nodes in there or something.

anyway, waterson sounds like he understands this way better than I do, so I
eagerly await the solution to eagerly built content.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fix checked in.
Whiteboard: back to originator for verification
alecf, would you please verify this works?  Thanks!  -ckritzer
Not to be obnoxious, but this bug is EXTREMELY easy to verify, I don't
understand why I have to do it? just go to http://xchat.org/ - if it doesn't
crash, then it's fixed.
since when does QA not verify bugs that developers have reported?
Target Milestone: M11 → M1
alecf, i think you appended your flame to the wrong bug.
Status: RESOLVED → VERIFIED
doh.
sorry ckritzer
yeah, this works great now...
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: ckritzer → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.