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

Opinions please: Reading Configuration files from TeamSite Staging

SethHickel

I have a developer who has implemented the use of XML files to populate drop downs in a form. He calls a custom ipl to parse the xml and build the drop down. He uses this often.

My issue is that he is reading from TeamSite staging instead of deploying the files to some area on the server.

Am I alone in thinking that this is not a good solution: reading files from TeamSite staging to build forms in a template - or - should I not worry about it?

Thanks.

Find more posts tagged with

Comments

ccprofessional

...
Am I alone in thinking that this is not a good solution: reading files from TeamSite staging to build forms in a template - or - should I not worry about it?

Thanks.

Why do you think its not a good solution?

SethHickel

Because the TeamSite IFS volume is not intended to be used for serving files - content or configuration. TeamSite does not do this - any native configuration files are served off of the server and not from the IFS volume. I've not heard of any implementations that use custom configurations serving them out of the IFS volume.

That would be like accessing CVS for code instead of releasing it to a server.

Am I way off base on this?

msrinivas

I have always put such XML "lists" for drop downs etc., on the file system rather than on IFS. I manage them in TS and deploy them back to the file system of the same server. I personally think this is cleaner.I have seen implementation the other way too. Have not noticed any "issues".

HTH

Adam Stoller

Because the TeamSite IFS volume is not intended to be used for serving files - content or configuration. TeamSite does not do this - any native configuration files are served off of the server and not from the IFS volume. I've not heard of any implementations that use custom configurations serving them out of the IFS volume.

That would be like accessing CVS for code instead of releasing it to a server.

Am I way off base on this?

Well - doesn't the workflow instantiator read WFM configuration information from the /iwadmin/main/... branch's staging area?
I believe they're planning to do something similar with templating.cfg in a future version, and then there's all the SitePublisher stuff which is largely stored within the /iwadmin/main store and read from there.

So... I'm not sure it's that bad a solution - generally better to be reading it from staging than from a workarea.

SethHickel

Was that a statement?

If that is true then, even though I would prefer that the files be published out onto the server instead of getting served from staging, I probably should back off on my request for re-work on this implementation.

So - is it true that the the workflow instantiator reads WFM configuration information from the /iwadmin/main/... branch's staging area?

ccprofessional

Was that a statement?

So - is it true that the the workflow instantiator reads WFM configuration information from the /iwadmin/main/... branch's staging area?

Almost everything in sitepublisher works this way. Components, SP Templates, available_models.cfg, WFMs, etc.

SethHickel

Almost everything in sitepublisher works this way. Components, SP Templates, available_models.cfg, WFMs, etc.

OK - good to know - so based on this re-work will not be requested.

Thanks all.

nipper

No big deal. I expect the native file system would be faster. Some more permissions issues to work out, from iwmnt (possibly). But in the grand scheme of things he is doing the right thing and while one approach *might* be a bit better, I doubt there is a compelling reason to change from A to B. I happen to read them native out of the TS filesystem, mostly because I am lazy and then I do not need to deploy them.