Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
"Find" custom menu item
System
Does anyone have a good 5.5.2 custom menu item for find that they would be willing to share? I would like to give the users four textboxes, two for filename (one regex, one exact) and two for text (one for regex, one exact). It should not allow exact if regex is entered and vice-versa. It would look in all files under their current directory for matches. Another thing that would only take a few hours to develop that should ship with the product (as an option if performance is a concern)...
Find more posts tagged with
Comments
Migrateduser
For whatever it's worth, 6.5 is supposed to come with a Search function that should do what you want and more. So if you can wait till October, you'll be golden.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
Actually this client is thinking about dropping IW within a year so 6.5 may never happen here. I really need something to find links to pages they want to move and/or delete.
tempnick
You are off base in suggesting that a truly useful find can be coded up in a few hours. Any "brute force" search through the file system to check metadata and parse content will be brutally slow unless restricted to a few directories. Don't bother trying unless you're ready, willing, and able to provide a nice CGI so users can narrow down what they're looking for. The only fast way to "find" things WHEREVER they might happen to be will involve some sort of indexed search via a dedicated search engine or by using a database -- neither of which is quick work to implement.
Migrateduser
Well, I've done it so I wouldn't say I'm off base. As I said, performance would be a concern, but the overhead of developing a real search solution exceeds the value, especially since the client may scrap Interwoven this year. If it's limitted to subdirectories and only exposed to certain users on certain branches I really don't forsee much problem. Like most shops, we can't let users map to the IFS as that breaks locking, templating, etc., and it's ridiculous for a CMS admin to get a call whenever a user needs to search. So you're the one who's off base.
One other thing I'm adding is checkboxes for whether the filenames/matches should be case sensitive.
tempnick
I'm confused... If you've already "done it" what are you asking for?
I'm certainly not trying to be an apologist for Interwoven but having once gotten sucked into the trap of trying to provide a quick solution to the "find" problem I would assert, again, that a useful general purpose search facility can not be achieved with a few hours of coding on their part, or anyone else's for that matter. It's one thing to make a "tool" that works in an idiosyncratic or limited way for your own use but another thing entirely to make a "product" for end-users.
Meanwhile, I WHOLEHEARTEDLY AGREE with you that a "Find" menu option should have been included long ago. It would have been well worth the development cost because it would have addressed what is probably one of the the Top Ten complaints about using TeamSite and may well have been a showstopper preventing many companies from adopting the product.
Migrateduser
Nick, you would be taken more seriously if you filled out your profile or added a sig line so we know who you are and who you represent. People who are anonymous tend not to get appreciated as much. Just a suggestion...you can do whatever you want.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Migrateduser
> I'm confused... If you've already "done it" what are you asking for?
I did this at a client site about 2 years ago. Since nobody seemed to be willing to share their version of this tool I am pretty close to having another one done (~200 lines of Perl).
tempnick
Call me "temp" instead of "nick" -- I bounce around from gig to gig and change emails ('cause of SPAM) so much I never seem to be at at one "valid" email address long enough to establish an identity... hence the "temp" moniker.
Just curious... why do you need to know who I am? Can't the text in a message stand on it's own? It's not like I'm trying to sell anyone stock or real estate. Plus, I do have a litte "history" with some foks here and I would rather it not influence a thread one way or another. Suffice it to say I've been doing TeamSite consulting for a while and system development for a long while. If you ever want me to qualify an opinion, just ask.
Migrateduser
Like I said, it was just a suggestion. It just tends to validate you....or not. You can do whatever you want. However when you say you have some history with people here and that is one of the reasons you want to remain anonymous, that does make one wonder...
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
Adam Stoller
Interwoven provide(s/d) a DCR Search and Metadata Search add-on that require(s/d) the use of DAS to push content and/or metadata to a DB in order for it to be searched on. This only worked for DCRs and Metadata (as the names imply).
The tricky part with DCRs had to do with replicants - e.g. if you have N replicated items and you want to search for "x" - do you provide a 1:1 mapping of the replicant items to search within (find "x" in replicant-1) or do you iterate through all replicants to find a match? The Interwoven tool provide(s/d) the former interface which tended to confuse people.
Do you need a DB? No - but it would probably make searching performance significant better at the expense of overhead elsewhere to push the data into the DB.
Traversing a directory tree in Perl is relatively trivial - though there are some pitfalls that folks tend to fall into fairly frequently (things to look out for: decide which area [edition/edname, staging, or workarea/waname] to search through and prevent your recursition from navigating through the other areas; do a breadth-first rather than depth-first search to prevent having too many open file descriptors).
Doing the actual search involves determining if it is to be structured (e.g. look for "x" in this location or element tag) versus unstructured (e.g. look for "x" anywhere within this file). The former requires a bit more code but should be more efficient in the long-run, the latter is trivial to implement but stands a chance of being relatively slow and returning "false-positive" results - especially for short and/or common strings.
As with any customization of this scope - I'd suggest starting with a requirements document and a relatively detailed design document - reviewed by the customer to verify that they agree with what will actually be implemented -- that should help tailor the design to their needs and allow you to choose among the various methods of implementation for one which will be relatively straight-forward to implement and with a pre-concieved idea of what the performance will be like.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
tempnick
It's good to "wonder" sometimes.
I don't exactly know what you mean by "validate you....or not" in your post. Shouldn't the substance of a message be enough? Or, is this a club with secret handshakes and a "good table" in the cafeteria? Would you NOT respond to a post from "tempnick" just because you didn't know me? What if I did fill out a profile? Would you know if it's truthful or not (if it's not nonsensical or coy)? What REAL difference does it make? (No, I'm not Marlon Brando reprising my role in Last "Tango in Paris"... "Names! Why do we have to have names?")
DevNet has gotten to be a good resource not because of all the bandwidth-wasting banter among the regulars but because of the real discussion of issues and collegial problem-solving that goes on here a good part of the time. But I digress... and wish there were an easy way to move this post over to the Bit Bucket while replying (is there?).
Meanwhile, don't get me wrong, I applaud YOU (and folks like jmeyer) for being vocal on so many issues and being, I guess, the Official Thorn in Interwoven's Side (OTIS). Since no one from Interwoven ever steps up to moderate the forums I appreciate all the time and effort you exert to try and keep things on a higher level here. THANKS!
-temp
Migrateduser
I just need a dumb keyword scan. The issue is really when a user moves, deletes or renames a file (I really suggest they they don't do that as it breaks DCR/output file relations, etc. and that crazy stuff with submitting), but sometimes it has to happen. I want them to be able to find all of the links to that file. There are probably other uses. Scanning the DCRs won't do. Again, as the customer is thinking about ditching IW, the whole idea of DataDeploy/DAS is out of scope and even if it wasn't I probably wouldn't consider it. I can't let them mount the IFS and use normal find tools because that breaks templating, locking, etc.
A real database back end would be nice...
Migrateduser
You make some valid points. Honestly, you're right, the substance of your replies should be all that matters. But some people have indeed made some valiant efforts to "help" people only to be very wrong. And you're right - you could put anything you wanted in your profile. The fact that DevNet is so open to anyone makes it both good and bad. I'm more curious than anything now just because of your last post, but you're entitled to your secrets. The people who absolutely should have a profile filled in and a sig line are the folks who work at Interwoven. I guess for anyone else it doesn't really matter.
I wish more people would just post at all. There seems to be a very small group of "regulars" and a
slew
of lurkers. I know I tend to invalidate myself because i cry wolf so much. But being able to vent is more comforting to me, because I know the things I think are wrong most likely will not be fixed, so invalidating myself in the eyes of some is not as significant as the satisfaction I get from venting. Everyone has their own motivators. I'll get off the profile soapbox...happy posting.
Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com
nipper
>Just curious... why do you need to know who I am? Can't the text in a message stand on it's own? It's not like I'm trying to sell anyone stock
>or real estate. Plus, I do have a litte "history" with some foks here and I would rather it not influence a thread one way or another. Suffice
>it to say I've been doing TeamSite consulting for a while and system development for a long while. If you ever want me to qualify an opinion, just ask.
On the internet, no one knows you are a dog. (One of my favorite cartoons)
When you post people want to know if you are a true expert or not. Esp when one posts opinion rather than specific code. It is
easy to say this will/won't work & give a couple of anecdotes about why. So when I look at an informative post, I want to know
if that person really knows what they are talking about. FOr someone who has posted little that means reading the profile.
Note, I am not accusing you of doing any of those things, however giving other people here your frame of reference is a good thing.
You do not have to give out your email if you do not want, but a little bit about your TS history will help.
Andy
tempnick
"I want to know if that person really knows what they are talking about"
So, "kick the tires" a little bit and see what response you get. That way, you and other readers can get context & background "inline" instead of having to read the tea leaves in a profile. For what it's worth, I've had one SUPER TS assignment, a few good ones, a few forgettable ones, and one noble disaster. My batting average has been better in other specialties but I don't think I've ever hit a longer homer than my SUPER TS gig.
-temp
Migrateduser
> SUPER TS
OK, this guy clearly has not worked with the product.
Just kidding, I've done my share of Super TS as well (though in this case super is a relative term).
tempnick
Touche (accent over the e)!
The SUPER part came from how I overcame the limitations of The Product and made EVERYONE happy. Not coincidentally, a big part of it (I guess the "S" part of SUPER) was how I enabled people to Search for their content using an Oracle DB to store all The Good Stuff (metadata, key content).