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

setting <browser> to browse another workarea

PaulD

Please Help.

I have a customer that plans on importing ~5GB of images and attachments into TeamSite. Users will add these images and attachments to content via a template.

My initial thought was that I could place these images and attachments in one place and use a "browser" template element to choose them. But the initial-dir tag limits me to the current workarea.

So then I thought that I would import the files into a workarea, submit them to STAGING, and then do GetLatest to all 13 other workareas. But... how does this fancy file system handle this? Would I have just used 65GB of dasd? (I only have 60 so naturally I'm concerned)

How are others handling this? Can I "browser" outside the workarea? Will I be wasting dasd?

thanks in advance,
Paul Dailey
IBM, IGS IWOV COMP

Find more posts tagged with

Comments

Johnny

There have been a few posts about this very issue.
If you do a search you may find more info and I think a CGI callout that works around this.

Few people seem to have done this with cgi callouts.

You could also use symbolic links (available on win2k in resource kit).

John Cuiuli
Consultant
Sydney, Australia

PaulD

Thanks for the reply. I did see those posts and the gentleman who created the CGI for this stated he had sent the code to Interwoven so they would create a Tech Note. I could not find that tech note. Would you happen to know the number?

Otherwise the symbolic link idea is a great one. What would be the implications? Can a symlink be submitted to staging? What does Interwoven feel about this?

Also, I am curious about the space impact I commented on previously. Would I really be consuming 65GB of space?

PaulD

I created a symlink in the dir I have "initial-dir" set to, browsed to the directory and nothing appeared in the "browser" window where the filelist normally is. Using telnet, I could cd to the symlink and see the filelist.
When you mean create symlinks, do you mean to files? This seems to work but is high maintenance if users are importing attachments and images.

Thanks!
Paul

Adam Stoller

(a) I recommend against using symlinks within TeamSite - they cause far more problems than they solve.
(b) The amount of space used in the backing store is related to the number of versions of files in the backing store.
If you have a 10 Gb image (foo.jsp) and you submit it for the first time into TeamSite from /default/main/www/WORKAREA/wa1 - you will have used up 10 Gb of diskspace in the backing store (perhaps a bit more, but not much).
If you then do a GetLatest for the other 9 workareas on that branch - you will now have used up 10 Gb of diskspace in the backing store NOT 100 Gb
If you edit the image and submit it - then you have a copy of both the original and the modified file in the backing store - so assume roughly 20 Gb of space, etc.

--fish
(Interwoven Senior Technical Consultant)

Johnny

OOps... I dont like recomending bad ideas Smiley Happy

Sorry!

Can you tell us what problems you have seen with sym links?..
They are part of the TS file system and Ive used them before with no ill effect.
I would be keen to hear about what problems I should look out for.

Thanks

John Cuiuli
Consultant
Sydney, Australia

gzevin

John,

actually symlinks in Windows (junctions) don't seem to have been implemented in TeamSite anyway. at least it was the case when I asked this question to Engineering when I was with IWOV...

Greg Zevin
Independent Interwoven Consultant/Architect
Sydney, AU

PaulD

Thanks for the posts.

It appears there can be two directions:
1) submitting the binaries to staging where assuming we need dasd roughly 2x the amount of binaries, or
2) Find this mysterious CGI script that is now a tech note and allow the users to "browser" to another workarea. (Actually, this is what the customer wants since this way they dont have to update workareas).

Adam Stoller

[side-thread: symlinks]

Symbolic links can cause all sorts of confusion:

If a directory is symbolically linked, then processes that rely on relative pathing (../..) may break because once you enter that directory, ../, is no longer pointing to the location from which you started.
If a file is symbolically linked, I do not believe that operations related to that file will necessarily work (submitting, viewing history, reverting, etc.), as these operations where designed to work with actual files and not symbolic links

