Another way to ask this question might be, "How flexible can the app's UI be"? I realize that's a fairly nebulous question, so I'll try to be more explicit.

First of all, I love the concept of FS. I love the interoperability of the apps created from Apex but they don't tell you up front how much Java, HTML, and CSS you need to know to create a polished app.

I can see that FS can create app UI that matches underlying normalized data structures. That is good and it solves many app challenges. But sometimes you need to go beyond that and I'm wondering if FS is up to the task at this point. Here's an example.

Let's say you have an app that manages the information pertaining to track meets. Thus, you may have a table structure such as this.

participant -> entered_event <- event (entered_event is an associative table)

i.e. Every participant can enter many events and each event can have many participants.

Instead of making a master-detail form, let's say the meet director wants to see contestants and entered events in a grid structure. Like this.

Participant 100m 200m 400m 800m 1500m 10K ... Bob Smith X X Harold Jones X X Sam Wilson X X

The values in the Participant column are from the participant table. The values in the other column headings come from the event table. The X characters represent check boxes. With a grid like this, it's extremely quick and easy to enroll participants in various events with the number of clicks equaling the number of events that they enter. Each time a check box is checked, a row is inserted into entered_event.

Accomplishing this in Apex would require a significant amount of custom code. How difficult would something like this be in FS?



asked 24 Feb '14, 22:41

klm2klm2's gravatar image

accept rate: 0%

Hi Klm,

Excellent question.

I'd create a view that represents the data shown in the grid where some columns in the view represent events. Then I'd create instead of triggers for the view and update the appropriate underlying tables when the checkboxes are checked/unchecked.

You are adding a complexity to the app, and no tool can make this complexity disappear. It just can make it easier to deal with.

In this solution, we are pushing most of the complexity down to the model layer into the creation of the view and its instead of triggers. Your challenge would be to create a query where you pivot event rows to columns. Oracle can do pivots easily, if the columns after the pivot can be known beforehand. For example, if this was a pivot where each day in the week was a row and you wanted to turn each day to a column, that's easy to do because you know the seven columns already.

In your case, knowing the number of events might not be possible. But if you have a good estimate for the maximum number of events that there can be, you can code your view for that maximum number of events. In most cases reasonable maximums can be set. No user can update 10,000 events in a grid can they? (even if there are that many events)

Then in the app, we can show and hide grid columns based on whether a column indeed represents an actual event and set the visible grid column headers correctly. (another complexity we have to deal with.)

Hope this helps,

Kind Regards, Yalim


answered 25 Feb '14, 01:24

Yalim's gravatar image

Yalim ♦♦
accept rate: 22%

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: 24 Feb '14, 22:41

Seen: 723 times

Last updated: 25 Feb '14, 01:24

© Copyright Gerger 2017