Problem with Set Script in Compiled App

[Richard Gaskin]

David Burgun wrote:
> Hi,
> 
> There are a number of reasons to extract the Scripts of RunRev Objects 
> into seperate text files:
> 
> 1.  We have to check files into a Source Database (Source Control 
> System) and Binary Files are not handlied that well.

Binary elements are not uncommon in databases.  It may be simpler to 
upgrade to a more robust DB.

> 2.  We want to be able to compare and exchange scripts from previous 
> versions and to track the deleteion and additions of objects to the stack.

This can be done easily in development -- why is that development task 
better served in your workflow from a standalone?

> 3.  For QA it is usefull to be able to take the latest GUI in terms of 
> appearance and swop in older scripts, to pin point where the problems lie.

Interesting idea, but if your code and your UI are that closely bound 
maybe it's time to consider factoring most of the code into libraries.

> 4.  There are lots of expensive tools (which we have) for comparing and 
> merging source code trees, exporting the scripts as files allows us use 
> them.

If you're heavily invested in "expensive tools" for this, a $99 copy of 
DreamCard to handle re-assembly seems a small addition.

> 5.  We want be able to globally replace Text across a whole stack or 
> project/application.

Why can't that be done at development time?

> 6  We want to write an "include" file pre-processor that grabs functions 
> from a Common Include file.

You may find greater overall efficiency doing includes as part of 
scripting, where you have the benefit of the script compile errors to 
point you to anything that needs attention.


Overall it seems the historical investment in tools designed for 
traditional text-only languages is where you're having dificulty making 
the parts fit with Rev.

Rev is definitely a different way of working, and while it's possible to 
jump through the hoops needed to coerce workflows designed for very 
different tools to also work with Rev, in many cases there are far more 
cost-effective ways to do the same job.

Ken Ray, myself and others have written a wide range of custom tools for 
managing small groups of developers contributing to a common project.

Chipp Walters has written one that's generalized for use with just about 
any Rev project, and it runs from any FTP server with no specialized 
server software:
<http://www.altuit.com/webs/altuit2/MagicCarpetCover/default.htm>

It may not do everything you need, but may spark ideas for Rev-oriented 
solutions to achieve the same practical benefits of what your system 
does with text-only dev tools.

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com