Building data base aps with Rev (Tuviah M Snyder)

Jan Schenkel janschenkel at yahoo.com
Sun May 25 13:49:00 EDT 2003


--- Sadhunathan Nadesan <sadhu at castandcrew.com> wrote:
> [snip]
> 
> Yo!  Let's keep this thread alive.  Really happy to
> see you have joined
> the discussion Tuviah.
> 
> Swami explained to me how to find the undocumented
> API so I was able to
> browser around in there and understand a bit more of
> what Jan was up to.
> I'm really hoping he will make us some simple
> master-detail form as an
> example but I realize it is a lot to ask.
> 

Hi Sadhu,

I wasn't planning on letting this thread die a slow
and horrible death, forgotten in the vast archives of
the RunRev webserver ;-)
Unfortunately, I've been trying hard to make MySQL
behave like it ought to ; and believe me, tracing an
intricate thing as the 'revDatabase' frontScript is
not a pretty sight, heh.
But I am working on a simple master-detail form sample
stack ; hopefully somewhere in this coming week, it
will be up on my website.

> Now, I wanted to post my progress so far.  My first
> posts about DB aps
> were .. I couldn't even connect!  I have come much
> farther so those
> of you trying to write data base apps, keep trying! 
> It does work.
> 

Well it better work, or I've been wasting a few months
of work ; not to mention what Tuviah has been working
on so hard *grin*
Just kidding, the main thing to keep in mind is that
this isn't FoxPro or 4D or FMPro ; once you realise
it's a general-purpose development tool with strong
roots in multimedia, but wide support for other
technologies, you'll be able to combine these in ways
that you wouldn't have thought of when you used the
classic RDBMS tools.

> At this point I have progressed through the help of
> Jan, Geoff and others
> to actually having a working applicaton.  Ok, it's
> rather trivial but
> it's useful for me.  I will post the code (below) in
> case anyone might
> find examples helpful.  Naturally the server name,
> login, password etc
> have been changed to protect the innocent.
> 

Okay, I've snipped the code and am just passing a few
observations :
- the 'merge' function is your friend ; it has made my
code a lot more readable and shorter ; no more put
after, or weaving replace commands
- there's no need to clone individual cards ; simply
save the data if necessary through an 'UPDATE'
command, and refresh the fields on the current card
with the data from the next record -- saves memory and
avoids clutter when you 'save' a new version of your
stack.
- use the 'revDataFromQuery' function if you need to
simply build a list and place it into a field (e.g. in
the 'audioList' and 'transcriptList' handlers)
- overall you seem to have learned a lot in a very
short time ; congrats :-)

> First I would like to mention a conclusion so far -
> the query builder
> is ok at the testing state to prove you are
> connecting to a data base
> and getting back data, after that, you have to write
> handlers to make it
> actually do useful work so why not add one or two
> more lines of code to
> include the query?  In other words, it's an ok start
> but ends up being
> too much trouble without more functionality.  This
> is not exactly a
> complaint, more like, expressing hope for more
> features in the future,
> a truly useful query builder.
> 

I'm sure the good people at RunRev HQ will be more
than willing to listen to our suggestions for future
additions and enhancements -- but I'm equally sure
they want to ship the final version and take a week
off ; and after that, we can start poking them :-)

> I found my programs kept hanging up when the query
> builder was trying
> to do something automatic, it was erratic with
> queries sometimes being
> connected, sometimes not.  So I dropped it and then
> things started
> working much better.
> 

Here's a tip : do not try to 'place' a query
background group on a card for debugging purposes ; it
will keep quite a few bits from working properly.

> Here's my real wish for the future - an automatic
> screen builder.
> Just give this thing a record type, and connection
> info, and it builds
> a card with all the fields from the record ready for
> data entry, labels
> matching the field names, and
> add/modify/inquire/delete buttons ready
> to go.  This is very realistic, meaning, technically
> feasible, not some
> wild impossible dream.

True, and that would be combined with fields that
check their input, format it, etc. Pretty sure it has
crossed their minds and is on the list for one of the
next versions.

> [snip]

Okay, I've snipped the code and am just passing a few
observations :

- the 'merge' function is your friend ; it has made my
code a lot more readable and shorter ; no more put
after, or weaving replace commands

- there's no need to clone individual cards ; simply
save the data if necessary through an 'UPDATE'
command, and refresh the fields on the current card
with the data from the next record -- saves memory and
avoids clutter when you 'save' a new version of your
stack.

- use the 'revDataFromQuery' function if you need to
simply build a list and place it into a field (e.g. in
the 'audioList' and 'transcriptList' handlers)

- overall you seem to have learned a lot in a very
short time ; congrats :-)

Best regards,

Jan Schenkel.


=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com



More information about the use-livecode mailing list