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; } } }

LSCS query for fetching the entire contents of the file

anisha

Hi All,

We are looking at leveraging LSCS in the best way possible for providing targeted content to the calling application.

With the knowledge I gathered so far, one of th approaches is to create DCRs with appropriate metadata and facilitate LSCS to deliver targeted content when the query is made using the metadata.

If we were to use this approach, it is my understanding that metadata based query needs to be made to get the resultant set and then parse the result set to provide the actual contents of the file based on document path or id. This approach seems to indicate that two requests (one for result set and another for actual contents) have to be made by the calling application to get the contents of the file.

Question:Is there a better way to fetch the contents within the file with one single request instead of multiple requests when calling application does not know the document path or id before hand.

Disclaimer : Longtime Legacy Teamsite customer/Developer. New to LSCS/LSDS world. Attended SitePublisher Component Development official training.

thank you!

Find more posts tagged with

Comments

Rick Poulin

anisha wrote:
Question:Is there a better way to fetch the contents within the file with one single request instead of multiple requests when calling application does not know the document path or id before hand.

No there isn't.

The reason is that LSCS doesn't know anything about the content format. If it was always XML, then it could combine it all into a single XML tree. But you can attach metadata to anything, not just DCRs. If you think about your result set containing files with binary data (e.g. image files), then it doesn't make sense to try putting that binary data within an XML tree, especially since things like video files or large PDFs would likely make the XML unparsable.

anisha

Makes sense. Thank you!

In that case, what would be the suggested best practice to fetch contents of the file via LSCS?

nipper

I was at a meeting with the PMs for TS/LS and made a request like this. So hopefully the feature will be added.

One thing you can condsider is that, if you are using LSDS to query LSCS, then LSDS has direct access to the DCRs on the disk. So you can make a query that says, give me all data with color=blue, and then instead of making 50 queries to LSCS for the actual DCR, you can grab them from docroot/templatedata because the information you receive will have docroot relative paths to the data.

nipper

anisha wrote:
Makes sense. Thank you!

In that case, what would be the suggested best practice to fetch contents of the file via LSCS?

I posted just after you posted. You can make an LSCS query but you may also have the data in the docroot and the path to it returned from LSCS. Your choice. Read from LSCS or read directly from disk once you know what you want to read.

Rick Poulin

Andy said "your choice", but really there's no practical reason to get file content through LSCS unless you're NOT also deploying those files to LSDS for some reason (and you'd need a pretty good reason). Local file system I/O will be several orders of magnitude faster than an LSCS call (HTTP + IDOL lookup + FS I/O), not to mention removing an unnecessary performance burden on the LSCS app.

nipper

The main reason I would do LSCS query is for the JSON transform, if you want the data in JSON instead of XML.

Though you can likely write an external for that too

Rick Poulin

JSON conversion doesn't work on content though, unless I'm not using the correct syntax...

anisha

rpoulin wrote:
Andy said "your choice", but really there's no practical reason to get file content through LSCS unless you're NOT also deploying those files to LSDS for some reason (and you'd need a pretty good reason). Local file system I/O will be several orders of magnitude faster than an LSCS call (HTTP + IDOL lookup + FS I/O), not to mention removing an unnecessary performance burden on the LSCS app.

Architecture team decided to go with single page architecture for the application and the application is going to be an Angular JS App. The app is going to make requests to LSCS instead of LSDS since LSDS gives html output and not just the content. With the way app is designed, Angular JS is going to control the layout, presentation, view etc and Livesite should be feeding just the content.

Probably it is not the best use of Livesite. HP was at on-site and made it clear. At this point everyone around is just trying to facilitate whatever Architecture wants to achieve Smiley Happy

anisha

rpoulin wrote:
JSON conversion doesn't work on content though, unless I'm not using the correct syntax...

rpoulin, you are right! JSON format or conversion is not applicable to content requests. To my knowledge it is only applicable to all LSCS requests, except for content requests.

Rick Poulin

anisha wrote:
At this point everyone around is just trying to facilitate whatever Architecture wants to achieve

Famous last words?

Before doing this, you should carefully consider the security implications of this model, especially if this is an internet site. Anybody with half-decent knowledge of web technology in general will be able to gain access to everything in your LSCS repo just by playing around with the queries. They can also hammer LSCS directly, which with the default performance tuning, would be quite bad.

On top of that, anybody with half-decent knowledge of LSCS can come in and DELETE YOUR REPOSITORY with almost zero effort, unless you perhaps remove the "projects" query handler altogether (I haven't tested this; and even then, you can't remove the document query so I could possibly delete documents one by one).

But I guess if you're going to ignore the vendor's direct advice, then you're probably not going to care much for mine either.

EDIT: to be clear, I'm not saying there's anything wrong with a single-page website getting data from LSCS. What I'm saying is that (IMHO) LSCS is not suitable for direct exposure to the internet. At the very least, you'd want to wrap it in a server-side application of some kind so you can strictly control the allowed operation set and the security around them. This may also apply to internal sites, depending on how much you trust your users.

anisha

rpoulin and nipper, thank you so much for the valuable inputs. I am still mulling through the available options...

anisha

rpoulin wrote:

EDIT: to be clear, I'm not saying there's anything wrong with a single-page website getting data from LSCS. What I'm saying is that (IMHO) LSCS is not suitable for direct exposure to the internet. At the very least, you'd want to wrap it in a server-side application of some kind so you can strictly control the allowed operation set and the security around them. This may also apply to internal sites, depending on how much you trust your users.

We will be using API gateway between SPA and LSCS to adress this.