Hello Everybody
I would like to make a form with a portal on the left side showing all records in a table, when selecting a record in this portal showing all related records in a portal on the right side of the form, i. e. it’s a 1:m relationship (between 2 tables) where I show all records on the 1 side to select one of them (and showing the related records on the m side).
How to accomplish that?
Best regards, Robert
Bob,
Use a portal on the left side of the main form, and a tabless tabpanel to display the record form. You can use a few methods to view the selected record. I would create a global relationship (Self Join) and create a method to populate the global and attach the method to OnFocusGained event of the portal fields.
Erich
Hello Erich
Thanks for the help, I will try it. Do you know of any examples showing this?
Best regards, Robert
Hi Robert,
There are many ways to use the functionality you mention. I have attached here an example from our solution to shows a number of
different ways of doing this (i.e. using portals and/or tabpanels and/or ‘controllers’ to achieve the effect you want of choosing one record from
such a list and showing all related records). This picture does a little more than what you are requesting because it has a number of different
portals and tabpanels but perhaps it is good to have more possibilities. The LastNames have been left out as this is a true production solution
with real data inside.
To explain the picture briefly:
On the far left hand side is the custom controller which in this case lists 108 patients in a particular group. On the right hand side are the related
details of whichever patient record/row is selected in the custom controller. Even though the custom controller is not a portal I am
showing this because often times that is the best way to achieve what you are after. In this case the custom controller is made up of a ‘List
View’ of whatever records I am interested in. In this case I have selected the first record with a ‘referral’ date of ‘11/16/99’.
On the main form notice there are a number of tab panels with the selected tabs being ‘Clinical Information’, the next sub panel being
‘Treatments’ and its selected sub panel being ‘Site Details’. In the portal under ‘Treatments’ notice that the first value under ‘strxdat’ is also
‘11/16/99’. The referral date and the start treatment date (strxdat) are the same for this patient. In this case my ‘selection portal’ of treatments
is limited to this patient as that is the record I have already chosen from the custom controller. I also have this portal arranged ‘horizontally’
across the top rather than on the left because I want to give the datamanager more information before they select the record they are
interested in. The idea is the same however. Anyway here in the ‘Treatments’ tab panel I have also selected the first row. For whichever
row the data manager chooses from this portal, the related records are then shown below in the various tab panels (‘Treatment Details’, ‘Site
Details’, ‘Treatment Cycles’, etc.). If you only have one set of related records (as I gather is the situation for you), then the tab panel can be a
‘tabless’ tab panel.
Finally in the ‘deepest’ tabpanel on the left hand side I have a portal showing all ‘sites’ for this particular patient and this patient’s particular
treatment (from 11/16/99). In this case the portal is restricted by the relationship to the treatment but again this just depends on how you set
things up. In this case I have selected the second row of that portal (‘Mesenteric’). All details of the Mesenteric row are then displayed in a
tabless tabpanel to the right of that portal and each column can be updated within that tabless tabpanel.
HTH
Hi John
Thanks a lot for your answer. What you are presenting is what I am looking for. Seems to be a very interesting application.
To start with my trial application, I am still somewhat stuck at two basic requirements (my real application is also built up based on this human interface elements) I don’t know how to do best (in Servoy) and most easiest/flexible:
Form based on one table (see screenshot_01), on the left side all records of the table, showing (here) the airfield name, but could be last name and first name or school class etc. On the right side is the detail (a number of attributes). Selecting an entry in the list (left) displays the detail on the right side.
Form based on two tables, relationship 1:m (see screenshot_02), on the left side again the table on the 1-side of the relationship showing all records (here imports). On the right side is again a list, showing all records of the m-side of the relationship, when selecting an entry on the left side.
These are the basic layouts I should have an good solution for.
Best regards, Robert
Hi Robert,
So gliding in Switzerland? cool! (Lived there for six years - went to school in Zuoz - many years ago). The problem is your requirement:
how to do best (in Servoy)
Servoy is like the monster Swiss Army knife: there are so many absolutely cool tools that suggesting the best one is hard to do without knowing not only your present application but who the users are (i.e. how knowledgeable), amount of time they spend on the solution per day, etc. Plus each Servoy developer has their ‘favorite’ tools; kind of like who is the prettiest girl in the world - to each their own.
For instance in my case when I look at your first screen shot and I see that the list of records shown doesn’t even show all airports starting with ‘A’ then what comes to my mind is you do NOT want to have a scroll bar. I hate for my data entry people to have to use the mouse - slower, carpal tunnel syndrome, etc. - so everything I do is built around minimizing ‘mousing’. For example I have just built a number of global methods that can be plugged in to any Servoy solution and allows the user to navigate between ANY tab panels as well as from record to record within ANY portal without using the mouse at all. But that’s me and my choices and without really knowing your needs or your user’s needs. With those provisos I would do screen shot 01 in this way:
If the users are only dealing with one airport at a time I would probably get rid of the scrolling side panel all together. If they are sometimes working with a subset of those airports, then I would keep the panel. But in either case I would probably put it in a ‘custom controller’ form in Servoy (not sure of your Servoy experience so forgive me if I sound condescending but are you familiar with ‘custom controller’ forms yet?). And for either situation I would have probably a global ‘airport’ field with a valuelist made up of all the airports. I would have that as a ‘type ahead’ field format. If your users are somewhat familiar with what you are doing then the type ahead feature is, in my mind, the best way to display choices. It lets the knowledgeable worker arrive at their choice with the fewest keystrokes/mouseclicks while still showing the less experienced user all of the choices. (Each time the user enters such a field with each keystroke entered it reduces the number of choices available if you are not yet familiar with Servoy’s ‘type ahead’ feature). If programmatically based on some other criteria than alphabetical listing (geographic?,type of airport?), you could still show the user their ‘subset’ of choices in the ‘scrollbar’. In that case you could also have the valuelist attached to the global type ahead field change dynamically based on this ‘other’, say geographic, criteria. Does that make sense? In all of these cases we are talking about both the ‘custom controller’ form as well as the ‘detail’ form being based on the same table. The custom controller form is a ‘list view’ form to show multiple records whereas the ‘detail’ form is ‘record view’. The detail form can or can not be placed in tab panel depending on your needs
As to Screen shot 02, again I don’t really know what that (table) relationship is to the table in 01 and maybe there is none - just straight export from one FM file to another FM file. But it appears that there is some connection at least with the export column more or less the same as the importdaten column. But not knowing more about that, the very straightforward way of achieving in Servoy what you have shown would be to more or less the same as in 01. It could be done in a custom controller or all on the same form. If it is done on the same form it could be based on the parent table with one tabless tabpanel (self-joined) showing a ‘list view’ form based on that same parent table. Then there could be another (parent to child relationship) tab panel with the selected tab showing a child table in list view to show the selected parent’s child rows. There really are many, many ways to show these things.
The best way is to just start exploring! Are you coming to Servoy World? That would be a great place to find out more in a ‘networking’ environment.
HTH
Hi John
john.allen:
Hi Robert,So gliding in Switzerland? cool! (Lived there for six years - went to school in Zuoz - many years ago).
Yes, I am a glider pilot (couldn’t hide that when giving such an example .-) You visited then a very famous school in Switzerland (Zuoz) at a beautiful place. I do gliding from time to time, starting in Samedan.
The problem is your requirement:
how to do best (in Servoy)
Yes I know this is not a sufficient requirement description (by the way there is an extremly good book: Problem Frames of Michael Jackson showing how to find out about requirements, sorry this is of course off topic), but it was easy to ask for
Servoy is like the monster Swiss Army knife: there are so many absolutely cool tools that suggesting the best one is hard to do without knowing not only your present application but who the users are (i.e. how knowledgeable), amount of time they spend on the solution per day, etc. Plus each Servoy developer has their ‘favorite’ tools; kind of like who is the prettiest girl in the world - to each their own.
This isn’t done quickly by writing
For instance in my case when I look at your first screen shot and I see that the list of records shown doesn’t even show all airports starting with ‘A’ then what comes to my mind is you do NOT want to have a scroll bar. I hate for my data entry people to have to use the mouse - slower, carpal tunnel syndrome, etc. - so everything I do is built around minimizing ‘mousing’. For example I have just built a number of global methods that can be plugged in to any Servoy solution and allows the user to navigate between ANY tab panels as well as from record to record within ANY portal without using the mouse at all. But that’s me and my choices and without really knowing your needs or your user’s needs. With those provisos I would do screen shot 01 in this way:
If the users are only dealing with one airport at a time I would probably get rid of the scrolling side panel all together. If they are sometimes working with a subset of those airports, then I would keep the panel. But in either case I would probably put it in a ‘custom controller’ form in Servoy (not sure of your Servoy experience so forgive me if I sound condescending but are you familiar with ‘custom controller’ forms yet?). And for either situation I would have probably a global ‘airport’ field with a valuelist made up of all the airports. I would have that as a ‘type ahead’ field format. If your users are somewhat familiar with what you are doing then the type ahead feature is, in my mind, the best way to display choices. It lets the knowledgeable worker arrive at their choice with the fewest keystrokes/mouseclicks while still showing the less experienced user all of the choices. (Each time the user enters such a field with each keystroke entered it reduces the number of choices available if you are not yet familiar with Servoy’s ‘type ahead’ feature). If programmatically based on some other criteria than alphabetical listing (geographic?,type of airport?), you could still show the user their ‘subset’ of choices in the ‘scrollbar’. In that case you could also have the valuelist attached to the global type ahead field change dynamically based on this ‘other’, say geographic, criteria. Does that make sense? In all of these cases we are talking about both the ‘custom controller’ form as well as the ‘detail’ form being based on the same table. The custom controller form is a ‘list view’ form to show multiple records whereas the ‘detail’ form is ‘record view’. The detail form can or can not be placed in tab panel depending on your needs
Thanks for the explanations, they help a lot to start and see what can be done in Servoy. No, I don’t know the ‘custom controller’ forms yet and you do not sound condescending if I don’t know something in Servoy. In fact I just started with Servoy a couple of days ago and have to continue learning a bit beside my other work. The reason I look into Servoy is because I plan to reimplement a school administration and information system (implemented in FileMaker, unfortunatly) in a more useful way and a SQL database. I did the data design in XCode/EOModeler, so there is no problem creating the SQL schema, but the tool for the forms is not yet clear. I am also thinking about using WebObjects Java Client. Did you ever compare Servoy to another development environment?
As to Screen shot 02, again I don’t really know what that (table) relationship is to the table in 01 and maybe there is none - just straight export from one FM file to another FM file. But it appears that there is some connection at least with the export column more or less the same as the importdaten column. But not knowing more about that, the very straightforward way of achieving in Servoy what you have shown would be to more or less the same as in 01. It could be done in a custom controller or all on the same form. If it is done on the same form it could be based on the parent table with one tabless tabpanel (self-joined) showing a ‘list view’ form based on that same parent table. Then there could be another (parent to child relationship) tab panel with the selected tab showing a child table in list view to show the selected parent’s child rows. There really are many, many ways to show these things.
Thanks for all these hints, I am going to dig into them.
The best way is to just start exploring! Are you coming to Servoy World? That would be a great place to find out more in a ‘networking’ environment.
Yes, I am coming to Servoy World, on the 27. September. Hope to see you there!?
Best regards, Robert
HTH
Hi John
My reply didn’t work as intended. My comments are within your quote, sorry, a bit hard to find/read.
Best regards, Robert
Couldn’t resist a thread that includes two of my favourite subjects: Gliding & Servoy
Agree with John’s suggestions and thought a second view might also help.
Have attached a screenshot of typical Contacts screen with searchable list on RH side and primary Contact information plus related Tab panels to Notes, Tasks, Jobs, Meetings etc.
Main screen is simply a Form on Contacts database
RH panel is an unrelated Tab Panel based on Contacts but in List view.
Because the list view and main view are based on the same Table clicking on a Contact in the list automatically shows their details in the Main view. Without having to write a line of code.
The yellow box at top of list is a global Quicksearch field that provides searching on first/last name and company name. The button simply filters the list to only show Clients with current jobs.
The bottom half of the main screen shows related Tab Panels [idContact = Meetings:idContact etc] with data from the other table shown in List view.
HTH
Graham Greensall
Worxinfo Ltd
Hi Robert,
Glad to hear that you are coming to Servoy World. See you there! Be happy to spend some time looking at stuff with you if it helps…
The reason I look into Servoy is because I plan to reimplement a school administration and information system (implemented in FileMaker, unfortunatly) in a more useful way and a SQL database. I did the data design in XCode/EOModeler, so there is no problem creating the SQL schema, but the tool for the forms is not yet clear. I am also thinking about using WebObjects Java Client. Did you ever compare Servoy to another development environment?
Because someone here at Stanford wanted us to look at WebObjects, I became fairly familiar with what would be entailed in developing our solution in Servoy vs WebObjects. Again different people can have different reasons for doing things but broadly speaking these are the reasons I liked Servoy infinitely more than WebObjects for what we wanted to do:
Hi John
I take your offer with pleasure to discuss my application with you at Servoy world. I am very interested in your knowledge and comparisons WebObjects (WO) vs Servoy. I would like to reply to points 1) to 4)
I was obviously not clear enough about this. I agree with you about browser based systems, but I am comparing WO Java Client to Servoy, so the result is in both cases the same, namely a Java Client application. In WO there is Direct To Java, which creates on pressing a button a first cut user interface without any coding at all, allowing data entry/manipulation into any table of the EOModel. Faster as that is just not possible - although it’s clear this is surely not the final solution.
Speed of development: Although I have nearly no experience with Servoy, I am not sure if with Servoy development is as fast as with WO. WO is fully OO (inheriting more or less anything incl. layout parts etc.). Creating a master detail form is as easy as drag and drop the 1-side entity and m-side entity to the Interface Builder window. Buttons and logic for New, Edit, Delete Record is for free (no coding at all). There is also the Assistant in WO for finetuning the layout elements and the Rule Editor to define any logic. But of course this is quite an abstract way of developing, compared with a more traditional way in Servoy. Whereas in Servoy there one needs to create any form (with either copy paste or from scratch) but as far as I found out there is no inheritance of, say for example, for layouts or other layout elements (graphics). Is that correct?
Ease of development: I partly agree with you on this. WO has quite a steep learning curve and it’s a huge package full of tools and technologies. Finding a way to start doing something is not easy (at least for us here it’s still difficult). Do you know why Servoy uses JavaScript as procedural language, it was designed for browsers (Netscape) and we are dealing in Servoy with Client applications? At a first glance, It doesn’t look very obvious to me but sure has it’s reasons.
Cost: WO is free (now) and deployment depends on the machine. And as I have the experience (although for Web apps) developing with WO is fast (faster than with Servoy?) the cost equation is not the same as yours, i. e. more in favour of WO.
General first impressions with Servoy: The whole user interface elements are a bit quirky (at least on the Mac), like tabpanels buttons (in detail not precise) or buttons (I do not get the real Mac buttons on the Mac but a rectangular (white/translucent) button or tabpanel background should be a bit darker (get’s a bit darke with nested level on the Mac).
Best regards and thanks for the discussion, Robert
Hi Robert,
Robert Huber:
4) Cost: WO is free (now) and deployment depends on the machine. And as I have the experience (although for Web apps) developing with WO is fast (faster than with Servoy?) the cost equation is not the same as yours, i. e. more in favour of WO.
Well the development environment of WO comes with XCode, so that is free alright. But the deployment environment came and comes with Mac OS X Server. Ofcourse that is payware.
So although you don’t have to pay extra for WO you still need to buy a Mac OS X Server license.
Robert Huber:
General first impressions with Servoy: The whole user interface elements are a bit quirky (at least on the Mac), like tabpanels buttons (in detail not precise) or buttons (I do not get the real Mac buttons on the Mac but a rectangular (white/translucent) button or tabpanel background should be a bit darker (get’s a bit darke with nested level on the Mac).
To get Mac OS X pushbuttons you have to set the height of those buttons to 26-28 pixels. Anything below and higher than that will give you a rounded-bevel button.
Also make sure you set your fields that are used as an un-editable combobox to 22 pixels in height.
ROCLASI:
Hi Robert,Robert Huber:
4) Cost: WO is free (now) and deployment depends on the machine. And as I have the experience (although for Web apps) developing with WO is fast (faster than with Servoy?) the cost equation is not the same as yours, i. e. more in favour of WO.Well the development environment of WO comes with XCode, so that is free alright. But the deployment environment came and comes with Mac OS X Server. Ofcourse that is payware.
So although you don’t have to pay extra for WO you still need to buy a Mac OS X Server license.
You are absolutly right, a server is to pay (somehow they have to make money to give us the tools for free, don’t they?
Robert Huber:
General first impressions with Servoy: The whole user interface elements are a bit quirky (at least on the Mac), like tabpanels buttons (in detail not precise) or buttons (I do not get the real Mac buttons on the Mac but a rectangular (white/translucent) button or tabpanel background should be a bit darker (get’s a bit darke with nested level on the Mac).
To get Mac OS X pushbuttons you have to set the height of those buttons to 26-28 pixels. Anything below and higher than that will give you a rounded-bevel button.
Also make sure you set your fields that are used as an un-editable combobox to 22 pixels in height.[/quote]
Thanks a lot for this tip, one just has to know that! That also means that Servoy and/or Java 1.4.2 doesn’t support the small and mini controls/fields defined in OSXHIGuidelines?
Best regards, Robert
Robert Huber:
Thanks a lot for this tip, one just has to know that! That also means that Servoy and/or Java 1.4.2 doesn’t support the small and mini controls/fields defined in OSXHIGuidelines?
Servoy uses a LAF (Look And Feel) file , apparently this LAF doesn’t support mini controls.
grahamg:
Couldn’t resist a thread that includes two of my favourite subjects: Gliding & Servoyrobert:
I agree it may be a good combination, I have to check out at Servoy WorldAgree with John’s suggestions and thought a second view might also help.
robert:
Thanks for a second viewHave attached a screenshot of typical Contacts screen with searchable list on RH side and primary Contact information plus related Tab panels to Notes, Tasks, Jobs, Meetings etc.
Main screen is simply a Form on Contacts database
RH panel is an unrelated Tab Panel based on Contacts but in List view.
Because the list view and main view are based on the same Table clicking on a Contact in the list automatically shows their details in the Main view. Without having to write a line of code.
robert:
I tried it and it’s exactly what I was looking for one of my basic form/navigation I use, thanks a lotThe yellow box at top of list is a global Quicksearch field that provides searching on first/last name and company name. The button simply filters the list to only show Clients with current jobs.
robert:
Ok, good to knowThe bottom half of the main screen shows related Tab Panels [idContact = Meetings:idContact etc] with data from the other table shown in List view.
robert:
I try that later on when I find some time.Best regards, Robert
PS: Where are you gliding (in England)?
HTH
Graham Greensall
Worxinfo Ltd
Hi Robert
Gliding & tug pilot at Husbands Bosworth in Leicestershire - though currently (22:30 UK time) doing pit timing/radio for brothers car at 24hrs Silverstone GT race - only 18 1/2hrs to go…
See you at Servoy World
