I think the way to go may be to just set both qname and localname to "fid"
- it doesn't seem like that would hurt anyone, and seems like it would get
things working on your implementation as well. How about you try that
out, and if it works submit a patch for the places where it just does one,
and we can apply it.
best regards,
Chris
On Fri, 16 Sep 2005, Cole Markham wrote:
> I finally had a chnace to step through and see what is happening. Here's
> what I can see.
> This method is in FilterTransformer, lines 137-145 (Geotools 2.1RC1):
>
> public void visit(org.geotools.filter.FidFilter filter) {
> String[] fids = filter.getFids();
>
> for (int i = 0; i < fids.length; i++) {
> AttributesImpl atts = new AttributesImpl();
> atts.addAttribute("", "fid", "", "", fids[i]);
> element("FeatureId",null,atts);
> }
> }
>
> The addAttribute method in AttributesImpl looks like this:
>
> public void addAttribute (String uri, String localName, String qName,
> String type, String value)
> {
> ensureCapacity(length+1);
> data[length*5] = uri;
> data[length*5+1] = localName;
> data[length*5+2] = qName;
> data[length*5+3] = type;
> data[length*5+4] = value;
> length++;
> }
>
> So, localName is set to "fid" and qName is set to "".
>
> Then, the next part looks to be dependent on my installation.
> com.sun.org.apache.xml.internal.serializer.ToStream.processAttributes(
> java.io.Writer writer, int nAttrs) is getting only the qName and writing
> that to output.
>
> public void processAttributes(java.io.Writer writer, int nAttrs) throws
> IOException, SAXException
> {
> /* real SAX attributes are not passed in, so process the
> * attributes that were collected after the startElement call.
> * _attribVector is a "cheap" list for Stream serializer output
> * accumulated over a series of calls to attribute(name,value)
> */
>
> String encoding = getEncoding();
> for (int i = 0; i < nAttrs; i++)
> {
> // elementAt is JDK 1.1.8
> final String name = m_attributes.getQName(i);
> final String value = m_attributes.getValue(i);
> writer.write(' ');
> writer.write(name);
> writer.write("=\"");
> writeAttrString(writer, value, encoding);
> writer.write('\"');
> }
> }
>
> So the problem seems to be that there is some miscommunication about which
> name the XML writer should be using. This would explain why it might not
> happen on other platforms with a different implementation of the XML writer.
> I don't know if there is some setting somewhere that specifies whether to
> use the local name or the qualified name for attributes. Is there something
> that can be set to specify the correct behavior?
>
> I switched to using GeometryFilters, so the problem went away because it
> doesn't use attributes, it uses content. In fact I am not sure whye
> FidFilter uses attributes, because it seems to be one of the only ones that
> does. The other one that I see in FilterTransformer that might have a
> similar problem with attributes is LikeFilter. It also only specifies the
> local name. FunctionExpression actually specifies the local name and qname
> to be the same, so it should work.
>
> Thanks,
>
> Cole
>
>
> On 9/9/05, Chris Holmes <[EMAIL PROTECTED]> wrote:
> >
> > Do you know what class is being used to generate the XML? Is it
> > SLDTransformer and FilterTransformer? It seems really weird if that's
> > not generating it right, since it's a SAX producer, which makes it hard
> > to just not include the attribute name. Maybe it has to do with the
> > SAX implementation you're using? Regardless, this is an odd problem.
> > All the other attributes get generated correctly? I checked the code
> > and all looks fine.
> >
> > Chris
> >
> > Quoting Cole Markham <[EMAIL PROTECTED]>:
> >
> > > I ran across a bug while trying to create FidFilters in uDig. The
> > > Filter
> > > gets created and applyed to the Style and everything works fine until
> > > the
> > > Style is recreated from XML.
> > >
> > > The FidFilter element doesn't get the attribute name (I assume fid)
> > > written.
> > > The following snippet from the generated xml document shows the
> > > problem.
> > >
> > > <sld:Rule>
> > > <sld:Name>name</sld:Name>
> > > <sld:Abstract>Abstract</sld:Abstract>
> > > <sld:Title>title</sld:Title>
> > > <ogc:Filter>
> > > <ogc:Or>
> > > <ogc:FeatureId ="structure_existing_area.1551"/>
> > > <ogc:FeatureId ="structure_existing_area.1254"/>
> > > </ogc:Or>
> > > </ogc:Filter>
> > > ......
> > > <sld:Rule>
> > >
> > > The remainder of the file appears to be ok. I tried to trace the
> > > problem,
> > > but I don't understand the xml encoder well enough.
> > >
> > > I switched to using GeometryFilters for now, and they are working
> > > fine.
> > > Hopefully this can get fixed for the next version.
> > >
> > > Thanks,
> > > Cole Markham
> > >
> >
> >
> >
> >
> > ----------------------------------------------------------
> > This mail sent through IMP: https://webmail.limegroup.com/
> >
>
--
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
