Re: Leaving the .4DB behind??
Definitely. We use git for everything - our erp source code, mobile apps source, etc. are all version-controlled, so getting structure files out as json or yaml files would bring 4d out of the 2009's. On Tue, Oct 23, 2018 at 4:39 PM Benedict, Tom via 4D_Tech < 4d_tech@lists.4d.com> wrote: > Robert says: > > >But what if the structure was that collection of files and that 4D runs as > >it always does but the github version management is always in play without > >an export? What if the .4db is simply a package that didn't have to be > there? > >Just a thought. I think at a minimum, we will be one mouse-click from > exporting > >the code, as you can see from the new v17r3 release and I'm assuming > we'll be > >able to import that same code to build a .4b from scratch. My idea saves > the > >conversion steps, all other functionality would be identical. > > I don't know anything about how v17r3 supports exporting code and forms to > a source code repository. Is it triggers by 4D Macros, like MethodHistory > which could trigger code when saving a method or is it something else? That > would be nice, but you would still need an explicit "Commit" capability. > > Ideally you could have a distributed team of developers all working on > local copies of the 4D structure, with local test data. Once their changes > are complete and unit tested they could be "checked in" to a github. From > there an automated "continuous build" process would periodically grab all > checked-in code and forms and build and deploy an updated structure to a > test server where testers would validate the changes. > > From the sound of things, we are only one step away from being able to > create this kind of build/deploy environment in 4D. This is would really > move 4D in the right direction, from an Enterprise acceptance point of view. > > Tom Benedict > Optum > This e-mail, including attachments, may include confidential and/or > proprietary information, and may be used only by the person or entity > to which it is addressed. If the reader of this e-mail is not the intended > recipient or his or her authorized agent, the reader is hereby notified > that any dissemination, distribution or copying of this e-mail is > prohibited. If you have received this e-mail in error, please notify the > sender by replying to this message and delete this e-mail immediately. > ** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ** -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Leaving the .4DB behind??
Robert says: >But what if the structure was that collection of files and that 4D runs as >it always does but the github version management is always in play without >an export? What if the .4db is simply a package that didn't have to be there? >Just a thought. I think at a minimum, we will be one mouse-click from exporting >the code, as you can see from the new v17r3 release and I'm assuming we'll be >able to import that same code to build a .4b from scratch. My idea saves the >conversion steps, all other functionality would be identical. I don't know anything about how v17r3 supports exporting code and forms to a source code repository. Is it triggers by 4D Macros, like MethodHistory which could trigger code when saving a method or is it something else? That would be nice, but you would still need an explicit "Commit" capability. Ideally you could have a distributed team of developers all working on local copies of the 4D structure, with local test data. Once their changes are complete and unit tested they could be "checked in" to a github. From there an automated "continuous build" process would periodically grab all checked-in code and forms and build and deploy an updated structure to a test server where testers would validate the changes. From the sound of things, we are only one step away from being able to create this kind of build/deploy environment in 4D. This is would really move 4D in the right direction, from an Enterprise acceptance point of view. Tom Benedict Optum This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: Leaving the .4DB behind??
But what if the structure was that collection of files and that 4D runs as it always does but the github version management is always in play without an export? What if the .4db is simply a package that didn’t have to be there? Just a thought. I think at a minimum, we will be one mouse-click from exporting the code, as you can see from the new v17r3 release and I’m assuming we’ll be able to import that same code to build a .4b from scratch. My idea saves the conversion steps, all other functionality would be identical. FWIW, Robert Sent from my iPhone > On Oct 23, 2018, at 3:36 AM, Epperlein, Lutz (agendo) via 4D_Tech > <4d_tech@lists.4d.com> wrote: > > No, I don't think so. It would be a complete different system. 4D relies on > the structure file, it is a database of code and other information, UI and so > on. ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
RE: Leaving the .4DB behind??
No, I don't think so. It would be a complete different system. 4D relies on the structure file, it is a database of code and other information, UI and so on. And it is a kind of runtime environment. If you will run the 4D code only from text files (in a uncertain future) you end up with a system of a scripting language like PHP or Javascript. But I think this all is a bit useless speculation ... Regards Lutz ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
