Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community

At 14 JAN 2008 11:20:09PM Martin Drenovac wrote:

Mike, I need for you to develop and 'idiot' proof rdkinstall.

I had the pleasure of upgrading a client who was on a system 12 months behind everybody else. And whilst that's not a real problem, the issue was that we wrote a few 'customisation' for this client.

Well, what happens when you upgrade a system? you of course nuke the customisations.

Which brings me to why I love AREV. In Arev, we used to create CUSTOM-BP, and off course attach BP, and then attach CUSTOM-BP so these 'idiot' issues would never hurt us. Keeping track of the source was easy also, it was all in CUSTOM-BP, so it would never collide with BP.

So, can you invent a CUSTOM-REPOSITORY for me, so that I don't inadvertantly stuff up again? OR as an interim because there'll always be a fool like you Martin - can someone assist me to the MFS so that I can store all of our developer code into an SVN respository - I believe you (mike) mentioned someone had done this when last you visited here in sunny Sydney.


At 15 JAN 2008 06:03PM David Goddard wrote:

G'day Martin,

If you want to customize you app for each client, why not create a new application for the client, that inherits your base application. You can then upgrade your base application without nuking your customizations.

We can talk more about it at the up coming training session.

Dave G


At 16 JAN 2008 04:52PM Paul Rule wrote:

This is what we do. We find it works well.

If you are doing customisations for multiple clients then you can use your one development system with multiple sub accounts each for a different client. I have around 150 accounts on my system with no problems. It stops you getting each client's customisations mixed up and keeps the core system separate as well.


At 17 JAN 2008 11:54AM DSig wrote:

Inheritance is a wonderful thing


At 18 JAN 2008 03:55PM Martin Drenovac wrote:

Guys, not to rain on your parade. Inheritance is not inheritance - when I change something in the parent it does not perculate down. And, whilst we have made the same approach initially it just became too much work to manage. But thanks for the time to drop a note.


At 18 JAN 2008 05:21PM John Bouley wrote:

Actually, when you make a change in a parent application it does inherit down the chain unless the child application has the same entity. Then the child takes precedence. I use it all the time.

John


At 18 JAN 2008 06:59PM [email protected] wrote:

Sorry John that isn't inheritance.

I remember in the design meetings for OI we were arguing as to whether this could be called inheritance as it was basically copying. It was decided that "OpenInsight has chosen to implement inheritance by a copying mechanism" or words to that effect. What OI has is a neat feature but it can only be called inheritance if you aren't used to real inheritance.

Several design compromises had to be made to take into account the speed of the then hardware. Originally the repository was going to allow you to define any set of entities as an entity and this superset could be used anywhere else. So for example you could define an address entity as being Street (Editline), City (Editline), State (Dropdown) and Zip (editline) and then just drop the address entity onto a form. Changes in the underlying address entity would ripple through all forms using it.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft


At 19 JAN 2008 12:15AM Bob Carten wrote:

What OI has is a neat feature but it can only be called inheritance if you aren't used to real inheritance.

Well put.

We can write object-like programs ( stored procedures ) using some naming conventions plus variable-named commons, but currently our tools do not help you implement or navigate any object hierarchy.

Anybody familiar with functional programming? ( see http://www.defmacro.org/ramblings/fp.html ). Basic+ is not a functional programming language. But Basic+ has statements like "call @myproc(p1,p2)" and "val=function(@myfunc(p1,p2))" which allow you to pass around program names, and Basic+ and functional programming techniques favor flat rather than hierarchical calling chains. Might be a source of some ideas for us.

call @subname(p1,p2)

and

result=Function(@funcname(p1,p2)

At 21 JAN 2008 02:57PM DSig wrote:

Seems line the next thing for you to do Giving real inheritance.

I agree that it isn't "true inheritance" but it does help the process. Maybe we should call it "Ugly Stepchild"

View this thread on the Works forum...

  • third_party_content/community/commentary/forums_works/2cf3dc2dec244d12852573d10017d148.txt
  • Last modified: 2024/01/04 20:57
  • by 127.0.0.1