David,
We use a two stage process similiar to a mix between your first and
third options but do not mess with the name attribute. First we use the
generated access methods to set required elements on the template row,
we then clone the row and remove any non-required elements from the
cloned row and finally insert the completed cloned row into the table.
No futher processing required. I do not understand why in the first
approach you a have a requirement to set an element after you've removed
it and why in the third approach you need to use the name attribute as a
flag. Hope that helps.
Regards,
Chris
David Michaels wrote:
One thing XMLC does very poorly is allow you to remove elements from
one template row in a table, but have them re-appear in subsequent
template rows.
The common case for this is when you have an HREF in your template row
that you wish to disable for certain rows -- you must remove the HREF
element to do this. The simplest options for doing this all have
drawbacks:
1. clone the template node first, then remove unneeded elements from
it. This loses the most convenient XMLC feature, namely the ability to
reference tags via page.getElementFoo() methods. No such methods exist
on the template row object (imho this would be the most powerful
feature to generate class files for specific template rows).
This is why I think everyone modifies the template row, THEN clones
the modified version. Note this is very suboptimal for cases when you
have a nested table associated with the first template row, but I'll
leave that discussion for another day)
2. Remove the elements from the template row, clone the row, and then
insert the elements back when needed. Drawbacks: hard to know where
exactly to insert these elements (generally this requires MORE id=
attributes added to the HTML to serve as a placeholder). Also this is
very hard to generalize: whether or not to insert these items back (or
remove them) depends on whether you removed them/ re-inserted the
elements previously. You could always put them back when you remove
them, but this is inefficient in cases where you have N adjacent rows,
all of which need the element removed.
I've settled on a third approach, which seems to be working well, and
I'd like to hear comments about:
3. I process the template row using the page.getElementXX() methods,
then clone it. If I want to remove an element, I do not remove it, but
rather assign a special value ('deleteme') to the elements name=
attribute.
I use a table to associate all items I've 'marked' in this way with
the template row object that I am about to clone. I created a function
that will clone the passed-in template row, and go thru the table
'resetting' the name attribute for all the nodes I had used
previously. Then, before rendering the page, I go thru the page and
getElementsByName('deleteme') and remove them.
This two-step mark & delete approach seems to work well. Of course it
clobbers the 'name' attributes in the process, but so far I haven’t
needed those on the elements I am deleting in this fashion.
I'd be curious to hear what others think of this approach.
--
David Michaels, Director of Web Engineering
PGP Corporation (650) 319-9009
--
Chris Webb
Voxsurf Ltd.
3rd Floor
Elme House
133 Long Acre
London WC2E 9DT
Tel. +44 (0) 20 7240 3621 x 206
Mob. +44 (0) 77 8639 2359
Fax. +44 (0) 20 7379 7573
e-mail : chris.webb@xxxxxxxxxxx
Voice Demo. +44 (0) 870 744 7223
http://www.voxsurf.com
Email disclaimer: This can be viewed at
http://www.voxsurf.com/disclaimer.html
| 