On Fri, 3 Dec 1999, Hugh Senior wrote:
> Scott wrote:
> >Sounds like a recipe for spaghetti to me. What happens when the
> >source field changes, do all fields that point to it have to be
> >live-updated with it? And what if you change the field, does the
> >"sourceField" get updated? What happens with fields with sharedText
> >set to false, do you have to specify the card? And the biggest
> >question: What would this be useful for?
>
> I don't think this is a recipe for spaghetti, Scott, just an extension of
> the sharedText property notion. The idea is similar to setting up a
> relational field in FileMaker as in "::Address1" with the ability to link
> the text contents of one field by reference to changes made in the text
> contents of another field (so that changes made in the "sourceField" are
> live-updated in their "aliases" automatically). Changes would be one-way
> only so any "alias" field would effectively have its lockText and
> sharedText set to true.
>
> set the icon of btn 1 to <image id>
> set the sourceText of fld 1 to <fld id>
There's a big difference between text and icons, though, and that's
that you'd expect to be able to edit the former in the field. If
you're willing to give that up, the problem is much simpler and the
potential for spaghetti much lower.
> The reason for this? Setting up relational fields. Phil suggested using
> htmlText, and both Dave and Mary suggested using a preOpenCard handler to
> re-build field contents on-the-fly. However, since each record in the
> system has multiple and independent address sections comprising over 30
> fields in total and all have to searchable, I have had to implement
> relationship tables (triggered on closeField in each "source" field) for
> live-updating of all related "alias" fields on all related cards. It now
> works very well, but was truly horrible to do and would have been so easy
> with a sourceField property.
I'm still a little unclear how this would work. It sounds like it
would only be useful if the source fields were all in some other
stack, which means you need three bits of information to do the
linking, the id of the field, the name of the stack it's in, and
probably the id of the card its on. Or would all source fields also
have to have sharedText set to true?
With all the limitations of this "source field" architecture, why not
just use a custom property array? Data storage and retrieval would be
a lot more efficient doing it that way. I've got nothing against
building database applications in MetaCard, but though it may sound a
bit blasphemous, I *don't* think using the default card/stack
architecture is the right way to do it (no indexing, inefficient
storage because of the need to store extra stuff like card objects and
style runs, no way to build relational capabilities, etc.)
Regards,
Scott
> /H
>
> Hugh Senior
>
> The Flexible Learning Company
> Consultant Programming & Software Solutions
> Fax/Voice: +44 (0)1483.27 87 27
> Email: [EMAIL PROTECTED]
> Web: www.flexibleLearning.com
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
