nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

best practices for component development

rohit34582

Hi Livesite gurus,

I'm building a component using the livesite sitemap external and my own appearance xsl.

However as my requirement is pretty complex i.e different tabs appear on the component depending upon the page it's placed upon...

I've built it completely by manipulating the xsl... however my concern is should i have done all the manipulation in terms of xpath in a custom java class by writing utility methods and using that in my component or is xsl a better approach?...

Given a scenario what would be the first thought that should come to a component developers mind..xsl or java...

Which is less memory consuming?

Pls advice....

Thanks in advance....

Find more posts tagged with

Comments

Stokes

Keep in mind that the xhtml output of your component XSL will be cached for each page, so performance won't be a factor after the first page hit.

So I wouldn't do filtering or transformation in Java for performance alone.

Stokes.

nestedcrosstab.zip

rohit34582

Are there any generic scenarios when I should filter the xml using Java?

I was wondering about this because when my page changes(when the user clicks a link) and I'm using java to filter the xml the class file has to get executed every time the page gets loaded and then the xsl transformation has to get executed...

Since transformation is also handled by java am I correct in assuming that transformation is more memory intensive and therefore I should limit my xsl logic to the minimum and use java to leverage xml filtering...

Stokes

You're probably right about the transformation being memory (and CPU) intensive. And you're right that simply pairing down the XML in Java would help with performance.

However, I think it's not a best practice to fix performance problems prematurely before you know you have a performance problem. (("We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." --Donald Knuth))

The case I can imagine where performance might be an issue is where the component, for some other reason, isn't cachable. The caching strategy is part of the component's properties, and if it must be set to "do no cache" (a last resort) then yes, I think using the External class to limit the XML and reduce the XSL translation effort would help.