Thread: rev.categories C# file

What is the name of the C# file that generates the rev.categories.xml.config file?

I am trying to query a specific column on the category table which will then be returned as part of a css class on the menu element.

<li>
<xsl:attribute name="class">
<xsl:value-of select="aspdnsf:GetMLValue(CSSClass)"/>
</xsl:attribute>

fields like SEName and Name work in place of CSSClass so I need to build this particular into the query that is used to generate the file.

All help is appreciated...

That's actually just a standard file that exists on your site - Web\skins\Skin_1\XmlPackages\rev.categories.xml.co nfig

so there is nothing in the background that creates the query for the page? how come most of the column names that are in the category table don't return data when substituted in my xsl:attribute? SEName and Name work but categoryid which is used elsewhere on the page doesn't?

or does this page query any other tables in the database??

Thanks

the rev XML Packages are unique among our other XML Packages in that they use the Entity Helpers rather than a package embedded query. The entity objects themselves are somewhat contextually agnostic, so the EntityID is probably the information for which you're looking.

Dusty
ASPDotNetStorefront Staff

so how would I go about editing the EntityID data so that I can choose any table column to display as my css class? I see the path root/entityhelpers/category/entity but I dont have the entityhelpers folder to find this file. I do have entityhelper (no 's').

If you look at the top of the rev.categories.xml.config xmlpackage in the package tag, you'll see includeentityhelper="true". Any xmlpackage with this will include entityhelper information in the xmlpackage (you can see the entity helper xml if you set debug="true" in the package). This hierarchical data is a bit complex, as well as heavily used within the application, and is assembled in the AspDotNetStorefrontCore project in the EntityHelper and HierarchicalTableMgr classes. You'll need the source code to modify these classes, and any changes will require a recompile in Visual Studio to take effect.

we don't return ALL table fields in the entity helper data, due to their size, and for performance, but if the field is there (see George's debug hint so you can see the raw data you have to transform off of) then you can just pull it, otherwise, you may have to just add a new db query node to your xmlpackage, picking off the entitiy ID on querystring, and pulling that field out, which would then be available also in the XML doc directly of the transform.

In other words, an XmlPackage can execute multiple queries in it if it needs to the DB.

Ta very much for the help. the debugging let me see a number of fields I could use as a substitute to achieve what I needed.

not perfect but it does the job at least...

ta!