Anything Portals

[bruceR]

One of the interesting features of the Web Viewer is the ability to display almost anything you can throw at it. Attached is a simple demo file that shows how to do something similar with just one table and either a list or portal view to that table.

It is a method for displaying data held in a Filemaker list (text field, global text field, or $$variable).

The idea is that you make a set of records, in a table called Array.

In it simplest form, there are only two fields. A number field "Index", going from 1 to N. And a calc field, Display, GetValue( $$array; Index).

Now ANYTHING you put in global variable $$array will be displayed in the record list for this table.

See attached.

anythingv1.zip

Edited August 4, 2008 by Guest

[Raybaudi]

One of the interesting features of the Web Viewer is the ability to display almost anything you can throw at it.

Pardon !

Where is the Web Viewer ?

I can't find it.

[bruceR]

Pardon !

Where is the Web Viewer ?

I can't find it.

Nowhere in this file.

This is about portals and lists; and adding "show anything" features to them.

See latest version, attached, which adds transpose feature.

anythingv1.zip

Edited August 4, 2008 by Guest

[Raybaudi]

Ok, that's pretty nice.

But I don't understand why you started the topic in that way.

Or I had to know something hidden in this phrase ?

"Attached is a simple demo file that shows how to do something similar..."

I would like to know how you can obtain something similar with a Web Viever; can you show it to me ?

[Martin Brändle]

Except for changing a VIEW of something, I don't know what this technique should be good for.

One can not do a find on the portal values, because the relationship is not valid. One can do the find on the related data, which is, however, unindexed.

Especially I'm asking what would happen to performance if one had some 1000 records and not only 100. With the exception of the index field, all fields are either unstored calculations or globals. What happens if the database is hosted?

[Ocean West]

http://fmforums.com/forum/showpost.php?post/296025/

Another example too :

This allows you to merge data not necessarily found in the same table into one list and then yet display the list into a single portal.

There are many applications that this technique could apply.

For example I want to return a list of all volumes attached ( using a plugin) i get a return separated list but then I want to give the user the ability to choose one of the volumes returned from the plugin.

By putting the values in a variable or global you can create an interface where users can pick from a portal list the item they wish to choose. Multi-User as well.

Other methods of creating temporary records by user was overkill and slow. This way it's scoped for the user, if the found set of data requires more rows then you could test for that in the script and just create the necessary records.

Edited August 4, 2008 by Guest

[Martin Brändle]

This is all fine, and I understood your example and the example of Bruce in this direction.

What bothers me, is that one needs to predefine a static number x of records for a dynamic number y of list values. If y > x you will run into trouble. (ok, that answered above; like alloc() in C. )

Edited August 4, 2008 by Guest

[Martin Brändle]

Just added about 6000 names to the second example. The sorting on the unindexed field in the relationship is a performance hog.

So these examples work only reasonably with a small number of list values.

[comment]

these examples work only reasonably with a small number of list values.

Don't portals in general?

[bruceR]

Ok, that's pretty nice.

But I don't understand why you started the topic in that way.

Or I had to know something hidden in this phrase ?

"Attached is a simple demo file that shows how to do something similar..."

I would like to know how you can obtain something similar with a Web Viever; can you show it to me ?

Go to the Web Viewer section and look at what people are doing with it. Or just look at the reporting section of the Web Viewer Example file. Or look over the content of what seems like half the Devcon presentations.

[bruceR]

Except for changing a VIEW of something, I don't know what this technique should be good for.

One can not do a find on the portal values, because the relationship is not valid. One can do the find on the related data, which is, however, unindexed.

Especially I'm asking what would happen to performance if one had some 1000 records and not only 100. With the exception of the index field, all fields are either unstored calculations or globals. What happens if the database is hosted?

Well, even supposing the technique is limited to 1000 records, I'd say roughly a bazillion things.

Regarding performance, I'm not sure what layout you're looking at or which file you're referring to, mine or Ocean's.

Did you even look at the scripts attached to my file?

Examples:

Instantly grab a list of field names or scripts or layouts for a file you're interested in.

Transpose data.

Export the data as merge file.

Create value lists or selector lists.

Create reports and graphs.

In my case, I developed the technique because a client wants to look at playlist when filtered by various attributes. So I can create different category list and use a single portal to allow the user to filter items by any number of fields.

