Java Vs Perl in TeamSite

Usually, all the Interwoven Implementation i have done, it was done in perl. Let it for FormAPI or External tasks or adding extra features to the save functionality in the DCR. My client has a requirement to get away from perl as they always have hard time to find Perl skilled personel in the market.

Has anybody used Java as the programming language with Teamsite. If yes, would you recommed using Java with respect to PERL and Why ?

Also, it would be great, if you can point me to some documentation, if any

Thanks

Find more posts tagged with

Comments

MAK

Usually, all the Interwoven Implementation i have done, it was done in perl. Let it for FormAPI or External tasks or adding extra features to the save functionality in the DCR. My client has a requirement to get away from perl as they always have hard time to find Perl skilled personel in the market.

Has anybody used Java as the programming language with Teamsite. If yes, would you recommed using Java with respect to PERL and Why ?

Also, it would be great, if you can point me to some documentation, if any

Thanks

Hi,

I think there would be lot of people here in support of "Perl" for the reason of comfort it gives you and as teamsite has always been using "Perl".
Now in my view, it will depend on which functionality you want to change to JAVA.
I have used it and i kind of liked the JAVA external task, java for customisation (custom features).
JAVA external tasks runs under the same JVM as teamsite so no extra processes, while using perl you can have "n" processes running for "n" external tasks.

kaalraa

Usually, all the Interwoven Implementation i have done, it was done in perl. Let it for FormAPI or External tasks or adding extra features to the save functionality in the DCR. My client has a requirement to get away from perl as they always have hard time to find Perl skilled personel in the market.

Has anybody used Java as the programming language with Teamsite. If yes, would you recommed using Java with respect to PERL and Why ?

Also, it would be great, if you can point me to some documentation, if any

Thanks

I suggest to get an answer from Interwoven itself. Smiley Happy

Adam Stoller

Usually, all the Interwoven Implementation i have done, it was done in perl. Let it for FormAPI or External tasks or adding extra features to the save functionality in the DCR. My client has a requirement to get away from perl as they always have hard time to find Perl skilled personel in the market.

Has anybody used Java as the programming language with Teamsite. If yes, would you recommed using Java with respect to PERL and Why ?

Also, it would be great, if you can point me to some documentation, if any

Thanks

Interwoven has been trying to lean towards Java and away from Perl for some time now - and generally each new release usually has something which helps put more emphasis on Java and less on Perl (for instance, in 6.7.1SP1 - if you want to use "non-OS users" you have to abandon all your pre-existing PTs and switch to using XSLT (okay, it's not Java, but it is away from Perl), if you're using WFM it's now javascript instead of Perl for the instantiation process and web services based URL Tasks instead of External Tasks (you could still use Perl, but ...)

Personally, I think the industry / universities made a mistake putting so many eggs in the Java basket without maintaining a well-rounded discipline for other languages. I think that Java definitely has its uses and strengths, but so does Perl - and that there are cases where one is significantly better than the other for a given task, and there are cases where either one will do just as well for a given task.

I'm certainly biased in favor of Perl, but that's largely because I have far more experience with it. I think it's easier to pick up and learn and play with, but as an interpreted rather than purely compiled language, it tends to have some performance overhead in run-time. And, because Interwoven never really provided a true Perl API, but does provide a true Java API - you can do a lot more in Java without incurring extra process overhead for invoking CLTs (like you do in Perl).

I think there are probably still a lot of Perl-knowledgeable folks out there (the language is far from "dead") - but Java is a more prevalent skill set - and thus generally easier to pluck people right out of school at cheap rates with sufficient skills to get started.

Bill Klish (a frequent contributor to these forums) has done a lot of work with TeamSite in Java, and I believe is quite happy to continue doing so - and I'm sure he'd recommend doing most, if not all, of your customizations in Java.

Of course there's also the axiom that you can generally write good (or bad) code in either language - so just because you choose a language to use doesn't mean you're going to get easier to understand or maintain code as a result.

For the Java stuff - you need to download the CSSDK from Interwoven's support site - though you may need an additional license to do so (or at least to use it).

ISCBorisB

Bill Klish (a frequent contributor to these forums) has done a lot of work with TeamSite in Java, and I believe is quite happy to continue doing so - and I'm sure he'd recommend doing most, if not all, of your customizations in Java

Without looking (and looking hard!) though, can you name another Java contributor? I know I can't...

What I do know is that my two Java-related requests did not find any real takers - none. Also, correctly or otherwise I
have an impression that I'm not the only one. If Interwoven has indeed been leaning towards Java, not a lot of us followed.

Adam Stoller

Without looking (and looking hard!) though, can you name another Java contributor? I know I can't...

What I do know is that my two Java-related requests did not find any real takers - none. Also, correctly or otherwise I
have an impression that I'm not the only one. If Interwoven has indeed been leaning towards Java, not a lot of us followed.

I think there have been a few, but none as prevalent as Bill.

While I hope to expand my skill set with Java / CSCDK at some point - especially in places where I find I have to make a bunch of system calls to IWOV CLTs, I'm still pretty much of a die-hard Perl programmer and don't see that changing anytime soon.

nipper

If Interwoven has indeed been leaning towards Java, not a lot of us followed.

Old dogs, new tricks. Go figure.

Now where is my K&R C book.

Adam Stoller

Old dogs, new tricks. Go figure.

Now where is my K&R C book.

I have a signed Harbison & Steele if you need it ;-)

nipper

I have a signed Harbison & Steele if you need it ;-)

Yes truly a geek.

This from the guy who has a signed copy, 1st edition of Unix Power Tools. Smiley Very Happy

mohit_maniar

Hello Santosh,

