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

read all DCRs

nipper

OK, building a component to provide a list of pages (and DCRs) - index page of press releases.

2 issues.

The first should be pretty easy. How do I reference the path (templatedata/category/type/data/) in Java ? If I hard code it (iwmnt...), then it breaks when released to prod ?

The second is going to be uglier. How do I figure the URL of the .page if I only have the DCR? I do not think I can. So do I read the press release .page files ? How can I get the DCR so I can get the title, date etc ?

I am missing something obvious here, this cannot be that complex. Dropping it into a DB seems like the only other option, but we are trying to avoid that

Tips/Pointers/RTFMs greatly appreciated.

Find more posts tagged with

Comments

Binettoid

Hi Andy,
"Read" all DCRs? I know you're not new to TeamSite but are you a Perloid who is being forced to move on to the new version(s)? What you're asking is really basic but requires a radical change of thinking from the older versions of TeamSite.

If you are not using LSCS/LSDS as your transformation and/or public-facing display engine (whether via proxy or directly), then a large part of what TeamSite 7.x can do will not be available to you. It sounds like you are not, or are not familiar with this technology.

If you are using LiveSite Content Services, all of this easily obtained by querying it (LSCSQuery + OGNL). You might set up some Taxonomy and create a registry of EA-to-page relationships. All of this is alluded to in the SP Dev Guide. If programming Java to talk to the LiveSite API is not the way you are used to working, you may need some (re-)training. Kick your boss's backside now and demand the training course.

I cannot imagine this helps much, by the sound of your questions, but it IS rather complex to get your head around, especially if you are used to the 1 DCR = 1 generated page way of working. I have had Sun certified Java and grizzled Perl experts alike come and go without really getting to grips with the way this stuff works.

There is a lot of information on LSCSQuery on this forum. Good luck finding it.
PM me if you need more specific answers. CyberPop and others are also very good at this.

nipper

Certainly your assessments are correct. I am using LSDS and hate Java. LSCS is likely.

I will checkout the manual. I have been to 6.7.2 SP/LS training, but the 7.2 changes I am still learning.

Like I said, this should be pretty easy & I figure I was missing something. My plan of an external Java app to do all the work needs to be flushed out.

Binettoid

I'm not sure what the point of using 7.x is, unless you use LSCS. Possibly a great deal of money for nothing new. I guess part of the problem here is that nobody's **** sure what all these "components" are and where they sit, how they work together, etc.

If you want to get the best out of TS 7.x, your plan should try to leverage LSCS as much as possible. This still means building your Java app, but it is interwoven (haha) with what has been done by Autonomy (livesite API). I have seen large client installations (50,000+ DCRs) that simply use TS as a version-control system, on the other hand.

So, in your staging/development/preview mode server you have LSCS built in and can query it for EAs, etc. You build a Java app that uses the Livesite API to look up documents (XML DCRs. Forget pages. Pages & components are the new presentation templates) based on EAs, such as "ContentType" (a taxonomy type) or Title, Country, CreationDate, Owner or whatever.

When you deploy to "production" you will need an instance of LSCS (a cut-down version of IDOL) running, as well as LSDS (or possibly other servlet container), to achieve the same functionality.

This area is not well documented and you largely have to take apart some examples and rebuild for your purpose, but it is so much better structured and closer to design patterns than previous technologies that most of us will end up doing things the same (or similar) way.

I hope this helps. If you ever meet the guy (obviously an old-fashioned Perl guru) who customarily answered posts on this forum with "If you don't know how to do this, you should pay (me) someone who does", please point and laugh until he becomes insecure.

Ottawa_IWOV

I'm not sure what the point of using 7.x is, unless you use LSCS. Possibly a great deal of money for nothing new. I guess part of the problem here is that nobody's **** sure what all these "components" are and where they sit, how they work together, etc.

If you want to get the best out of TS 7.x, your plan should try to leverage LSCS as much as possible. This still means building your Java app, but it is interwoven (haha) with what has been done by Autonomy (livesite API). I have seen large client installations (50,000+ DCRs) that simply use TS as a version-control system, on the other hand.

