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

Alternate to extending data model in 7.1

msrinivas

It appears that the SitePub data model extension that was available in 6.7.2 is no longer available/applicable to 7.1. Is that correct and what is an alternate approach to achieve some of the same functionality?

TIA!

Find more posts tagged with

Comments

Migrateduser

I suppose that depends on what functionality you mean. We have been working on using LSCS, I believe it accomplishes the same goal. That said it has been an interesting ride and I think you can still extend the data model.

test_digits.rptdesign

vpatel

Srini: what is the use case? What you trying to achieve?

HtmlInReport.zip

msrinivas

Essentially we have product information like features and specifications of the products that we are trying to normalize. We want to be able to build a component that is able to do compares between product features of various products. Hope that makes sense.

Migrateduser

If you look at page 347 of the SP 7.1 Dev Guide, you'll find the instructions you are looking for. I'm not convinced that LSCS as currently constructed provides answers for the same use cases. For one thing, it seems like there are instances where one could use ICE for content that one was then inserting into the data model and surfacing in other areas, but one currently cannot do ICE if LSCS is involved (my understanding from talking to a couple of folks in the engineering team is that a solution for that is under active development).

I'm going to be posting a separate thread on this in a bit, with one of my use cases. I think it can be addressed by extending the data model, but the documentation actually seems a little thin where the taxonomy is concerned.

msrinivas

On the same page 347 it says that the section is there for backward compatibility and applies to versions prior to 7.1. That is what threw me into a loop.

test_crosstab.rptdesign

vpatel

Basically pre-7.x, LS (now known as LSDS) deployed the taxonomy, basic asset info, metadata, etc. into a DB. That was on OOTB DB schema dictated by LSDS. In order to meet client specific requirements there was a need to extend that data model and map your content to that DB and / or a totally new DB and still have LS still able to talk to it.

As you can see, this was a fairly involved process. Starting from 7.x, LS was split into LSDS + LSCS. LSCS addresses exactly that need. You don't need to extend the data model or anything. You can set any EA and that'll be automatically available for you to do lookup against, do compariosons against, to filter against, to render, etc. The key here is to move away from the cumbersome process of extending data model (update DCTs, write additional Spring configs, write additional Java beans, write addiitional hibernate -- other orm -- mapping files, etc) to simply capturing relevant fields/metadata. LSCS simplifies this cumbersome process and having to wait for build cycles.

In any case, if you still have a need to have a DB, you can go ahead and build a custom data model with a corresponding DB.

HTH

Migrateduser

That's a pretty important sentence that I overlooked. I guess maybe they are trying to push this sort of thing over to LSCS. I'm going to open a support ticket to try to get an answer for that since it potentially impacts a design I am doing.

Migrateduser

The support tech who responded to my case said that data model extension is definitely still supported. I've replied back asking for clarification on why the developer guide says that the info is for backwards compatibility purposes only. I'll let you know more as I find it out.

Update:
Ah - I missed Viral's post that happened at the same time as mine.