Even if you limit the technique to say 100 records, you can still page through an extremely large data set this way.

I view this mostly as a display and data manipulation technique.

[bruceR]

Newer version with CSV export feature.

anythingv1f.zip

[comment]

I would like to know how you can obtain something similar with a Web Viever; can you show it to me ?

Here's one very simple example:

http://www.fmforums.com/forum/showpost.php?post/284897/

[Raybaudi]

Thank you, comment.

I knew your example.

It seems that I have completely misunderstood this topic.

[bruceR]

Thank you, comment.

I knew your example.

It seems that I have completely misunderstood this topic.

Looks that way.

It is fairly old news that Web viewers allow you to display almost anything. That's what we learned years ago from the Web Viewer Example file that came with FileMaker 8.5. Of course those techniques continue to evolve rapidly, in interesting ways.

But the subject of THIS thread is how to do something similar

(display almost anything) using portals and list views.

Edited August 5, 2008 by Guest

[Raybaudi]

... the subject of THIS thread is how to do something similar (display almost anything) using portals and list views.

Yes...

My English isn't so good; at first read I thought that you had found a way to put a portal inside the WV ! :

[Martin Brändle]

Don't portals in general?

No, one has to differentiate.

If records of the related set are unsorted, there is no reason against using and working with a large related set in a portal. It's a view as well as the records displayed from a main table are a view.

There might even be a performance advantage if one retrieves data from a portal instead the same data from the main table in PHP CWP. This was reported in the last german FM magazine.

[Martin Brändle]

Well, even supposing the technique is limited to 1000 records, I'd say roughly a bazillion things.

Regarding performance, I'm not sure what layout you're looking at or which file you're referring to, mine or Ocean's.

Did you even look at the scripts attached to my file?

Examples:

Instantly grab a list of field names or scripts or layouts for a file you're interested in.

Transpose data.

Export the data as merge file.

Create value lists or selector lists.

Create reports and graphs.

In my case, I developed the technique because a client wants to look at playlist when filtered by various attributes. So I can create different category list and use a single portal to allow the user to filter items by any number of fields.

Even if you limit the technique to say 100 records, you can still page through an extremely large data set this way.

I view this mostly as a display and data manipulation technique.

I looked at Ocean's (Stephen Dolenski's) example.

And I had investigated your example, including the scripts, as well (before I added my critical comments here).

I fully acknowledge your's and Stephen's work. It's clear to me that these are display (and not sure, if also adequate data manipulation) techniques, that's why I spoke of VIEW above.

Problems may arise if you want to process the data further and if one is in a hosted (or multi-user) environment. Or even in web-based environment, which is multi-user also.

Data is in an unstored, unindexed calculation field. Sorting and finding may be slow.

In a multi-user environment, each user may have a local set that is very different from the set of another user, your script or your field names, for example. These very different sets, however, are assigned to the very same key values. Normalization? Let's assume the user changes something in his local list. What happens if you would like to write back the data to the host, several of the local sets? You have to take it apart by looping through a script, assign the right key values, find in the database if the record already exists or not, and may be have to create new records. It's then you doing all the data synching, not the database.

From a web perspective, the same holds true. My first thought was, that this would be a nice technique for splitting a list of keywords a user has entered into records that each hold a single keyword, by calculation only. It isn't because of the issues I raised above.

Conclusion: The technique is very nice for displaying a local, temporary view of read-only data. If it must be manipulated, one has to resort to a scripted or normalized approach.

[comment]

there is no reason against using and working with a large related set in a portal.

Speaking as a user: I don't know what to do with 1,000 records in a portal. I don't know what to do with 1,000 records in list view either - but at least that scrolls better. I do know what I would think of the solution's author though. If you want me to wade through it myself, just give a text file, thank you.

I think Bruce's technique could be very useful in some situations, and utterly unsuitable in others. I don't know why that bothers you so much - it's true for any tool.

[Martin Brändle]

Speaking as a user: I don't know what to do with 1,000 records in a portal. I don't know what to do with 1,000 records in list view either - but at least that scrolls better. I do know what I would think of the solution's author though. If you want me to wade through it myself, just give a text file, thank you.

E.g. filtering?