So, in your staging/development/preview mode server you have LSCS built in and can query it for EAs, etc. You build a Java app that uses the Livesite API to look up documents (XML DCRs. Forget pages. Pages & components are the new presentation templates) based on EAs, such as "ContentType" (a taxonomy type) or Title, Country, CreationDate, Owner or whatever.

When you deploy to "production" you will need an instance of LSCS (a cut-down version of IDOL) running, as well as LSDS (or possibly other servlet container), to achieve the same functionality.

This area is not well documented and you largely have to take apart some examples and rebuild for your purpose, but it is so much better structured and closer to design patterns than previous technologies that most of us will end up doing things the same (or similar) way.

I hope this helps. If you ever meet the guy (obviously an old-fashioned Perl guru) who customarily answered posts on this forum with "If you don't know how to do this, you should pay (me) someone who does", please point and laugh until he becomes insecure.

One of the more informative and hilarious posts of I ever read on Devnet, and I have been reading this forum for a long time.

My struggles are exactly what has been mentioned on this thread. Autonomy (Interwoven) forcing customers to upgrade to the "latest and greatest", and assuming you go with LSDS and LSCS, a whole new way of doing things.

I have customers that hang onto 6.7.2 SP2 because they are not comfortable with the new world, mainly LSCS and the underlying mystery of IDOL. Anytime you rely on a search repository as your content/metadata storage layer for your DAO presentation services you are going to need require new experitise and skill sets (most likely), the North American marketplace is not crowded with seasonsed, IDOL/Java/XML/REST etc. resources who are freely available.

However, given the trend in the industry around cloud based apps, and storage paradigms like BigTable, Apache Hadoop etc., gaining some noSQL knowledge and working with IDOL is probably a good skill set to develop.

tec_iwov

you can use the the File that is accessable for the request context to get to the filesystem in an abstract way that works both in sitepub and livesite runtime. see getFileDal()

Bowker

First - sorry the this excessively long post. But I believe everything you need to do what you want is described here. There are other options but unless you want "browsers" to have direct access to your data, this is the best/only solution I have come up with.

Firstly - NO JAVA REQUIRED. (sorta - see note at the end about an external I needed to write.

Everything in LSDS is XSL and XML. Components are nothing more than small snipets of XSL code. XSL has a "document('url')" function that will read XML content from a remote source. One possible source is LSCS such as
[PHP]
[/PHP]
There may be an "easy" way to get the URL but I've not found it. (See further for documentation references.)

To build the URL for LSCS:
1) http://ut81501:1876/lscs/admin/debugpanel/
2) expand "admin" Choose "list project names" & copy the name attribute for the project you want to search.
3) Expand "document retrieval" choose "document query"
4) paste the project name into the project
5) put * in the the query

The bottom frame will display a search result. Right click on the frame and select properties.
You will get something like this:
http://ut81501:1876/lscs/v1/document?project=//SDCPWSU02/default/main/SP&start=0&max=100&q=*

Copy it and put a $* (yes dollar star) before the ? and paste it in a new browser window.
http://ut81501:1876/lscs/v1/document$*?project=//SDCPWSU02/default/main/SP&start=0&max=100&q=*

You will get back the same list but with all the searchable fields for that file. In my case I wanted to find all (or at least the first 100) the DCRs with "bowker" in the title field.
http://ut81501:1876/lscs/v1/document$*?project=//SDCPWSU02/default/main/SP&start=0&max=100&q=TeamSite/Metadata/Title:bowker

One of the attributes of the document tag returned is a uri. In my case it was: uri="/document/id/2e5c7bdb9a89b330f386630a9f6d7e22". That URI can then be used to get the content by stripping the search URL and appending the returned URI, such as:
http://ut81501:1876/lscs/v1/document/id/2e5c7bdb9a89b330f386630a9f6d7e22

That last URL can be used in a separate xsl...document() call to get the content from the DCR.

In a nutshell - this is what I plan on doing (unless someone has a better idea.)

[PHP]

Phone number for is...
[/PHP]

In your case, looking for all the press releases you probably would use: (some assumptions made about your Press Release content)
[PHP]

