custom tag location

Same question over here. Anyone has news on this ? --thx, F.

mstradling

I believe you should be able to just put them in there.

/vendor was added when they upgraded Perl with 6.1 and I think that was the point IWov moved all their code into vendor.

http://devnet.interwoven.com/site.fcgi/techlib/051304

You can just drop the code right there. Customizations really should live in site/lib anyway.

Environments:
(1,2) TS6.5SP1, TS6.5SP2 on W2K3
(3) Vignette V7 Portal on Solaris 9

To Mark and Dave,

I know this is the theory (site/lib and vendor/lib). But I tried putting my custom tag file in site/lib/TeamSite/PT/ and it doesn't work. If I put it in vendor/lib/TeamSite/PT/ it does work.

so are you guys giving me the theory, or does this really, practically work for you?

anyone else _tried_ putting a custom tag perl module somewhere other than vendor/lib ?

thx.

btw, my custom tag is a real simple modification of iwov_xslt, to output UTF-8 instead of raw format. Details for the curious are here :
http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=PRODUCTS_TEMPLATING&Number=74285&page=0&view=collapsed#Post74285

--Fred.

Fred,

To be honest, I try to stay away from reusing namespaces, i.e. site/lib/TeamSite/PT verses vendor/lib/TeamSite/PT, for this very reason. Why not create a new module under site/lib and reference that module from within your PT to give you the custom tag functionality?

Environments:
(1,2) TS6.5SP1, TS6.5SP2 on W2K3
(3) Vignette V7 Portal on Solaris 9

Dave,

thanks for the hints, but do you have any code examples of PT where you do that... I can't seem to get it to work.

Perl module namespaces confuse me enough as it is, but anyway, I'm quite convinced that, by the way the PTparser works, it will only look at the TeamSite: Smiley Tongue

T module for custom tag implementations.

I'd be grateful to see some working code that proves me wrong.

cheers,
Fred.

I might not be able to until late this week, only because my "goodies" are at home and until next week, I'm only home once a week.

Until then, perhaps someone else could share?

Dave

Environments:
(1,2) TS6.5SP1, TS6.5SP2 on W2K3
(3) Vignette V7 Portal on Solaris 9

I'd share - but I've never used custom tags - I do my PTs in Perl (one big iw_perl clause) and write / use regular perl modules when I need them.

Given a very specific, very small set of requirements - I might try writing / sharing the code for handling it - but anything more than that would essentially be me doing work for free, for someone else who is most likely getting paid for it.

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

You know me and you know I wouldn't do that -- it's not good for the TeamSite Guild

but I'd basically leave whatever I have in pseudocode so that one could extrapolate on how to get the job done without giving away any real work.

Environments:
(1,2) TS6.5SP1, TS6.5SP2 on W2K3
(3) Vignette V7 Portal on Solaris 9

My comment was not a snipe on your post Dave - merely providing the constraints under which *I* would provide a sample to do what was being asked for.

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

I follow... I'm basically agreeing that I wouldn't provide code outright like that. Maybe my previous post will beckon Jeff, who commonly DOES overextend himself and solve others' problems for them.

Environments:
(1,2) TS6.5SP1, TS6.5SP2 on W2K3
(3) Vignette V7 Portal on Solaris 9

JonathonG

would find it fascinating if you (or anyone else) got this to work in a different namespace, given the following line from PTparser.pm (on a 6.1 system, your mileage may vary in other versions):

eval "use TeamSite: Smiley Tongue

T::$element;";

This appears in the section of code dealing with initializing tags from the TPL. So, it would appear that the "TeamSite: Smiley Tongue

T" namespace is required. So, unless you can figure out a way to point the TeamSite: Smiley Tongue

T namespace to site/lib for some things and vendor/lib for others, I think you're stuck with putting the custom tag info under vendor/lib (way less than desirable). Of course, your alternative is to, as ghoti suggested, write the PT all in Perl and use standard Perl include mechanisms.

Jonathon
Interwoven Developer
Allstate, Inc.

Sadly, I think you're right. I guess I had put my tags in vendor/lib. There's an interesting module: vendor/lib/TeamSite/PT/iw_xml.pm, which basically parses the tags and then hands off to the individual functional modules.

Dave

Environments:
(1,2) TS6.5SP1, TS6.5SP2 on W2K3
(3) Vignette V7 Portal on Solaris 9

JonathonG

Amazingly enough, this is even documented correctly. See TSserver>http://TSserver/iw/help/tst/pt/TeamSite__PT__iw_xml.html, where it states:

Classes that derive from TeamSite: Smiley Tongue

T::iw_xml must be installed in:
<path-to-TeamSite-perl-module-dir>/TeamSite/PT/ in order to be
used by PTparser.pm

So, I guess sometimes it pays to RTFM.....sometimes

Jonathon
Interwoven Developer
Allstate, Inc.