I am doing an implementation for my current client. I used java api [CSSDK & WFM] mostly for workflows. It was quite handy. Java API's are providing almost all functions which you could do the same with perl [External Task etc].

Let me know if you need more information.

Thanks,
Mohit.

Migrateduser

I guess i have opened a can of worms for us to debate :-)

ISCBorisB

I guess i have opened a can of worms for us to debate :-)

Surely it must have been a jar of worms

Migrateduser

Are there any speed imrovements with java over perl? I find that java runs pretty slow especially through a web server. Development might be a little slower since you'll have to compile and put it in a form that TeamSite can use. With perl, you can write your code and test it out on the command line without any compiling into byte code. But that is just me.

ISCBorisB

Are there any speed imrovements with java over perl? I find that java runs pretty slow especially through a web server. Development might be a little slower since you'll have to compile and put it in a form that TeamSite can use. With perl, you can write your code and test it out on the command line without any compiling into byte code. But that is just me.

That really depends on what you are doing and how you are doing it.

For example, (other things being equal) traditional non-URL external tasks are faster to instantiate in Perl than in Java.
From the other hand, CSSDK provides (again for example) an API to assign Extended Attributes. The only way to do that in Perl is to call
corresponding clt with the target File. Try to do that for a deep directory structure and shell-forking overhead really adds up. Single
precompiled Java servlet can be quite literally hundreds times faster.

As for development efforts, testing and such - that really depends more on your and your team expertise and preferences
than anything else.

Samir_Friend

Hello Santosh,

I am doing an implementation for my current client. I used java api [CSSDK & WFM] mostly for workflows. It was quite handy. Java API's are providing almost all functions which you could do the same with perl [External Task etc].

Let me know if you need more information.

Thanks,
Mohit.

Hi Mohit,

Can you please elabborate "....almost all functions..."? I want to know what is missing with the Java part.

pammi

It all depends on requirement.

It not much UI then perl is good enought since it is easy compile and run.

If you have more UI (beautification)then java is good .

Thanks

Amlan

I agree,

Java APIs are available not only for TeamSite but for OpenDeploy, metatagger etc which is very handy indeed.

I would advise you to go for an XSL based implementation as opposed to TPL and use Workflow Modeller.

Workflow Modeller reduces the complexity and helps in customising workflows by admin users.

Using XSL, WFM and java based external tasks can give you a complete perl free implementation.

Regards,
Amlan

Adam Stoller

Workflow Modeller reduces the complexity and helps in customising workflows by admin users.

You must be drinking the IWOV Sales Koolaid - WFM makes something that should involve technical knowledge seem like it's easier than it is, and then makes it twice as complicated to do things "right". If you do design the workflow correctly (with timeout handlers and error handlers - the WFM GUI becomes a tangled mess of boxes and lines, thus showing that there is more complexity involved in designing a workflow than just drawing a few boxes with lines between them on a screen.

I think WFM is a big step up from the old Workflow Builder - but that's not really saying much since WFB was a piece of **** that never should have been released.

The concepts behind WFM are reasonable, I just don't think they've done enough to truly make it work as good as they make it sound like it does.

Migrateduser

You must be drinking the IWOV Sales Koolaid - WFM makes something that should involve technical knowledge seem like it's easier than it is, and then makes it twice as complicated to do things "right". If you do design the workflow correctly (with timeout handlers and error handlers - the WFM GUI becomes a tangled mess of boxes and lines, thus showing that there is more complexity involved in designing a workflow than just drawing a few boxes with lines between them on a screen.

I think WFM is a big step up from the old Workflow Builder - but that's not really saying much since WFB was a piece of **** that never should have been released.

The concepts behind WFM are reasonable, I just don't think they've done enough to truly make it work as good as they make it sound like it does.

I would definitely have to agree with you on this. Now that I've used WFM for a couple of months after writing WFT's for a number of years, while I kind of like the Java API, actually building a useful complex workflow is far from trivial with WFM. The drag and drop GUI is cute and all, but under the hood when you need to do things that aren't so cookie-cutter, that's when it gets really confusing. Dealing with variables and parameters is not simple. It's certainly doable and once you understand it, you then know how to do it in all workflows. But the documentation is poor (shocking!) and really that's my biggest gripe. WFT is hard if you don't understand it. If there were better docs, it would be less hard, but it would still be hard. WFM shouldn't be hard, but it is because it's not intuitive after you've drawn your boxes and lines. And the documentation is remarkably weak.

DevNet is lucky to have the 5 or so experts still here helping people. Autonomy/IW is not helping people on DevNet. IW Support has been offshored (or so it seems) and communication with some of the support folks can be very, very difficult and frustrating. If only there was better documentation...

miletwo

Poor documentation on an IW product? NO! Say it isn't so!

oscarvillalvazo

I would definitely have to agree with you on this. Now that I've used WFM for a couple of months after writing WFT's for a number of years, while I kind of like the Java API, actually building a useful complex workflow is far from trivial with WFM. The drag and drop GUI is cute and all, but under the hood when you need to do things that aren't so cookie-cutter, that's when it gets really confusing. Dealing with variables and parameters is not simple. It's certainly doable and once you understand it, you then know how to do it in all workflows. But the documentation is poor (shocking!) and really that's my biggest gripe. WFT is hard if you don't understand it. If there were better docs, it would be less hard, but it would still be hard. WFM shouldn't be hard, but it is because it's not intuitive after you've drawn your boxes and lines. And the documentation is remarkably weak.

DevNet is lucky to have the 5 or so experts still here helping people. Autonomy/IW is not helping people on DevNet. IW Support has been offshored (or so it seems) and communication with some of the support folks can be very, very difficult and frustrating. If only there was better documentation...

I know that feel bro