Array Coolness

[Josh Mellicker]

Bob,

An approach we use is to:

1. populate a table field on a card on a hidden stack with the data  
from the DB (data object)

2. render a list (or more often, a scrolling group-of-groups with each  
group representing a single row) for the user to see and interact with  
(display object)


This way, we don't have to worry about hiding columns, since they're  
all in the data object, and any updates the user makes to the display  
object are automatically mirrored to the data object.

This may sound kludgy at first glance but it gives the developer such  
a wonderful degree of flexibility when designing the display object,  
yet handles all data needed in the hidden data object.

For example, just like Filemaker, one record (one group in the group- 
of-groups) could contain option menus, text fields, buttons, label  
fields, popup calendars, whatever, for the user to interact with.





On Mar 4, 2009, at 9:32 AM, Bob Sneidar wrote:

> Hi Len.
>
> It would be easier to hard code a query if I was coding for a  
> specific application that only did one thing, but I am making  
> generic functions to query the database based upon fields that I  
> have dropped into a form using a Field Dropper utility I made. The  
> idea is to be able to query a database table for it's structure,  
> allow the user to pick a field and what kind of field he wants it to  
> be, select some options (like List Visible for example) and then  
> "drop" that field into the form with a set of custom properties that  
> will determine how the field behaves on the form and in lists. The  
> fields have the same name as the table columns with an "f" prepended  
> to them, so if I know the field name I know the column name.
>
> The functions to do all this are generic so that they can work with  
> any form built from columns in any database. I am building more than  
> a specific application to do a specific thing, I am building a  
> framework of functions and utilities that will work much like  
> Filemaker when I am done, so I avoid any application specific  
> coding. My functions don't know (and don't care) what the actual  
> columns are. Their visibility in any list is determined by whether  
> or not the column has a corresponding field in the form, and if it  
> does, whether or not the ListVisible property is true. I set this  
> property in the Field Dropper utility.
>
> Some fields are ALWAYS invisible (such as the deleted flag, the  
> unique id, and the signature lock). But they have to be part of the  
> data returned from the query so I can check those values against any  
> new values before I write anything back to the tables. It's just  
> sooooo much simpler to script a query on the fly using "SELECT *  
> FROM" and then rearrange the columns for the list view as needed.
>
> Bob Sneidar
> IT Manager
> Logos Management
> Calvary Chapel CM
>
> On Mar 3, 2009, at 1:51 PM, len-morgan at crcom.net wrote:
>
>> Wouldn't be MUCH easier to just ask for the data you want in the  
>> order you
>> want in your query and not have to worry about diddling with  
>> arrays?  For
>> example:
>>
>> SELECT f1, f2, f3, ... fx FROM myTable -- Gives you the same as  
>> SELECT *
>>
>> SELECT fx, fy, f3, f1, f2 FROM myTable -- Gives you back the fields  
>> in the
>> specified order
>>
>> Just my two cents' worth
>>
>> len morgan
>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution