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

TPL sets EAs

System

I didn't write it and I'm not going to comment on or change the logic, but the TPLs here set extended attributes on the files they are generating. Of course this fails for new files and for preview as the files that it's trying to set extended attributes on don't exist. What would you do to get around this?

Find more posts tagged with

Comments

lhdavis

Modify the TPL logic to NOT generate extended attributes if it is preview or if the file DNE.

Since it fails for new files because it is trying to set the extended attribute value before it has generated the file, maybe create and schedule a batch process to regenerate any of these filetypes which will insert the extended attributes (since the file exists now).

Just one possible approach...

Luke Davis
Open Technology Group, Inc.
luke.davis@med.va.gov

Adam Stoller

If you're not going to change the logic and there's a flaw in that logic - what exactly are you expecting us to suggest?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

If you were going to change the logic, what would you do. For instance is it possible to flush the buffer/write the file from within the TPL, then set attributes.

Adam Stoller

If you're using iw_ostream or Perl's open()/close() routines - certainly that would work.

My questions would be based more around why these EAs are being set by the PT and whether there's any other way of providing the functionality (e.g., if the files are generated within the context of a workflow, follow the generation step with additional code to set the EAs).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Funny thing - users have never been able to preview here because of this and other bugs. So they always generate. The problem with this is that they sometimes select the wrong output file when they generate, which overwrites something else and causes a big mess. I would prefer to have them preview if possible. But...

When I added the code to not set attributes if the output file doesn't exist I noticed that the left nav doesn't work correctly in preview. Left nav is generated based on the directory the output file is in, which works for generate but not fore preview when the output file is in templatedata/iw_preview). Wondering what people do about that case as well.

We do have a scheduled regeneration process, but that's another whole can of worms because it takes from staging to a temp workarea, regens, submits, then can't update the other workarea(s) with the updates since there may be other changes in progress in those areas, which causes workflow submit conflicts...

"I walk through minefields." - The Prodigy

Migrateduser

> If you're using iw_ostream or Perl's open()/close() routines - certainly that would work.

Nope, just using iwpt_output, iw_include, inline'd html, etc. It's like a 1997 implementation (all static HTML including left nav). There's no way to flush the default buffer and write the file from within the TPL?

> My questions would be based more around why these EAs are being set by the PT and whether there's any other way of providing the functionality

Dude, I have no clue, it's kindof a joke. More and more I see less and less need for extended attributes - I would rather store that data in the XML itself so it's available to any system/process, regardless of wether an output file exists or not (hey, in this case I guess I could set the attribs on the DCR, which does exist, and any proc that needs that value could retrieve EA pointing to DCR and get other attributes from DCR, but who knows how much code that would impact). Plus, why store a value that can be calculated (I think that was one of the first rules in CIS 350, right after don't store multiple values in a single entity/attribute) - if the TPL can figure out the value to set, then so should any process that needs that value - logic should be in a module, not a TPL/attribute. But I can't make significant changes to DCTs, TPLs, workflow, etc. - I just want to reduce my admin burden until we can scrap the system.

Adam Stoller

How about this - in the PT - put some iw_perl code near the beginning that determines the name of the output file and ensures the file exists - something like:<iw_perl>
my $ofile = iwpt_get_ofile_name();
if (! -f $ofile){
if (open(OUT, ">$ofile")){
close(OUT);
}
else {
# log an error somewhere?
}
}
</iw_perl>That way there will be a file to set EAs on regardless of whether the actual contents of the file have been flushed out yet. Note, you might have to play with the value of $ofile a bit to make sure it represents a file system path and not a vpath.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

I can give it a try, but wouldn't my trying to write the file at the same time that iwpt_compile is trying to write the file cause a conflict?

iwovGraduate

Left nav is generated based on the directory the output file is in, which works for generate but not fore preview when the output file is in templatedata/iw_preview). Wondering what people do about that case as well.

Why can't you change the preview dir to where you need to generate ? I guess you are using the same DCT/PT combination to generate files to different directories ?

TOC_report.rptdesign

nipper

>I can give it a try, but wouldn't my trying to write the file at the same time that iwpt_compile is trying to write the file cause a conflict?

It should not. From what you have said, it sould like the file is not open when the iwpt_compile is running. Worth a shot.

Andy

iwovGraduate

How exactly are you setting the ext attr from your PT ? I have done this in the past (something similar to what ghoti posted), never had issues.

Migrateduser

Using system call to invoke iwextattr.

Migrateduser

> Why can't you change the preview dir to where you need to generate ? I guess you are using the same DCT/PT combination to generate files to different directories ?

Yes. Plus, couldn't the temp files get submitted and deployed if they were in the real content directories?

iwovGraduate

Yes. Plus, couldn't the temp files get submitted and deployed if they were in the real content directories?

ok, as far as I know you can (and have to) specify only one preview directory in templating.cfg.

No, preview files created by templating should not be submitted.
I don't think it evern shows up in the UI for users to select and submit. If you still want to prevent it IWOV engineers have created something called autoprivate.cfg Smiley Happy