IDE for Teamsite - Forms publisher

Hello-

Is there a plugin for existing IDEs like Eclipse etc OR any IDE to build/edit datacapture and presentation templates, with auto complete for xml elements etc...

Thanks

Find more posts tagged with

Comments

mart2001

No, there are no IDE for TeamSite that will help with code completion. Unless you write your own syntax and heavily customize eclipse for that to work. The best option might be to open the formpublisher in an xml editor. But there are no ready made software out there to use for TeamSite editing purposes.

Rick Poulin

No, there are no IDE for TeamSite that will help with code completion. Unless you write your own syntax and heavily customize eclipse for that to work. The best option might be to open the formpublisher in an xml editor. But there are no ready made software out there to use for TeamSite editing purposes.

You can, however, use most XML editors (including Eclipse) for DTD validation and code completion, provided you configure the IDE to point at and read the DTD file.

nipper

There was a plugin for Dreamweaver to make TPL and DCTs. They were of marginal value.

Jashan

ok. XML Editor makes sense for DCT/PT.

Say how about a .wft file that has both perl and xml in it? What are people out there using to edit a .wft file? The best I could think of was to use EPIC (perl plugin) for Eclipse. And when I want to edit the XML I just open the same file using XML editor.
Is there any better than this approach?

Thanks
A

Adam Stoller

ok. XML Editor makes sense for DCT/PT.

Say how about a .wft file that has both perl and xml in it? What are people out there using to edit a .wft file? The best I could think of was to use EPIC (perl plugin) for Eclipse. And when I want to edit the XML I just open the same file using XML editor.
Is there any better than this approach?

Thanks
A

I use Emacs if editing a WFT (and many other such files - but then again, I'm quite happy without an IDE for Perl or XML)
I use WFM for most workflows now, as most of my customer's want it that way (it's got its quirks, but ...)

kman1

Based upon responses, there does not appear to be a TeamSite solution or IDE to both support development of code (java, javacript, xsl, etc )and development of Content (page, dcrs, templates, etc) How are folks working around this challenge?

Our team will definitely be using an IDE to do development so that we can efficiently write, deploy, and test code changes locally and Emacs and VI is not an option. How to I bridge the source control for code vs Team Site for Content divide?

I saw this plugin and wonder if anyone has any experience with it: http://sourceforge.net/projects/ts-team-plugin/

Thanks for your help

Rick Poulin

Based upon responses, there does not appear to be a TeamSite solution or IDE to both support development of code (java, javacript, xsl, etc )and development of Content (page, dcrs, templates, etc) How are folks working around this challenge?

You might have to expand on your situation, because this seems non-standard.

Typically, you have a well-defined separation between "code" and "content".
* code is written by developers, tested in other TeamSite environments, and eventually promoted to production. This is usually versioned in a third-party tool like TFS/SVN/CVS/Perforce/etc.
* content is usually written by content authors (business users) directly in production, and is versioned by TeamSite itself.

Code is usually java, xsl, perl, DCTs, workflow, etc.
Content is usually dcrs, pages, images, etc.
JS and CSS may fall in one or the other, depending on your situation, the capabilities of your users, and the desire of your organization to maintain control of the look and feel.

In your case, it sounds like you're responsible for both code and content, in which case, is TeamSite really the platform for you? TeamSite is meant to facilitate website content management by non-technical users. If you, presumably a very technical user, are managing content via this platform, you're probably limiting yourself with needless bottlenecks and implementation restrictions, IMO... but again, you might need to expand on your circumstances to paint a fuller picture.

kman1

You might have to expand on your situation, because this seems non-standard.

Typically, you have a well-defined separation between "code" and "content".

Thank you for your help and let me clarify. Our organization does have a separation of code maintained by developers and content maintained by the business. The problem is that we have to merge content and code between TeamSite and Source Control.

Java, javascript, css, and XSL are maintained a source control system outside of TeamSite so that developers can easily code in eclipse in their local environments. The project extends LSDS so that developers can run the LSDS locally in an application container. The javascript, css, and XSL have to be imported to team site from source control in order to support site publisher.

Content such as pages, DCRs, templates, images, etc, are maintained in Team Site, but this has to be exported to the local developers machine so developers can work locally with the latest business content changes. Currently to accomplish this by exporting content to source control, so each developer gets the updates when they synchronize.

So synchronizing content and code between the two systems onerous and I’m looking for ideas to help simplify to reduce overhead, simplify builds & deployments, and reduce errors. Currently we only allow developers to modify CSS in source control, however the business would like to be able to modify the CSS in the future as well.

Rick Poulin

Java, javascript, css, and XSL are maintained a source control system outside of TeamSite so that developers can easily code in eclipse in their local environments. The project extends LSDS so that developers can run the LSDS locally in an application container. The javascript, css, and XSL have to be imported to team site from source control in order to support site publisher.

This is a pretty standard problem. Autonomy attempted to provide an answer in the way of SPARs (SitePublisher ARchives; documented in the SitePub dev guide). The theory is that you would have an ANT or Maven build process in Eclipse that would build the SPAR (a ZIP file with a specific folder structure) and then your build manager could take this file and deploy it on a target TeamSite instance via the provided install_archive.ipl script. In reality, I've found SPARs to be somewhat restrictive so I've built a process along the same lines -- eclipse builds a ZIP and I have a script on all TeamSite instances that consumes this archive and puts the contents in the right places. If you search devnet, you'll find that variations of this is what most people tend to do, but it's almost always a custom build.

Content such as pages, DCRs, templates, images, etc, are maintained in Team Site, but this has to be exported to the local developers machine so developers can work locally with the latest business content changes. Currently to accomplish this by exporting content to source control, so each developer gets the updates when they synchronize.

I don't often bring production content back into dev because content shouldn't matter as long as you have a representative sample. As such, I've often just made this a manual process of updating my development sandbox with production content using a manual file copy, as required. If yours is more frequent, or you're more dependent on real world content, I'd suggest writing a script that allows any given sandbox to "pull" production content by copying across a file share or something like that. You could automate this, but personally I think you could just leave it up to the developers to sync whenever required.

So synchronizing content and code between the two systems onerous and I’m looking for ideas to help simplify to reduce overhead, simplify builds & deployments, and reduce errors.

This is always the goal for all projects, but since TeamSite is a framework and not a solution, it's hard if not impossible for Autonomy to provide a "one size fits all" build process. As such, I don't think there will ever be any answer other than "build your own to suit your needs" though for consultants like myself, we tend to build it once and then reuse+tweak it for new clients.

Currently we only allow developers to modify CSS in source control, however the business would like to be able to modify the CSS in the future as well.

If and when you get there, make sure to keep a clear delineation between developer- and business-responsibility, possibly by splitting up the css into separate files and @importing one into the other or merging them at deployment time. If possible, keep even the folder structures separated.

Adam Stoller

One project I worked on recently used TFS for source code control with an ant script that build jar files and placed them into the appropriate directory on the TeamSite server (e.g.: IWHOME/local/config/lib/content_center/...) and then the would do a make_toolkit.ipl or build.sh (depending on where the jar file went) - and their content would reference code from there.
The "grey-area" files (CSS, JS, XSL) were often distributed into their appropriate locations too, as individual files, but were excluded from being deployed to the production environments, as that was handled via the jar files.

I was only tangentially involved in the above, so I don't really have more details than that, but perhaps it will server as a spring-board (no java pun intended) for you to come up with a full solution.