Browsing through large lists and serendipity might well make sense in certain cases, especially if a user does not exactly know which search terms to use and what exactly is in the database.

See e.g. the alphabet box on http://www.eqi.ethz.ch/en/

I think Bruce's technique could be very useful in some situations, and utterly unsuitable in others. I don't know why that bothers you so much - it's true for any tool.

I had learned a lot from Bruce's example. What bothered me was detailed in my previous post. We are all searchers, that's why we are here in a forum. It's here for exchange and debate.

Edited August 5, 2008 by Guest

[comment]

If a portal is filtered, then it doesn't show a "large related set" - so we are back to where we started.

that's why we are here in a forum. It's here for exchange and debate.

Absolutely. It just seemed to me you were attacking the method because it cannot do everything. No method can, so it's rather pointless. I would learn more from examples where the method CAN be put to good use.

[bruceR]

I looked at Ocean's (Stephen Dolenski's) example.

And I had investigated your example, including the scripts, as well (before I added my critical comments here).

I fully acknowledge your's and Stephen's work. It's clear to me that these are display (and not sure, if also adequate data manipulation) techniques, that's why I spoke of VIEW above.

Problems may arise if you want to process the data further and if one is in a hosted (or multi-user) environment. Or even in web-based environment, which is multi-user also.

Data is in an unstored, unindexed calculation field. Sorting and finding may be slow.

In a multi-user environment, each user may have a local set that is very different from the set of another user, your script or your field names, for example. These very different sets, however, are assigned to the very same key values. Normalization? Let's assume the user changes something in his local list. What happens if you would like to write back the data to the host, several of the local sets? You have to take it apart by looping through a script, assign the right key values, find in the database if the record already exists or not, and may be have to create new records. It's then you doing all the data synching, not the database.

From a web perspective, the same holds true. My first thought was, that this would be a nice technique for splitting a list of keywords a user has entered into records that each hold a single keyword, by calculation only. It isn't because of the issues I raised above.

Conclusion: The technique is very nice for displaying a local, temporary view of read-only data. If it must be manipulated, one has to resort to a scripted or normalized approach.

Yes, I think it is mostly about read only data and snapshots, and any issues about stale data need to be recognized.

During tests, I have found performance across a WAN to be quite fast. Remember, you're pulling a data snapshot into global fields (or variables) so it is computed locally. Sorts have been pretty fast as well, as have finds. Though it is an unstored calc it is a LOCAL unstored calc, not an unstored calc that reaches out across the graph and across the WAN.

Writing manipulated data back to the original record is something that could be done and we would need to explore carefully how it might be done reliably and efficiently.

[bruceR]

So has anybody tried the export feature on the Transpose tab? Being able to grab data and give user friendly field names to a CSV export seems kinda handy if I do say so myself.

[Søren Dyhr]

If records of the related set are unsorted, there is no reason against using and working with a large related set in a portal.

I wish to remind of when you read this anecdote the last time:

The pilot of a small plane is hopelessly lost in a cloud bank. His passenger

worriedly asks, ‘What can we do?’

The pilot responds, ‘I’ll fly a little lower and see if I can get my bearings.’ Just

then a building comes into view below. The pilot yells to a man on the roof,

‘Where am I?’

‘About 150 feet above the ground, in an airplane!’ the man yells back. Upon

hearing the answer, the pilot immediately locates the airfield and lands.

The bewildered passenger can’t restrain his curiosity. ‘How did you figure out

where we were?’

‘Easy,’ answered the pilot. ‘That guy’s answers were completely accurate, but totally

useless, so I knew he had to be a Microsoft software engineer. I quickly recognized

the airfield at Redmond, Washington, and landed the plane.’

Here's another one:

‘Remarkably, all of the well-known

computer interfaces...are designed

as though their designers expect

us to have cognitive abilities that

experiment shows we do not

possess.’

Both from the same source:

http://www.smallco.net/RestrainYourself.pdf

However do I think Albert have his quote from:

http://www.amazon.com/Inmates-Are-Running-Asylum-Products/dp/0672326140/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1218012869&sr=8-1

--sd

[Ocean West]

Here is another sample I just posted on another thread - very similar... concept...

http://fmforums.com/forum/showpost.php?post/299876/