Filtering by substring

[MacSig]

Hi, I'm not sure this is the right place to post my question anyway I have a portal that shows the list of the documents. For each document I have a button that links the document to a model. But since the number of documents is quite eleveted I would like to filter them, letting the use to input a string an display only the documents that contain the string within their title.

Is there a way to achieve so?

I really don't have idea where I should start from.

Thanks and have a nice day

[bcooney]

You are asking for a "filtered portal."

See comment's demo: Filtered Portal

[MacSig]

thanks Barbara for you reply: that is exactly what I was talking about.

Following the example you pointed me I could make it works matching a string. Is there a way to using a substring.

Let us say I have the children below:

GEN123

GEN456

LCQ789

and I would like to be able to input GEN and get GEN123 and GEN456.

I'm not sure this is possible since I have to change the relationship between Parent and FilteredChild.

Right now the relationship is cSubstring = cSubstring and I don't see the option to use any functions.

Is there a way to achieve my goal?

Thanks again and have a nice weekend

[comment]

If that's a constant pattern and not just an example, you could define a calculation field in the Child table =

Left ( Yourfield ; 3 )

and match on that. Even better way would be to split the field into two, as it seems to violate the "one fact per field" rule.

[MacSig]

Thanks for your reply.

It would be great if I can input any substring.

Changing my former example, if i have

GEN123

GEN456

LCQ789

LCQ123

and I input 123 I should get GEN123 and LCQ123

or at least having a variable substring length.

I'm not sure I understand what you mean when you say "split the field". you mean having 2 field (category and progressive) instead only one (code) and storing GEN as a category and 123 as a progressive ?

At this point I'm not sure all the documents have the same pattern, I will ask about and if applicable I will follow your suggestion.

Thanks again, I appreciate your help

[comment]

you mean having 2 field (category and progressive) instead only one (code) and storing GEN as a category and 123 as a progressive ?

Yes, that's exactly what I meant.

Matching any substring is possible, but not simple. In your example, you would need a calculation that takes "GEN123" and generates:

GEN123

GEN12

EN123

GEN1

EN12

N123

GEN

EN1

N12

123

to match a substring 3 to 6 characters long. Search the forums for 'exploded key' to learn more.

[MacSig]

Thanks I will.

Right now I have an issue with the filtered portal that is driving me crazy.

As I said I have documents and models (with a join table since I have a multi-multi relationship).

I have added the portal on document side and it works fine.

Now I'm trying to add the filtered portal also on model side. I have done exactly the same steps (or at least I think so) but when I input for instance TTT123 I get all the models ending with 123 (TTT123, ZZZ123 ...), even if I input TTT123x I get the same results. However if I input only TTT I don't get any of the TTT... models I have.

I know it is very difficult to figure out why without having the project in front but do you have any ideas?

Thanks

[comment]

Check your field types?

[MacSig]

you the man

I did but just on 1 side (on documents table) but I missed the type on models. it was number.

Now it works fine.

I have 1 more question for you (really the last one) since exploded key looks quite complicated. how about matching only the first n characters.

Something like Left ( Field ; n )

If I input GEN I get all the documents starting with GEN

If I input just G all the documents starting with G.

Is this easier than exploded key?

THANKS

[comment]

Yes, that's possible. I don't particularly like this method, but it seems to work.

MatchStringStartingWith.fp7.zip

[MacSig]

Thanks for your sample. However looks like it doesn't work

I have updated my calculation field now when I input as a global "GEN" the calculation looks like

"GEN

GENzzz"

but it doesn't match any code I have.

May I ask you why you added "zzz"?

I'd like to learn more about FM not just solve my current issue.

Once again thanks

[comment]

Does it work in my file with your data?

The "zzz" puts a 'cap' on the matching values, so that "GEO", for example is excluded. Only values that fall between "GEN" and GENzzz" are matched.

I said I didn't like this method, because it shouldn't work. I believe it's a bug. It has worked in 5 versions now, so I guess you can use it - but I cannot explain it.

[MacSig]

I have just changed 3 of your rows (with GEN123 GEN456 and GIN123) and looks like it work.

But when I change the calculation on my file, it doesn't perhaps because you have a self relationship on the table however I have different tables on the relationship.

[comment]

perhaps because you have a self relationship on the table however I have different tables on the relationship.

No.

[MacSig]

Looking around I found RegexPlugIn.

I'm trying to understand if it works with IWP, if so it could solve my issue: I could just use it to match the first n characters.

I'm going to try it.

Have a nice weekend

[LaRetta]

I have just changed 3 of your rows (with GEN123 GEN456 and GIN123) and looks like it work. But when I change the calculation on my file, it doesn't

:qwery:

And you don't care to understand what is wrong in your file? Why would you think a plug-in can solve it if Comment's method doesn't work in your file (although it works fine in his)? It means, as before, that something is wrong in your replication of the process and no plug-in can magically fix THAT. :crazy2:

[MacSig]

Thanks for your reply.

First of all I don't like so much to use "zzz" so if I can find something more explicable is better. Moreover, unfortunately with my FM knowledge is not so easy to understand what is wrong with that approach on my solution. I'm still working on but I guess I will give up soon.

Have a good 1!

[comment]

I found RegexPlugIn

I don't think you understand the real issue here. It's very easy to calculate if the child value contains (or begins with) the search string. However, such calculation must rely on the search string in the parent table - and therefore the result cannot be stored, and cannot be used as the matchfield in the relationship. That's why you need to either force the child to enumerate all possible combinations in advance, or use a range key on the parent side. Doing the calculation using RegEx is not going to change anything.

BTW, the "zzz" is entirely explicable. The somewhat problematic part is using a multi-line field to achieve a ranged match. Come to think of it, it's not really required here and you can construct an entirely orthodox range relationship - see attached.

MatchStringStartingWith2.fp7.zip

Edited June 27, 2009 by Guest

[MacSig]

Thanks for your reply.

You have just confirmed my thoughts.

I had an idea, I though it was a good 1 but it looked to easy to me anyway I tried it.

Left ( myField ; Length( Parent::field ) )

In this way I should obtain the first n characters but (of course) it doesn't work so even the plugin will not solve my issue.

I will check you way out again hopping to figure out what is wrong with my file.

Right now I can find the children that match exactly. Starting for here I do as below:

- I update the calculation field on the parent from gSearchString to

gSearchString

& ¶ &

gSearchString & "zzz"

- I update the relationship between Parent and Child from

cSearchString = cSearchString

to

cSearchString <= cSearchString

AND cSearchString > cSearchString

From my understandin these steps is what I need to make it works.

Am I missing something? Can you please confirm me the steps?

Thanks again I do appreciate your help

[comment]

Why is there a calculated cSearchString field on the child side of the relationship?

[MacSig]

On parent side I have 2 fields:

gSearchString Text Global

cSearchString Calculation Unstored, = gSearchString

and 1 on child side

cSearchString Calculation Indexed, = Code

and this works, I mean it matches the entire code.

The calculation on child side is because I tried Left (Code ; 3) earlier on. I guess it doesn't matter

Am I wrong?

Edited June 27, 2009 by Guest

[MacSig]

update: actually it matters

I have changed the relationship to

Code <= cSearchString

AND Code > cSearchString

and it works.

Thanks and have a nice weekend