Okay, I deserved that, I suppose

although, whenever possible, I much prefer looking at the actual code than at errant and sometimes arbitrary documentation.

Dave

Environments:
(1,2) TS6.5SP1, TS6.5SP2 on W2K3
(3) Vignette V7 Portal on Solaris 9

JonathonG

I much prefer looking at the actual code than at errant and sometimes arbitrary documentation.

Agreed. Thus, the "sometimes" in my message

Jonathon
Interwoven Developer
Allstate, Inc.

For what it's worth - I created two modules like so:
[iwhome/iw-perl/site/lib/testing/foo.pm]package testing::foo;
use base qw(Exporter);
@EXPORT = qw(foo);
1;
sub foo{
print "FOO\n";
}[iwhome/iw-perl/vendor/lib/testing/bar.pm]package testing::bar;
use base qw(Exporter);
@EXPORT = qw(bar);
1;
sub bar{
print "BAR\n";
}[/tmp/foo.ipl]#!/path-to/iw-perl/bin/iwperl
use strict;
use warnings;
use testing::foo qw(foo);
use testing::bar qw(bar);
foo();
bar();
exit 0;I run it:/tmp > iwperl foo.ipl
FOO
BAREven if I change it to eval "use testing::foo qw(foo);"; it works so it seems to me that as long as you don't use the name of an already existing module it should work if you place your module in site/lib.

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

In reply to:

Amazingly enough, this is even documented correctly. See http://TSserver/iw/help/tst/pt/TeamSite__PT__iw_xml.html, where it states:

Classes that derive from TeamSite:T::iw_xml must be installed in:
<path-to-TeamSite-perl-module-dir>/TeamSite/PT/ in order to be
used by PTparser.pm

Yes, I did RTFM and I saw that. but it was also there in the 5.5.2 docs for iw_xml.

So I _figured_ that
- under TS 5.5.2 <path-to-TeamSite-perl-module-dir> = iw-home/iw-perl/lib/perl5/site_perl/5.005
- and under TS 6.5 <path-to-TeamSite-perl-module-dir> = iw-home/iw-perl/vendor/lib + iw-home/iw-perl/site/lib (given all the wonderful stories about splitting your own code from vendor code)

but the PTparser doesn't seem to think that way. Dunno why.

--Fred.

I think you should open a case with Support to report this as a bug. As I indicated in my previous post - you should be able to call uniquely named modules from within any sub-directory of the @INC path regardless of whether the sub-directory name itself is not unique between multiple paths.

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

I found in vendor/lib/TeamSite/PTparser.pm why the custom tag handlers (modules) must be under vendor/lib



   652        # tag modules are located directly below the PTparser.pm
   653        my $iw_xmldir =  File::Basename::dirname( __FILE__ ) . '/PT';
   654
   655        opendir (PT, "$iw_xmldir") or die "could not open $iw_xmldir";
   656
   657        my @iw_xml = map { s/\.pm$//; $_} grep { /\.pm$/  } readdir PT;
   658
   659        foreach my $tag (@iw_xml)
   660        {
   661            # so that it's easy to hook things in later,
   662            # set a flag in our "known iw_xml elements" hash
   663            # (tag modules actually get pulled in just prior
   664            # to first use via an evaled 'use' directive).
   665
   666            $this->{iw_xml}{init_state}{$tag} = -1; # defined, no init yet
   667        }                                           # >=0  means init ran

So basically, what happens is that it takes all the perl modules in vendor/lib/TeamSite/PT and accepts those as tags (custom and iwov) in Presentation Templates.

That explains why it doesn't care about @INC so much. Reflects old style (non-split vendor/site) structure of the Teamsite perl library.

Yeah, a bug support case should be made. Hope I find the time

-- Fred.

EDIT : made a support case.

Good detective work - please do find the time to file it and post the bug id to the forum.

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

yeah, good thing Interwoven is an open-source believer

Good detective work - please do find the time to file it and post the bug id to the forum.

Support finally treated this (after 19 days). BUG ID is 65447

"Starting from Teamsite 6.1, all the Interwoven perl customizations have been moved to vendor/lib, and site/lib seems to be the directory for the customer to install their own and 3rd party packages/modules. Specifically for PT custom tags, when the user customization perl module is put inside site/lib/Teamsite/PT, the PTparser.pm doesn't seem to parse the perl modules which results in an error. PTparser exclusively looks at vendor/lib/Teamsite/PT modules.
(...)
The below KB article also misleads the fact that the /iw-perl/site/lib is reserved for customers. Although this makes sense for the installation of 3rd partly packages, it doesn't explicitly/implicitly explains the fact that PTparser.pm will ignore the tags present under this directory structure.
https://support.interwoven.com/kb/kb_show_article2.asp?ArticleID=51304

This seems to have created lot of confusion from the customer's perspective.
"

--F.