Q:
Is possible to integrate something similar to Git, Svn, etc in Lianja?
A:
it was just as effective to install a free git client and use it against the Lianja apps and library folder.
Q:
how can I add a new page that another programmer did at his pc for the main project at my pc.
A:
Break your application down into a group of smaller apps. Save the app as a package on one PC then copy it to a shared drive on the LAN or sftp it Into the cloud or place in github.
Fetch the smaller app down and include in your main application.
You can switch between apps very quickly using Luanja.openApp() in an appropriate menu or command button delegate.
Built-in file versioning via the versions workspace too. Any files edited in an app or library file is versioned including the actual .lianja files that are used to serialize and deserialize the apps.
Lianja v3.0 includes Git integration.
Right click on Apps or Library “Files” to display a context menu which includes many common Git commands.
These are all disabled until you download and install Git from git-scm.com. (Be sure to add the Git directory to your PATH. This is c:\program files\git\bin\" on my windows development machine).
I would also recommend you download and install SourceTree for managing your git repository. You can download this free from sourcetreeapp.com.
The Git website at git-scm.com includes a complete eBook which explains how git operates and how to use it. Another good resource to help you better understand Git can be found at githowto.com.
In LIanja after you “Git Init here” from the files context menu you can perform a variety of git actions by selecting them from the context menu. Alternatively, you can select “Git Gui” from the context menu.
I recommend you create an account with github.com or use Amazon AWS CodeCommit. Both are a good choice.
The Lianja “Versions” workspace keeps versioned files for all edits you perform. You can restore from a previous version in the “Versions” workspace.
Git is a powerful version control system for Teams and individual developers. Its most powerful feature by far is “Branching” which allows multiple team members to create a new “Branch” of code, work on this and when its ready to be merged with the main codebase, use Git to merge it in and commit the changes to you code repository.
Git can work very nicely without a remote repository providing file versioning on a single developers PC. This is called “Local” Git.
In general, Git (or equivalent) for the app, and Dropbox (or equivalent) for databases, are the easiest ways to share applications among developers.
For an all-in-one solution, Sourcegear's Vault can handle app files and databases.
Git is better (once you understand it) for keeping release versions and development versions and hotfixes, etc. all straightened out.
Git integration: this is also huge, because Source Control is your software bank vault. And proper Git integration will also organize your development effort. Sure, you could do it yourself (and it was on my list to do <s>), but now we'll have it done for us. Based on the track record, I'm guessing it will be configurable and able to be customized (by you, using the basic operation hooks provided) to your development style. E.g., do you use a separate QA branch? Do you rebase before merging? etc. -- and if you don't grok those questions, aren't you glad it's being done for you?
Q:
How can I point to a deployed database from the App Builder?
For some individual developers, its possible that they may develop and deploy on a single server (not ideal - I know).
Or perhaps they develop and use the same box for UAT before deploying to a production server.
I was wondering if it's possible to open the production database from inside the app builder to get all the data definitions for comparison.
Something like
Code:Open database C:\lianja\cloudserver\tenants\public\data\Southwind
A:
The best way to handle this is take a snapshot of your database schema at the time you release version 1. You can right-click on the database name in the data workplace and choose "Copy..." then give it a name such as:
It is then just a matter of creating your own "diff" using the functions provided and creating an updatedb.prg script (possibly as the open database trigger from v1.0 of your database).southwind_v10
Each time you release a new version that has schema changes take a snapshot...
etcsouthwind_v11
You then have a general updater that will modify the schema and provide continuous delivery of schema changes by generating a new updatedb.prg and replacing it in the database.
You also have a complete history of schema changes for all versions that you have deployed.
Thats the way I would handle schema changes onto a live site.
All topics in [Answers] alphabetically:http://www.lianja.com/community/showthread.php?2717-Answers
Reply With Quote
Bookmarks