If I'm looking at a file in my workarea that's symbolically linked to a file in your workarea and I manage to view history on it and then try to revert it to a previous version... what should happen?
- Should the symbolic link be broken, and I end up with a copy of the actual version of the file (from the other location) in my workarea? [how?]
- Should the symbolic link be preserved, and the file in your workarea be reverted based on my request in my workarea? [what happens if I don't have write access in your workarea?]
If a file or directory is symbolically linked to a location outside of TeamSite - what happens then?
- How should TeamSite behave if I try to submit a symbolic link?
- If it cannot do it - how do we inform the user in such a way that they don't become even more confused?
- What happens to the entire concept of edition-based reproducibility of content?
Note: if you suggest TeamSite break the symbolic link by copying the content into the current location at the time of the operation, what happens the next time someone changes the content in the location of the original source of the symbolic link?

There are probably other concerns as well - but I think the above are enough to generally recommend against the use of symbolic links in any version management product.

Symbolic links are a convenience that's very nice for things that aren't being version controlled and/or are only being accessed in a read-only capacity - but once you get beyond that level of usage, their usefulness needs to be balanced with the complexities they add.

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

Hi Paul,

Could you find the CGI script to browse other workareas?
I also have a similar requirement and am looking for the CGI.

Thanks in advance.

-Ashish

hemranga

hey i have the code which does this...i have a component which browses any workarea...and that too it is configurable for any of the brances and also File types. Let me know if you guys need and i willpost it.
My Id : hemanth.r@itcinfotech.com

Migrateduser

Hi Ranga,
Can you please post the cgi here?

Thanks
-Ashish
(ashish_deshpande@hotmail.com)

jaybee

Hey Ranga .. can we get the code here?

hasel

can you pleas post me the code?

seeDerekNow

Yea - Can somebody please post that script? I can't find it anywhere.

Derek

gzevin

what wonders me is that even in TS6 IWOV has not provided this callout. Something is definitely missing at the place where they keep their whiteboard with designs.... I still cannot understand it. I was screaming about this when I was with them...

anyway - whoever wants this script, please message me. I simply prefer to count the number of companies using my script Smiley Happy

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

I'm working with the script now and the code is pretty bad. I may just have an obsolete version, but based on what I have I would suggest just writing your own.

seeDerekNow

Hi Greg - if you could send me the script (derek.kim@wellpoint.com), that would be great.

Derek

gzevin

I dunno which code you have. The one that I have written is not perfect (as initially it had to be written in a matter of a day or two), but is very robust after some changes we made ....

I saw some modifications to it so it was reskinned to look almost like Webdesk ...

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Hi Greg,

I strongly agree with you, the missing abillity to browse other workareas from the <browse> button is sertainly a lack in TeamSite. At least IWOV could have enabled proxy settings for this feature.

I would be very happy if you would forward your scripts to me as well

Kind Regards
Per Staffe
H. Lundbeck A/S, Ottiliavej 7-9 DK2500 Valby

Adam Stoller

I think it's a question of how-much-rope you provide users to hang-themselves with. There are certainly scenarios where being able to browse to another area inside of TeamSite (or even outside of TeamSite) makes sense, but there are also plenty of scenarios where doing so will lead into an operation failing further down the line - for apparent confusing reasons.

I think it's someting that should be configurable in the browse element itself - so that it leaves the decision in the hands of the local developers.

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

gzevin

Adam,

one of the benefits one has in TeamSite (and one of selling points) is the ability to place all the images in one branch (sub-branch) and do proxy failovers, so a lot of space is preserved, and graphic designers could also work in one place. This is what PaulD is talking about

So this functionality has never been supported by an appropriate OOTB callout or <browser> itself. This is why file browser callouts have been so popular. The one I've written has been used in dozens of accounts I believe. I'd say if IWOV made the <browser> configurable, this would be the best outcome.

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

gzevin

staffe,

could you message me with your e-mail address?

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Johnny

I think another strong point for this is ensuring users select approved content that already exists.

There is no garantee a file selected in a workarea has been submitted and deployed, meaning extra work to figure these points out.

It is appropriate in these situations to select files out of the STAGING area instead of the workarea.

So the configurable option would work well here too.

John Cuiuli

Migrateduser

Sorry Greg,

After all these years I'm still not a computer - or I have some bad sectors on my memory chip.

My e-mail is prs@lundbeck.com - sorry for the inconvenience