Is it possible to have portals inside portals?
Or are there other work arounds/toos for dealing with relationships, two or three levels deep?
Regards,
Lee Snover
No, portals in portals is not possible, but tabpanels in tabpanels is possible! So two or three levels deep, is not a problem!
Hope this helps
HJK:
No, portals in portals is not possible, but tabpanels in tabpanels is possible! So two or three levels deep, is not a problem!Hope this helps
I don’t think tab panes are going to do it for me. I need something analagous to repeating fields in my portal. I was told I would need to use a related file, instead of repeating fields, since they don’t exist in Servoy/SQL. Hence the need for a portal in a portal.
Is there a Java Bean or other object that would allow me to emulate a repeating field easily from within a portal? Is there some type of array object that can be displayed?
Thanks,
Lee Snover
You can simply create a form in LIST VIEW and then show that in the tabpanel.
To “simulate” a repeating field - you can do multiple relations to the same data and show multiple field on that single line in the list view.
OR
You can show a portal in the list view.
Cheers,
Bob Cusick
I thought I read somewhere that it was not a good practice to have tabpanels displaying list view? I that is the case, what are the disadvantages?
bcusick:
You can simply create a form in LIST VIEW and then show that in the tabpanel.To “simulate” a repeating field - you can do multiple relations to the same data and show multiple field on that single line in the list view.
OR
You can show a portal in the list view.
Cheers,
Bob Cusick
Bob:
THanks for the ideas. I don’t think they would present visually the way I need, unless the fact that the field is in a tab could be made totally invisible to the user.
What I have is essentially a series of 120 repetition, repeating fields (about a dozen fields, mostly numbers, a few text), they essentially make up a very specialized calculator with various pieces over time (think amortization table but more complex). These calculation fields are never really searched on, they are only relevant at the detail level in context of the parent record. In my app, I have multiple “sets” of these records per Parent record, so it represents a tremendous amount of data. Filemakers repetition fields are ideal for this actually with a few exceptions.
In SQL, I would make a record that has columns for each of the 12 or so repetition sets, and then build a block of 120 records to build out the “calculation grid” if you will.
On my main window, I have a parent record, then I have a child record that holds summary info. from a set of grandparent records. In Filemaker, the Grandparent is the one with the repetitions defined. In SQL, I have to go another layer Great Grandparent to handle the calculation portion and link up to the next level. I only show the first 20 repetitions of each Grandparents primary repetion in the main window, but I have to get down to that level in the main window.
If we can meet at Devcon, I’ll show you what it looks like in FM7, and maybe it will make more sense and you can offer suggestions. It’s a beast, and that’s why I’d like to get it into a SQL environment if possible. But I have to maintain the ease of use and Filemaker “interface” style to keep my superiors happy.
Thanks,
Lee Snover
Hi Lee,
WOW. What a BEAST.
Let’s do hook up in Phoenix, and I’m SURE we can come up with something…
(THINK HTML )!
Jan Aleman and I will be there from Thursday (tomorrow) to Thursday. You won’t be able to miss us… we’ll be the guys in the Servoy shirts (at the bar or in the pool).
Cheers,
Bob
bcusick:
Hi Lee,WOW. What a BEAST.
Let’s do hook up in Phoenix, and I’m SURE we can come up with something…
(THINK HTML )!Jan Aleman and I will be there from Thursday (tomorrow) to Thursday. You won’t be able to miss us… we’ll be the guys in the Servoy shirts (at the bar or in the pool).
Cheers,
Bob
Bob:
Will do. A Beast it is. It’s amazing we have a working version in Filemaker 6! It’s messy though. FM7 has been easier, but still fighting many workarounds and I would like it to work in IWP.
The biggest problems with FM7 are the lack of indirection just about everywhere, and performance is still totally for the birds with large data sets.
Look forward to meeting you in Phoenix. I’ll be in mid day Saturday.
Regards,
Lee
ebrandt:
I thought I read somewhere that it was not a good practice to have tabpanels displaying list view? I that is the case, what are the disadvantages?
I use tab panels for just about everything – record, table and list views. In fact, quite often my interfaces is one record in an “interface” file and all the application data is accessed via tab panels using one parent interface. I hide tabs and use my own tabs generally to get a consistent look between platforms. I have whole solutions where you stay in this one interface and the tab windows can sometimes be up to four levels deep. A good knowledge of relationships and how to load record sets is key.
The advantages are less GUI work, a cleaner look, more information on one screen (which I think is important), less clicks for the user in general, and easier code management.
This is analogous to the “one-file” coding approach in FM6. Minus the 3 billion relationships (and the corresponding calculated fields) and having to deal with record locking on your own. In web terms, it is similar to using a templating system to build your pages.
The tab panel is one of the most powerful features of Servoy IMO – I rarely use a portal at anymore.
Post what you guys come up with. I’m sure it will involve tab panels (and maybe some portals in a tab panel) and I’m sure it will be a whole lot more elegant (and faster) than your FileMaker versions.
- David
david:
ebrandt:
I thought I read somewhere that it was not a good practice to have tabpanels displaying list view? I that is the case, what are the disadvantages?I use tab panels for just about everything – record, table and list views. In fact, quite often my interfaces is one record in an “interface” file and all the application data is accessed via tab panels using one parent interface. I hide tabs and use my own tabs generally to get a consistent look between platforms. I have whole solutions where you stay in this one interface and the tab windows can sometimes be up to four levels deep. A good knowledge of relationships and how to load record sets is key.
The advantages are less GUI work, a cleaner look, more information on one screen (which I think is important), less clicks for the user in general, and easier code management.
This is analogous to the “one-file” coding approach in FM6. Minus the 3 billion relationships (and the corresponding calculated fields) and having to deal with record locking on your own. In web terms, it is similar to using a templating system to build your pages.
The tab panel is one of the most powerful features of Servoy IMO – I rarely use a portal at anymore.
Post what you guys come up with. I’m sure it will involve tab panels (and maybe some portals in a tab panel) and I’m sure it will be a whole lot more elegant (and faster) than your FileMaker versions.
- David
David:
Thanks.
Any chance you will be at Filemaker DevCon?
I’d love to see what you have put together.
Regards,
Lee
I agree 100% I use them for everything too, It’s nice being able to take up alot less room on a form and organizing it better. I thought that I had read somewhere that using list views in portals was not a good pratice, I use them anyway though.
Erich
Got in yesterday. Something about drinking with Bob and Jan that drew me like a moth to a flame…
david:
Got in yesterday. Something about drinking with Bob and Jan that drew me like a moth to a flame…
Gee, all you Servoy folks going to Devcon, isn’t that like Democrats sneaking into the Republican convention?