[/PHP]

The hardest part is building the search URL. I've build an include XSL that takes some parameters, builds the url and returns it.

Here's where I'm stuck (sorta)
How do I get the parameter (?pr=@uri) on the built page. The parameters are not available natively to components. So if you pass in a DCR URI, how can the component get that URI to get the contents from the server? My solution was to write an "external" that will take all the parameters from the URL and put them in the XML used by the component.

Documentation
As their documentation goes, this is about middle of the road - not too bad, but difficult to interpret unless you understand what you're doing.
"LiveSite Content Services Technical Reference Guide Version 7.1 rev 1 Dec 2009" You will find it in the 7.1 docs not in the 7.2 docs since there isn't an updated version for 7.2.

I can give you some historical details on all of this if you care - send me a private message and I'll fill you in.

Binettoid

I see what you're doing here Dan, but I find your post highly confusing and I'm guessing others will too.

Why do this? Of course you can do some heavy XSLT processing to construct REST queries and then do more to render the result, but you will never have the kind of power in XSL that you have in Java to manipulate the data. You may also run into self-imposed problems with the execution order of things.

What problem does this solve? You should describe why you took this approach and why it is better/different from the standard approach. Do you not like Java or have some (e.g. organizational policy) problems accessing the Java tools on your platform? I'm not knocking your overall assertion that a lot of what is needed can be accomplished without writing Java classes but your NO JAVA caveat - except for the bit that solved the problem with your approach - is bizarre.

Some of the statements you make do not make much sense to me, either because you are generalising too much or because your a talking about your problem/solution and not the platform as a whole. If you explained your approach better, there might be some real value in here. While 'Components are nothing more than small snipets of XSL code.', they can reference other things, including Java classes, or contain .Net controls, so this statement is not that helpful.

This post could be really useful to someone, highlights some of the key mechanisms of LSCS in particular, and deserves to be a little better explained.

Bowker

Interesting comments.

To answer a few of your questions - why not Java? Three reasons:
1) Corporate policy of implementing Java changes is challenging at best. If you want details PM me and I'll fill you in, but think "Sarbanes-Oxley" and risk mitigation.
2) Skill set required. Writing good Java code (tough to define that I know) requires a skill set that's different from XSL.
3) Time to market. I can implement (code, test, deploy and use) a solution to produce a "dynamic page" that utilizes search results in less than hour with zero down time. No restarts required nor anything more than creating a new component, page and deploy it.

If you, or others, find my post confusing, I apologize. Let me simplify it. with this. To post all press releases one could do this:

[PHP]

[/PHP]
In my humble opinion this is far better than creating a separate Java class to do the same thing. If you are worried about speed, I contend that +90% of the time spent during runtime is actually doing the rest call to LSCS. Xalan, although an older version, is still pretty quick and the insignificant fraction of a second gained by not doing it this way is FAR out weighed by the care and feeding of any Java code.

As a note - I could have posted "yea - you can do it all in XSL" and be done with it. Not very useful.

I hope this clears up some questions and explains why I would, did and will continue to build pages of this type this way.

nipper

I, for one, appreciated Dan's post. Java development is on of the huge issues with LSDS (IHMO). Not that you need Java, but that you need to rebuild the TS GUI to test, you need to deploy a JAR and restart the application server in production (across the firewall). Having worked in environments that are PCI compliant (able to handle credit cards), there is a huge difference between Code (Java) and markup (XSL)

Frederik

@Dan. Interesting approach.

Purely out of curiosity... can you also sort the list?

PS / FYI
I see you use the default project name in lscs url, which is the full branch name (thanks IWOV for forcing the hostname into that :rolleyes: )
?project=//SDCPWSU02/default/main/SP

You can define a simple project alias in LiveSiteCSAuth\authoring\etc\deployment\config\lscs-authoring.xml file. That way your code is more portable (no server-based vpath => use project alias). All content needs to be redeployed though. The conf only applies to subsequent deployments.

example
[HTML]

[/HTML]

nipper

Fredo - I have seen XSLT sort templates before. It should be possible to put that into the XSLT Dan provided.