Not yet available but I don’t want to keep you from the latest stuff we started working on: The Outline plugin.
The plugin will also work as a seperate application and will give you the following:
complete treeview of the repository
copy/paste of forms/methods etc between solutions
find forms/scripts etc by name
find (key-)words in scripts
printing of scripts
printing of outline
add notes
and whatever you can think of, just mail me
A preview screenshot is attached. It is in no way ready yet but it gives you a good ‘feeling’. As you can see I try to stay pretty close to what Servoy looks like
I you now rename a column, by a third party tool) you will loose all kind of connections inside Servoy, where this column belongs too!
for example, relations, valuelist, form-fields must be re-assigned again, etc..
For the methods, we have renaming tool, so that is allready possible.
Ditto for renaming servername, tablename and stylename.
In case of the first 2 when you rename them you end up with no accessible calculations. They are still there but not visible/accessible anymore.
But when you import the solution into another machine you will find it still checks (and whines about) the references of these.
Renaming a server will give potential issues with EVERY deployed solutions since renaming would require an added or renamed server to the servoy.properties file.
Changing whatever properties on a database/table will be somewhat similar. Within the repository I think there will be no issue but when the table is renamed or fields are renamed an export will create a new table and/or new fields instead of changing these with a deployed solution. Not very helpful I think…
Great idea, Marcel (it was one of my “desiderata”):
What about an “obsolete stuff reporter”? Something that indicates that a certain media is not used by none of the elements, or a method is not linked to a button or called from another method etc… Possible?
this item (script,form,element) is used by…
Also, to set properties in bulk, i.e, i want all fields to have style ‘astyle’… I want all to form’s omFindCmd set to… i never want scrollbars on labels…
IT2BE:
Hmm, should be possible. Don’t know if I can integrate it immediately but doable I guess…
Great.
It would be a very efficient way to remove the “garbage”, especially when you duplicate a solution to use it as a starting point for a similar project.
That looks so cool! I can’t wait. Copying forms and methods alone would save me so much time in migrating a current project. I’ve tried ‘reducing’ a solution (by about 90%!) to make it a module which can then be imported but this would be SO much better for that.
On Robert’s request:
Ditto for renaming servername, tablename and stylename.
In case of the first 2 when you rename them you end up with no accessible calculations. They are still there but not visible/accessible anymore.
But when you import the solution into another machine you will find it still checks (and whines about) the references of these.
I have a related question concerning just servernames and best practices:
Let’s say you have a Production, Test and Development environment kept as separate databases (I’m talking about the ‘data’ database of course not the servoy_repository database). You develop a Servoy solution using the Development environment. When you think it is ready to go you want to first test it in the Test environment and then finally deploy it in the Production environment. What is the best and simplest way to do that? Should I just temporarily ‘delete’ the named server connection that I am using for the Servoy solution (say Developer) and then, when told that that server connection doesn’t exist, give the named connection (Test or Production) that I want my solution to now connect too? I haven’t gotten to that point with this solution yet but is that the best way to do it? If that is then I think it would also be handy to be able to ‘temporarily’ delete or disable a named database connection just to force a solution to hook up to the new desired connection. Would it be possible to do that within this plugin? I can see a time when I would like to be able to simply/easily disable a connection for a while and forcing a solution to connect to a different server rather than exporting a solution with one server connection and then re-importing it as a different solution with a different server.
Maybe I have missed something, but can’t you do this from in the repository? “Replace Table”… I use it all the time.
Copy forms: Modules reduce the need for copying forms. If you still need to copy a form, add the module/project you want to copy from as module to the project you want to copy to and simply duplicate the form… References to global scripts are preserved, so use global scripts wherever possible in forms that you intend to duplicate.
**Copy scripts:**If you find yourself copying scripts, they should probably have been placed in a reusable module in the first place. Copying scripts was a big issue for me before the Servoy Developer Conference. Thanks Marcel for showing us a bag of tricks, particularly the virtual table columns
john.allen:
I have a related question concerning just servernames and best practices:
Let’s say you have a Production, Test and Development environment kept as separate databases (I’m talking about the ‘data’ database of course not the servoy_repository database). You develop a Servoy solution using the Development environment. When you think it is ready to go you want to first test it in the Test environment and then finally deploy it in the Production environment. What is the best and simplest way to do that? Should I just temporarily ‘delete’ the named server connection that I am using for the Servoy solution (say Developer) and then, when told that that server connection doesn’t exist, give the named connection (Test or Production) that I want my solution to now connect too? I haven’t gotten to that point with this solution yet but is that the best way to do it? If that is then I think it would also be handy to be able to ‘temporarily’ delete or disable a named database connection just to force a solution to hook up to the new desired connection. Would it be possible to do that within this plugin? I can see a time when I would like to be able to simply/easily disable a connection for a while and forcing a solution to connect to a different server rather than exporting a solution with one server connection and then re-importing it as a different solution with a different server.
Hi John,
use replace table in the reporitory to simply change all references to one server with another server, or, there is the databasemanager.switchserver()…
use replace table in the reporitory to simply change all references to one server with another server, or, there is the databasemanager.switchserver()
is when you have a hundred odd tables or more. Perhaps I have it wrong. But say I have a server connection that has 100 tables and that is my test or development database. I have another server connection that has the exact same tables and structure which is my production environment. I develop my Servoy solution using the test environment. When done I want to deploy it using the production environment. Of course I can export the solution and then import as the new solution pointing to the production environment. The problem there is that when one is using an ‘inherited’ database (i.e. one that you don’t totally control for one reason or another - legacy design, sharing with other apps, etc.) then there are often all kinds of things that you have to manually set up in Servoy so that it will work with it. In particular such things as columns that are set up within Servoy to be ‘row identifiers’ and the kind of things that Providence1 mentions in his current post ‘Importing Solutions reporting incorrect!’. (Importing Solutions reporting incorrect! - Classic Servoy - Servoy Community) Some things do not get exported/imported as part of a solution. So if you import that solution you have to go about changing all those things again. It’s doable, it’s just kind of a pain. The same problem exists using the ‘change table’ dialogue in repository. At least that is how I see it/understand it.
So my thinking was this without Marcel’s plugin:
Create my solution in the test environment. When done delete the server connection (temporarily) to the test environment and then when loading the solution and asked about it, point the solution instead to the production server connection. Then when I wish to develop the solution further, load a new release (not activate for clients but just load in Developer) but before that temporarily disable the ‘production’ server connection in Servoy. So when loading/starting the new (Developer) release within Servoy, it will be pointing to the test server yet the ‘active’, client release will still be pointing to the ‘production’ release. When done with the new additions/changes to my Servoy solution, then change the ‘new’ release to be the active release after first temporarily disabling the ‘test’ server thereby forcing a switch to the ‘production’ server.
What I was thinking with Marcel’s plugin is that perhaps that could be done directly within that plugin environment. In other words somewhere within the Servoy repository all ‘named’ connections are stored. As long as you are sure that two different named connections have the identical database structure, then in theory one could just change that named connection for a solution without having to export/import a solution, forcing a new connection or ‘replacing’ all tables. If the database structures are different then you might run into problems with this approach and would be better off exporting/importing. But I find it is pretty easy to check/compare two database structures. I run the script generator in Aqua Data Studio and then run the ‘compare’ function within BBedit and that shows them pretty nicely.
john.allen:
The problem there is that when one is using an ‘inherited’ database (i.e. one that you don’t totally control for one reason or another - legacy design, sharing with other apps, etc.) then there are often all kinds of things that you have to manually set up in Servoy so that it will work with it. In particular such things as columns that are set up within Servoy to be ‘row identifiers’ and the kind of things that Providence1 mentions in his current post ‘Importing Solutions reporting incorrect!’. (Importing Solutions reporting incorrect! - Classic Servoy - Servoy Community) Some things do not get exported/imported as part of a solution. So if you import that solution you have to go about changing all those things again. It’s doable, it’s just kind of a pain. The same problem exists using the ‘change table’ dialogue in repository.
I see. Yes, I have the same issue when I set up new tables in PostgreSQL using Aqua data studio on my development connection. I move new tables manually across using Aqua and set up the sequence/pk info again in Servoy. From that point onwards though, I let Servoy manage any new fields on its own.
john.allen:
So when loading/starting the new (Developer) release within Servoy, it will be pointing to the test server yet the ‘active’, client release will still be pointing to the ‘production’ release. When done with the new additions/changes to my Servoy solution, then change the ‘new’ release to be the active release after first temporarily disabling the ‘test’ server thereby forcing a switch to the ‘production’ server.
What I was thinking with Marcel’s plugin is that perhaps that could be done directly within that plugin environment. In other words somewhere within the Servoy repository all ‘named’ connections are stored. As long as you are sure that two different named connections have the identical database structure, then in theory one could just change that named connection for a solution without having to export/import a solution, forcing a new connection or ‘replacing’ all tables.
Why don’t you just re-point the connection in Server Preferences. You keep the name the same, put point it at another database. I have two Servoy preferences for each project. One Dev and one Live. I export out of Dev, quit, start Live and import. The connections have the same names.
john.allen:
But I find it is pretty easy to check/compare two database structures. I run the script generator in Aqua Data Studio and then run the ‘compare’ function within BBedit and that shows them pretty nicely.
Implemented as ‘Call Stack View’.
Will show you all Objects that make use of the selected Object in a direct context and even indirect (Hierachical View)
