TeamSite and .NET integration/best practices?

does anyone have any experience/white papers on TeamSite integration w/ .NET/C#? i did a search and all i found was that you can gain access to the TeamSite repository and workflow engine via .Net calls, but this would have to be customized on our end. and that there is anything currently available from Interwoven. i know there are plugins for BEA and websphere...

any help would be greatly appreciated! thanks in advance

Find more posts tagged with

Comments

Dima

We are using .master files generated by Teamsite with ContentPlaceHolder .Net tag.

nipper

There are a lot of people who use .Net in TS. My current project is as well.

There is a KB 49749 that talks about virtualizing .Net in TS, it is a pain. Also, do not mess with the passwords for TSIMP_host or IUSR_host (my company requires real passwords for those), that has screwed up virtualization from templates.

Finally, if you are using templates (we create aspx and ascx files from a template) I wrote a WP that talks about preview complexities. You can search the tech lib for it.

HTH

Andy

Migrateduser

very good feedback guys - thanks - we are having some issues w/ preview and .NET, especially with visualannotate. after a user clicks "Save" the page totally breaks Smiley Sad

Andy - more importantly, how are you generating your aspx and ascx files from the template? the only way ive seen is w/ perl (which i am definitely not crazy about) - is there a better (supported) way? both consultants ive worked with are using perl Smiley Sad

nipper

Yes use Perl, you do not have much of a choice, you will also use iw_ostream.

kvargas23

Nipper quickie question, do yo happen to know tech library article ID? I searched all through the library and couldn't find anything related to preview.

arthas746? Were doing a similar thing here. And in my last company we also built out an asp.net based website with a 150 sub-branches but had to copy all the .net related stuff (dlls, web.config, master pages, etc) to each branch to get it preview. A bit of a headache to manage , but it did work nicely.

Also, anyone know a better way to organize your .net code for an aspx based website when you got hundreds of sub-branches?

thanks,
Keith

nipper

This is the one I wrote: 59207

KristerS

The consultants I'm working with are using templates to generate our ASPX files. We've got master pages for the overall look and feel and the generated ASPX files contain the content and HTML to fill in the ContentPlaceHolder pieces of the master pages.

It seems that generating the aspx files with the content in them doesn't exactly separate content from presentation. Is there a better way to pull the CMS content from inside our aspx's (like I think JSR 170 indicates in the Java world and the Java connections to CMS do), or are we best off just generating the ASPXs from templates?

If we are best off generating the ASPXs, then I guess we'd also be best off ensuring our templates/ASPXs are concise and generate mostly content and not much else, right?

I hope this makes sense.

Thanks!

ISCBorisB

I hope this makes sense

Not much. You are mixing Apples, Oranges and Peaches

1.Apples JSR-170 (or any other JSR) is an abstract specification, not a Product. The proper question would be something like:

Q. Should I use non JSR-170 CMS System like IWOV TeamSite or should I use JSR-170 CMS Platform like Alfresco?
A. Only you (your Company) can answer. It depends on preferences, expertise, price of licensing, availability and price of Support
Development and Maintenance, Open Source Policy and on and on...

2.Oranges. Generated Assets Format.

Q. Are we best off just generating the ASPXs from templates?
A. May be or may be not. Your target Environment seems to be .NET though, if so ASPX Format is the primary one.
If you are planning to change you Production Site Platform (to WAS, JBOSS, BEA and whatnot) that answer may change.
Note that 'Apples' and 'Oranges' are orthogonal, with some constraints you can create (almost) any format from
any CMS. TS and Alfresco both are perfectly adequate for generating ASPX (or HTML/XML/PHP/JSP/Perl for that matter!).

3.Peaches. That one is my favorite, a Holy Grail of complete Content and Presentation separation (military music here!)

Although a noble goal, it is best achieved (to the extent it can be achieved) by the intelligent use of your CMS. That said, at some point
separated Content and Presentation just must come together again in the form of Web Page for example. C/P separation in
ASPX is not far from C/P separation in HTML in my opinion, it just can not be done.

Ah, almost forgot. Yes, sure... You'd "be best off ensuring our templates/ASPXs are concise, etc...".
It will be much better than rambling, redundant and verbose templates/ASPXs.

nipper

The consultants I'm working with are using templates to generate our ASPX files. We've got master pages for the overall look and feel and the generated ASPX files contain the content and HTML to fill in the ContentPlaceHolder pieces of the master pages.

Follow Bo's advice.

2nd, what you *may* want to do is have the ASPX files include content controls (ascx) files and the templates generate those. This allows you to have better control on the look and feel.

Of course the ascx is worthless alone and must be paired with an aspx so it makes preview more complex.

All in all is this worth the effort ? I doubt it. But if you want to, go ahead.

KristerS

Thank you ISCBorisB and nipper for your input. You've given some great insight!

sudeshw

Hi guys,
Since most of you have already used TeamSite for .Net projects, could you please direct me to links/documents where I can get an understanding on the basic steps involved in creating a .Net project in TeamSite?

are there any additional tools apart from TeamSite required for this? for example I saw terms such as WorkSite, Interwoven CAP etc..

nipper

There is no best practice documents. There are a couple documents (one I wrote, another written by Interwoven) in the tech article list, on the implementation of DotNet in TeamSite, but most of the best practices are in consultants heads and seldom get written down.