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

Can LSCS queried results display the fields in a dcr?

System

LS 7.1

I have a need to display a list of related facilities. One of the things that needs to be in the list is the facility phone number. The phone number is part of the dcr not the metadata.

This will give me the document list:
http://lspreview:8080/lscs/v1/document?q=TeamSite/Metadata/stafflocationid:=6,114

but there is no data in the document elements:

[HTML]

[/HTML]

Any ideas?

Find more posts tagged with

Comments

vpatel

Easiest way to get this is to set whatever fields/items you want to query upon as EAs on that DCR. Which version of LSCS are you on?

Rick Poulin

vpatel has the ideal solution, but in case that's not possible for you for whatever reason, you can always use that list to then query each record individually.

Looks like your query is returning page files which contradicts your desire for DCR results, but in any case.. you can access the original file content (and thus the XML of your DCR or page) via a query like this:

http://lspreview:8080/lscs/v1/document/path/sites/www/location/belton.page

Migrateduser

We are on LSCS 7.1.

So what ramifications would that have on in-context-editing? We already have a lot of content entered the way it is, changing these fields over to ea's through the tagui would require double entry so that is not a good option. I suppose we could add them to the extended attributes using formapi and some custom code. That or the external will have to do a look up for each document and build out the xml we need. The fear there is it would be inefficient.

Rick Poulin

Don't do double-entry. The suggestion is to have a task in your workflow that extracts the required content from your page/dcr and sets/updates the value of the EA prior to your deployment task.

Migrateduser

If we add a task to the work flow then each dcr we need to do this with would require some nasty maintenance in the task. To start spit balling some solutions I am thinking of a couple ways to get around updating and deploying the code for the task every time a new dcr is added or a new field is identified as being needed as part of the metadata.
- We could use a naming convention on the fields. What impact would renaming fields in the dcr have, besides the obvious impact to the xsl that already refrences it?

- A configuration file could be maintained with the fields per dcr we want to do this for. This 'feels' like the best idea.

- All dcr fields can be added to the extended attributes. This seems the easiest but something does not feel right about it.

thoughts

Rick Poulin

I'd suggest that if it's going to be a few text fields, then your config file is probably the way to go. If it's going to require large blobs of HTML or any content that is larger than 4096 characters (EA limitation, if I remember correctly), then you'd probably want the option I suggested above, where your Java external queries every document in the results one by one and extracts the content you need.

Migrateduser

Thanks, I will probably go with the external for now and if the performance becomes an issue then look into creating a task for it. The workflow task can wait for when we have time or need for that.

Thanks