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

DCR autogenerate approch

sanu

Hi All,

The users want the output file generated automatically when they click the Save or Finish button in the DCT. I have done this customization by overriding the Save and Finish buttons. Here the authors will specify the output file name from inside the DCT by using which the output file will be generated automatically.

Now the issue is when the output file path is renamed directly, when the user clicks on Save next time, the old path is used since the DCR item which contains the file path will not automatically change and will still generate the output file as per the old path. Is there a way to modify the DCR item to have a new path automatically whenever the output file is renamed?

Find more posts tagged with

Comments

Sarang

Which Save event have you overwritten?

sanu

I am using onSaveValid event

ISCBorisB

I am using onSaveValid event

Use IWPageGeneration.getOutputFile() to obtain the File and re-populate DCR Item in question

vpatel

Use IWPageGeneration.getOutputFile() to obtain the File and re-populate DCR Item in question

I am not sure if that will work Boris.

If I understand his issue correctly, lets say you have following DCR - /templatedata/some-cat/some-data-type/data/my-dcr.xml -- which created /htmls/my-dcr.html when it was generated initially. Now let's say that somebody goes in there and moves/renames this generated HTML to /htmls/my-dcr-101.html. Now when they edit and generate my-dcr.xml it'll still generate back to the original my-dcr.html and not my-dcr-101.html. I think that is the issue.

Potential solutions (depending on your exact requirements):
- Perhaps create and manage some sort of "dependency mapping".
- Perhaps make use of the iwat triggers (on rename event, set some EAs back on the original DCR or something).
- Perhaps don't allow users to edit or re-name these HTML files directly -- only way they can update it is if they make changes to the DCR itself. This is probably the easiest of the three.
- ....

HTH!

ISCBorisB

I am not sure if that will work Boris.

If I understand his issue correctly, lets say you have following DCR - /templatedata/some-cat/some-data-type/data/my-dcr.xml -- which created /htmls/my-dcr.html when it was generated initially. Now let's say that somebody goes in there and moves/renames this generated HTML to /htmls/my-dcr-101.html. Now when they edit and generate my-dcr.xml it'll still generate back to the original my-dcr.html and not my-dcr-101.html. I think that is the issue.

Potential solutions (depending on your exact requirements):
- Perhaps create and manage some sort of "dependency mapping".
- Perhaps make use of the iwat triggers (on rename event, set some EAs back on the original DCR or something).
- Perhaps don't allow users to edit or re-name these HTML files directly -- only way they can update it is if they make changes to the DCR itself. This is probably the easiest of the three.
- ....

HTH!

Perhaps not - in any case the scenario has not been clearly explained

He said "...the issue is when the output file path is renamed directly..." - whatever that means. I read it as the Path is kept
as a DCR's populated Item and somebody goes through the regular Generate GUI regardless. Typical GIGO

namithapai

Typically should'nt the output file always be regenerated and never directly renamed after generation? This means the extended attributes will also break.

How about put a process in place where to rename the file, they have to follow the dcr regeneration path?

Adam Stoller

Typically should'nt the output file always be regenerated and never directly renamed after generation? This means the extended attributes will also break.

The EAs on the generated file point back to the DCR - if you rename the generated file and leave the DCR alone - nothing should break (I don't consider it a good practice, but nothing should break)

How about put a process in place where to rename the file, they have to follow the dcr regeneration path?

My feeling is that DCRs and generated output files should use the same relative path and name - and that if you want to rename one, you need to rename the DCR, potentially change a value within the DCR from whence the name may [should] have been derived, generate a new output file, and delete (and submit) the old generated output file.

The whole thing should be programmatically handled - the less you leave for the users to do manually the better (IMO)