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

Application Development Environment

System

I am looking for information and best practices around developing web applications with TeamSite CMS. Specifically how the development environment and repositories should be structured. For example, without TeamSite CMS the view content such as html, css, and xsl will reside within the main source code repository such as CVS. Assuming I am a server side developer when I am developing I will checkout the latest code in CVS and be able to deploy local in the typical manner. Well along comes the TeamSite CMS repository and now all html, css, etc. is stored within TeamSite CMS and stroed in the associated content-store. (More specifically the templates and content that will be generating my html.) Now is it best practice to have the most recently released html, etc generated by TeamSite CMS synced in CVS to aid the development of the web application? From a developers perspective what if I need to work on a new service that will be triggered from a not yet stable button created in the CMS, what is the best solution to allow for this type of development? Any help, guidance, or conversation is encouraged. Thanks in advance...

Find more posts tagged with

Comments

Bowker

w00w00 - wOWwOW - what a question.

I've been using TS for about 6 or 7 years and have talked to dozens (+) of different companies that use TS for a number of different things. It's a tool that can be used & abused (customized) to do whatever you want.

We use it for four different purposes our selves.
java code repository
content repository
web site construction
Education/training CDs

As for "best practices" it will depend greatly upon your environment, security/permissions requirements, size of your expected content, TS components you use (TS, Forms Publisher, Site Publisher, Live Site), number and skill set of users.

If you can elaborate more on your environment and what your ultimate goal is that would help. Also you should consider attending a local user group, although I didn't look up where you're located.

nipper

w00w00 - wOWwOW - what a question.

I've been using TS for about 6 or 7 years and have talked to dozens (+) of different companies that use TS for a number of different things. It's a tool that can be used & abused (customized) to do whatever you want.

This is not something that is easily described in a sound bite. There is a reason consultants on here have been using the product for several years. When someone calls themself a TeamSite Architect, it is (often) for very good reasons.

(Development)
Win 2K
TS 6.7.1 SP2 (i think)
LS 3.0
OD ?

BTW, Dan, you are not using 6.7.1. SP2 on your dev server, maybe SP1, since that was release just last month.

Andy

Migrateduser

If you can elaborate more on your environment and what your ultimate goal is that would help. Also you should consider attending a local user group, although I didn't look up where you're located.

Currently the site isn't using TeamSite at all, though we have licenses for the following.
- TeamSite Version 6.5 SP1
- OpenDeploy 6.0.2

Good news is that I know that I can practically do anything within the TeamSite fold via scripting, configuring, and extending. Bad news is, that is a lot of rope. I will do my best to explain the current environment, and the proposed new (TeamSite enabled) environment.

Current Environment:
Currently both client-side-developers (CSD) and server-side-developers (SSD) are using Dreamweaver and Eclipse for all development. For simplicity let’s just consider the HTML and Velocity Template files live in some views directory but are put in the WEB-INF directory when the application is build and deployed. Both work on the same SCM repository. Both CSD and SSD build and test the complete application locally. (If it matters we are using ANT for compiling, building and deploying the application.) Also, note that we can pull out the HTML and Velocity files to some other location and have the application refresh on the fly so that content only deployments can happen currently, but the content update is still tied to the IT (CSD) team.

Future Environment:
Hoping to use TeamSite CMS to decouple content and source-code releases further and allow for TeamSite content editors (business folk) to change and deploy content without IT (CSD) involvement the following environment has been presented.

HTML and Velocity Templates will have their necessary DCTs and PT/TPLs created therefore pulling out the content from the HTML and Velocity Templates into TeamSite for management through the use of FormsPublisher. Now when the new static HTML is generated based on changes to content or PT/TPLs these changes need to be pushed/pull/synced with the SSD environment; remember they are building and testing the application locally. Not worried about the CSD now since they will need to be doing there work within TeamSite, or using Dreamweaver for layout issues etc and then applying the necessary updated to the PT/TPL files within TeamSite.

This file syncing I can do many ways; OpenDeploy, scripting, command line, etc. It just seems like a problem that should have a more standard approach to solving.

Bowker

I think I understand what you want - you want the content to be separate from the presentation and allow for either to be updated "when ever" without involving (theoretically) the other group.

If I'm on track send me a private message with your phone number and I'll call. We do what I think you want here. It would be a long description, but it might be fruitful.

Firenze

Looking at something similar with Velocity templates involved. Any updates on how this went/is going.