How was it done before version 4 then?
Hi Patrick
It was the same.
Best regards, Robert
ptalbot:
How was it done before version 4 then?
But there was no concept of workspace then, so how was it done?
How could you achieved what Johan is explaining here: managing different datasources/users/styles for different end clients??
Ah, I understand what you mean, but don’t know how it was done as at that time we had only our first app in development. And wit one app the problem doesn’t arise.
Regards, Robert
ptalbot:
But there was no concept of workspace then, so how was it done?
How could you achieved what Johan is explaining here: managing different datasources/users/styles for different end clients??
ptalbot:
How was it done before version 4 then?
This was how it was done in 3.5 (article is 1.5 years old and targeted to our frameworks developers). It is done the same in 4.x with workspaces. It works simple enough for us – we literally have dozens of workspaces and sharing (and versioning!) is MUCH easier than in 3.5. Of course, we have our own security module so don’t use Servoy’s default security stuff which makes things a lot simpler. In my opinion, if you’re running multiple clients from one server you should roll your own SaaS-level security. Servoy’s security is a pain for managing more than a few users at a very basic level.
MANAGING ALL OF YOUR SERVOY SOLUTIONS
==============================
What's inside:
1) How did this happen?
2) The Problem
3) Solution and benefits
4) How to implement
5) Summary
6) Bonus
1) How did this happen?
Servoy is an amazing tool for solving problems. So much so that it is common to find yourself with a repository packed with a sundry of solutions. An Filemaker Pro data importer, an HTML method colorer, an batch mail solution, the main project for your company, a simple solution to track all of the pin whole leaks you've fixed in your house this past year, etc. (I was even working on a Tetris game at one point.)
Then there are all the random solutions with weird names like "ztest", "trashme" and "tempxyz" littering up the place. Not that you can delete any of them in case one of them contains that all important code snippet you've been looking for for the past 20 minutes.
Then there was that annoying Servoy bug several months ago that you couldn't quite isolate after repeated postings to the forum and several trips to the drug store for the little rage pills. You finally get a working non-working example put together in a nice tidy solution that you sent off to Servoy support. This solution was called, "seeitoldyouso." In the process you also created solutions "imnotsureifthisisit" and "whywontthisbugshowupnow".
Then there was a point when you figured you were finally hot stuff at Servoy and you decided to start answering forum questions. But you weren't quite confident enough to answer without a little testing of your own first. These solutions are typically named "igotdaanswer", "thatdudeissostupid", "toosimple", etc. (The day you accidently stuck your own foot in your mouth you don't celebrate by creating a solution called "imsuchanidiot".)
Then you decided one day to split "the main project for your company" into modules in an attempt to organize that solution better. You end up putting the navigation in the wrong module, spend days trying to figure out which modules to include in each other, and forget one morning before coffee which module opens the whole solution...but we can save all this for another tip. The end result: a bone collection of modules -- some working, some just hanging out and making your life miserable by luring you into opening them by mistake. Repeatedly. Sucker.
Of course you have also been faithfully doing the version release thing all along as well. This leads to the always fun: "I know I made that screen in module x of solution y. Now let me see...what release was that in...."
2) The problem
The Servoy repository screen is an alphabetical listing of all your solutions. That's it. You don't get to reorder them, categorize them, describe them, or take a peak into the contents without opening them. At one point, Servoy started putting the date beside each release (I think it was version 3.something). Given the magnitude of how limited the functionality of the Servoy repository screen is, this tidbit practically made me suffocate from laughing the day I noticed it.
3) Solution and benefits
A. Divide your solutions up
My Servoy life became orders of magnitude easier the day I started dividing my solutions into their own instances of Servoy. Put all of your testing apps in one instance, some utility apps in another, the solution that runs your website in another, all of your client solutions each in their own instance, etc.
The main reason we recommend installing Frameworks into a new repository is because it currently weighs in at 13 modules (and we still have a few more to go in the base release). Simple put, we don't want you to add all those modules into a repository with other important stuff -- it will just confuse your life.
B. Use naming conventions
This is almost a requirement if you are using modules. Any naming convention is better than nothing. Something, anything -- to organize the repository list so you don't have to go hunting around to find the module you want to work on.
We go one step further and put a short unique identifier tag into each module name (in CAPS). We use this identifier to preface all object names in that module that so that there is no chance of getting conflicting names when we combine various modules. Forms, calculations, relationships, value lists, global variables, etc.
C. Versioning
I keep releases to a bare minimum. You can't edit past releases, it's impossible to tell which release has what in it, you can't compare releases, and rolling back a solution with 15 modules is pain. The only reason I have releases is when I import modules I get back from other developers on a project.
Instead, I keep multiple snapshots of a client solution -- each in their own repository. Besides being easier to identify what version does what, I can open multiple versions at the same time and compare differences.
D. Point multiple instances of Servoy developer to the same repository
Do this one as needed. In my case I do this all the time! Why? So I can work on multiple modules (and even different screens in the same module) simultaneously.
Say I need to create a report in the report module. The requirements may be to add another field to a table. At the same time I will want to add this field to the work flow module that handles data entry for this table.
When using this technique, just restart both Servoy developer instances often to sync up the changes.
4. How to implement
When I started writing this tip I had no idea I would write so much before getting to this point. But it all just poured out! Which is to say that what follows is very simple once you get the hang of it and well worth doing over and over until you can set up a new instance of Servoy in under a minute.
Here are the steps:
1. create new databases
2. duplicate Servoy developer application
3. duplicate servoy.properties file
4. assign new servoy.properties file to new Servoy developer application
5. re-point your database connections to the new databases
1. Create new databases
Typically you will have a repository database and a database for your solution data. When using our frameworks also have a frameworks and example databases. (The Servoy default install has a few more as well.)
I use the free Mysql Administrator application for this job. Whatever your backend flavor is, get an external tool to manage it with. You cannot create new databases from within Servoy.
Again, using a naming convention for your databases is a good thing. "client1_repository" and then "client2_repository" for the next version makes things simple.
2. Duplicate Servoy developer application
Just duplicate in place and rename it. "Client1" or whatever.
3. Duplicate servoy.properties file
Same thing. Call it client1.properties.
4. Assign properties file to a Servoy developer
By default, Servoy developer keeps all of it's properties in the servoy.properties file. If you duplicate Servoy developer, the duplicated application is still pointing to the servoy.properties file. This is a good thing if you want to run two developers on the same solution (benefit D above).
How to do this varies by platform. Check out this post by Edward Callaghan on Servoy Magazine. For windows users, read the comments:
http://www.servoymagazine.com/home/2005/05/tip_how_to_run_.html
What isn't covered in this post is that you can also rename the "Servoy" string in the title bar to anything you want -- say, "Client1". Which makes it easier to identify which developer instance you are on when you have 5+ of them open.
It's in this section of the plist file:
<key>CFBundleName</key>
<string>Servoy</string>
5. Re-point database connections
At this point, when you start up your new developer you are still pointing to the databases that your source properties file was pointing to (since you duplicated it). Go into Servoy preferences and re-point things and restart. If you changed the repository connection to a new database you will be prompted to rebuild the repository tables.
Now you have a blank slate to work with. Easy beans.
5. Summary
Servoy's repository screen still has a lot evolving to do. If you are working on many solutions you gain a number of benefits by separating your solutions into multiple repositories. Not the least of which is keeping better organized!
You can also use this technique to do basic versioning and develop in multiple related modules (or even the same module) at the same time.
6. Bonus
If you want to go to the next level of version control, check out Jeff Bader's comment (1st one) to this Servoy Magazine post:
http://www.servoymagazine.com/home/2007/12/commentary-serv.html
david:
This was how it was done in 3.5 (article is 1.5 years old and targeted to our frameworks developers)…
Hi David!
Thanks for sharing, that’s great info. I’m convinced that a separate workspace is the way to go now.
Actually, I was already using a separate worskpace for tests and explorations of all kind (it often ends up being my “main” workspace these days ), but that was more of a convenience, to allow for the wildest (especially with beans and plugins), but I really believed that one for test and one for work would be enough, although I was concerned at how easily it could grow up…
Having some solutions Working Sets would be nice BTW, and maybe some way to organize the forms of a solution in a folder hierarchy.
About security though, I’m actually thinking of (starting to craft) some kind of hybrid model (where I roll my own model of users/roles based on independant tables and attach it to Servoy’s groups to benefit from some of Servoy’s security features).
I remember seing Sean Devlin’s webinar about it and thought it was actually nice to be able to leverage some part of the built-in security while fine tuning your own.
ptalbot:
About security though, I’m actually thinking of (starting to craft) some kind of hybrid model (where I roll my own model of users/roles based on independant tables and attach it to Servoy’s groups to benefit from some of Servoy’s security features).
I remember seing Sean Devlin’s webinar about it and thought it was actually nice to be able to leverage some part of the built-in security while fine tuning your own.
That was a really good webinar (as usual Sean).
The two main issues with touching Servoy security is:
1- Data entry in design mode – severely limits runtime flexibility.
2- Permissions logic can get really buried – what layouts and layout objects are visible, editable; what tables can be deleted from, etc. Spaghetti code in your future.
Keep in mind that there is nothing in Servoy security that you can’t do on your own. I agree with you that the advantage of the hybrid model is that you can save time coding specific logic at the group level (i.e. table logging or whatever). But you have to do a lot of interface work for the data structures and code in all the hooks which is a fair jump from just using Servoy security.
If you’re in the business of developing many Servoy solutions, or you need ultimate flexibility and power – eventually you have to go all the way. It’s much easier to build business logic around group permissions and everything is configurable at runtime. For large solutions, deployments, or SaaS it’s almost a requirement. And once you’ve got it all done (reusable of course), small deployments and solutions are a snap.
An example: our clients can easily setup a temporary employee with what screens are visible, what records are available, what actions can be done, and tons of other things. No calling us.
A benefit: with this in place, new projects are literally confined only to developing business logic. Clients like paying for their business logic to be developed more than for solution infrastructure to be developed.
Another benefit: no issues syncing developer machines with deployment servers.
So depending on what your goals are – default, hybrid, or completely custom security – have their place. However, I’ll put a bet down that you will eventually end up with a completely custom security scheme Patrick It’s almost inevitable once you start down that road.
david:
So depending on what your goals are – default, hybrid, or completely custom security – have their place. However, I’ll put a bet down that you will eventually end up with a completely custom security scheme PatrickIt’s almost inevitable once you start down that road.
You are right as usual David! I will probably end up with custom.
In the meantime, it saves some times to rely on the existing instead of adding this to the amount of things I need to build…
But I’m aware that one day or another, it will prove insufficient. I just hope that I will have the time then (meaning budget) to do it.
If only I could have the fundation of a framework that I know of…
Thanks for your explanations and nice screenshots!
ptalbot:
If only I could have the fundation of a framework that I know of…
We had a $50 special running but it expired yesterday…
I use Data-Mosaic’s Framework for user and security (access to forms and records) and it is great. So maybe try it out for a test drive, the investment is worth it in terms of payback of time saved developing and testing (believe me I tested it a lot.)
Waiting expectantly for the 4.x version now…
Thomas Parry:
I use Data-Mosaic’s Framework for user and security (access to forms and records) and it is great. So maybe try it out for a test drive, the investment is worth it in terms of payback of time saved developing and testing (believe me I tested it a lot.)
Waiting expectantly for the 4.x version now…
Thanks Tom! I tried Data-Mosaic (and liked it a lot) and that was the one I was talking about, actually
Except that my company got cold hands when we had trouble with the performances in the beta, and even if it’s fixed now, somehow I can’t convince them to get back to it, in the meantime unfortunately I had to prove that we could do without…
Still it doesn’t mean that for later projects we will not use it, and then if the 50$ offer is back, don’t forget to send me an email this time, David
ptalbot:
Except that my company got cold hands when we had trouble with the performances in the beta, and even if it’s fixed now, somehow I can’t convince them to get back to it, in the meantime unfortunately I had to prove that we could do without…
One of the main benefits of using our frameworks is that when issues/bugs are found, we knock our socks off and figure them out. Then everyone using frameworks benefits. In this example, the whole Servoy community benefited because it was style sheets not caching:
http://forum.servoy.com/viewtopic.php?f … 29&p=62433
If you had not tested our frameworks, you could very well have hit the same speed issue on your own if you were insistent upon being cross-platform compatible.
Considering all the quirks involved with technology – java having more than its fair share – I would think our response would be a major selling point. We spent close to 30-man hours narrowing that one down. Your company might as well get cold feet about Servoy.
david:
ptalbot:
Except that my company got cold hands when we had trouble with the performances in the beta, and even if it’s fixed now, somehow I can’t convince them to get back to it, in the meantime unfortunately I had to prove that we could do without…One of the main benefits of using our frameworks is that when issues/bugs are found, we knock our socks off and figure them out. Then everyone using frameworks benefits. In this example, the whole Servoy community benefited because it was style sheets not caching:
http://forum.servoy.com/viewtopic.php?f … 29&p=62433
If you had not tested our frameworks, you could very well have hit the same speed issue on your own if you were insistent upon being cross-platform compatible.
Considering all the quirks involved with technology – java having more than its fair share – I would think our response would be a major selling point. We spent close to 30-man hours narrowing that one down. Your company might as well get cold feet about Servoy.
David,
I know full well the value of frameworks and the efforts you put in your work, no need to convince me of that.
Unfortunately, I’m not my manager: I’m not the one buying. I didn’t have the final decision, that’s all.
As to getting cold feet about Servoy, sometimes they do! - I don’t.