Why I am Not Using Servoy

Using Servoy to administrate the content of your website? Discuss all webrelated Servoy topics on this forum!

Why I am Not Using Servoy

Postby teammascot » Wed Dec 15, 2004 12:33 am

First, let me say - I think Servoy is a beautiful product, a huge step in truly delivering desktop client RAD dev with RDBMs integration. I am writing this post in the hopes that I might find out if my reasoning for deciding not to develop with Servoy is valid and to see if any alternatives exist for the obstacles I encountered.

A few months ago I downloaded Servoy and began developing an app. I was blown away and the product was truly inspiring, but I ran into what I saw as major obstacles to truly leveraging its potential. I did finish the application and it was beautiful - except for the following points. Can anyone correct me OR give me a glimmer of hope that future versions of Servoy will resolve these issues.

1) SQL - Because Servoy relies on its own query writing to fetch records, it limits the ability to take advantage of complex SQL statements. Yeah, I know - I used the sql functions to fetch rows but as far as I could tell, things like aliases and related fields were not well supported. I found the workaround to be a mess - building calculation fields meant creating dummy fields in MySQL so I wouldn't have to wait for large datasets to be calculated by Servoy.

I have read that Servoy uses advanced caching to speed performance, but the result is that Servoy IS NOT truly separated from the datasource. It requires the datasource to be dependent upon it. Why can't Servoy just act as a results set tool, at least as an option. Utilizing SQL to perform key calculations and to limit results and returning them directly to the client/server seems far more efficient.

I guess what I am saying is that a truly separated model would act more like lasso or php on Apache where it queries the DB and then handles the returned rows before displaying.

2) Data Dependancy - Yeah I know Servoy says it is completely seperated from the datasource but the fact is the datasource can't be messed with outside of the Servoy environment. This was truly dissapointing. I thought of a hundred ways to use Servoy but they almost all required other users to add, update or delete datasource info via a web interface. Ecomm and other situations make it impractical for everyone to access a datasource via Servoy client. I know this point has been discussed in previous posts, the issue of flushing client cache, etc but why can't clients just retrieve the records every time? Web sites do it all of the time. Or if Server would utilize a special required timestamp field in the DB in conjunction with key values it would know when records were updated, added or deleted.

Thats it - my only two gripes. I found everything else great and I still hope I might be able to utilize Servoy in the future. For now I have gone back to web application development to meet my needs.

Thanks for any comments.
TeamMASCOT
Officially Licensed Sports Merchandise
http://www.teammascot.com
teammascot
 
Posts: 16
Joined: Fri Sep 17, 2004 5:29 am
Location: USA

Re: Why I am Not Using Servoy

Postby ROCLASI » Wed Dec 15, 2004 2:50 am

teammascot wrote:1) SQL - Because Servoy relies on its own query writing to fetch records, it limits the ability to take advantage of complex SQL statements. Yeah, I know - I used the sql functions to fetch rows but as far as I could tell, things like aliases and related fields were not well supported. I found the workaround to be a mess - building calculation fields meant creating dummy fields in MySQL so I wouldn't have to wait for large datasets to be calculated by Servoy.

For what do you need the complex queries for ? Reporting ?
If so then you can still use the SQL and display them in HTML (inside a text field, displayType HTML_AREA).

teammascot wrote:I have read that Servoy uses advanced caching to speed performance, but the result is that Servoy IS NOT truly separated from the datasource. It requires the datasource to be dependent upon it. Why can't Servoy just act as a results set tool, at least as an option. Utilizing SQL to perform key calculations and to limit results and returning them directly to the client/server seems far more efficient.

I guess what I am saying is that a truly separated model would act more like lasso or php on Apache where it queries the DB and then handles the returned rows before displaying.

Servoy is separated from the datasource. The fact that Servoy does caching has nothing to do with the datasource. The datasource doesn't know of it and thus doesn't depend on it.

teammascot wrote:2) Data Dependancy - Yeah I know Servoy says it is completely separated from the datasource but the fact is the datasource can't be messed with outside of the Servoy environment. This was truly dissapointing. I thought of a hundred ways to use Servoy but they almost all required other users to add, update or delete datasource info via a web interface. Ecomm and other situations make it impractical for everyone to access a datasource via Servoy client. I know this point has been discussed in previous posts, the issue of flushing client cache, etc but why can't clients just retrieve the records every time? Web sites do it all of the time. Or if Server would utilize a special required timestamp field in the DB in conjunction with key values it would know when records were updated, added or deleted.


I use Servoy as back-end tool for Lasso driven sites where web-users can add/edit data. Servoy works fine with this.
It's just that you have to call a function (see below) to make Servoy catch up with the database.
Code: Select all
databaseManager.refreshRecordFromDatabase(foundset, -1)

This forces Servoy to re-fetch the foundset from the datasource. Any other caches are untouched.
This is much less drastic than flushing the client cache completely.

Besides this Servoy is working on a headless client that is expected to be released in January 2005.
With this you add data via the web and Servoy will know about it. :)

teammascot wrote:Thats it - my only two gripes. I found everything else great and I still hope I might be able to utilize Servoy in the future. For now I have gone back to web application development to meet my needs.

I have made many web-based applications with Lasso Professional and my experience is that Servoy is way more efficient for database driven applications than a web-based one.
Mainly for one reason and that is that Servoy doesn't have to send over the GUI every time you load a screen. Once loaded it is cached on the client and only (new/changed) data is being send over the internet.
That is the power of Servoy and using caches in a smart way.

Apart from the fact that developing in Servoy is much faster than in Lasso. Even when you reuse code a lot in Lasso.
Now do I think Servoy is a replacement for tools like Lasso Professional ?
No.
But there is definitely an overlap and in those situations you can choose either one. Which one depends on your requirements.
Robert Ivens
SAN Developer / Servoy Valued Professional / Servoy Certified Developer

ROCLASI Software Solutions / JBS Group, Partner
Mastodon: @roclasi
--
ServoyForge - Building Open Source Software.
PostgreSQL - The world's most advanced open source database.
User avatar
ROCLASI
Servoy Expert
 
Posts: 5438
Joined: Thu Oct 02, 2003 9:49 am
Location: Netherlands/Belgium

Postby teammascot » Wed Dec 15, 2004 4:25 am

Thanks for the reply - you have my attention :D

For what do you need the complex queries for ? Reporting ?
If so then you can still use the SQL and display them in HTML (inside a text field, displayType HTML_AREA).


Most of my SQL statements include joins, stragiht and left, and the joined fields are never opperated on - just for display, but I do need to be able to edit data and perform actions for fields belonging to the primary table of the statement. Can I do that with the HTML _AREA?

The ability to utilize the built in Portal for viewing/editing records is nice - was hoping to avoid HTML_AREAS, but to be honest never really jumped into the them, so I may have been missing something.

Servoy is separated from the datasource. The fact that Servoy does caching has nothing to do with the datasource. The datasource doesn't know of it and thus doesn't depend on it


I probably used the wrong terminolgy, I was trying to communicate that solutions in Servoy make it hard to work with a datasource's data using other clients as it messes up the cache and thus Servoy clients do not see the changes. Your answer about using the function:
Code: Select all
databaseManager.refreshRecordFromDatabase(foundset, -1)

seems like it might be the solution though. So this technique will basically force fresh records on every query if I use it before selecting any records?

I have made many web-based applications with Lasso Professional and my experience is that Servoy is way more efficient for database driven applications than a web-based one.


I agree and that is a huge draw for me. Transfering only the text data is awesome as well as not having to fiddle with HTML for layout.
TeamMASCOT
Officially Licensed Sports Merchandise
http://www.teammascot.com
teammascot
 
Posts: 16
Joined: Fri Sep 17, 2004 5:29 am
Location: USA

Postby bcusick » Wed Dec 15, 2004 11:51 am

Regarding the HTML - use it! You can trigger methods in servoy (and pass parameters), display images, links, related data, whatever.

Regarding using a Web client and having the Servoy data update - WATCH FOR A JANUARY 2005 ANNOUNCEMENT that will solve that issue. :D

Hope this helps.
Last edited by bcusick on Wed Dec 15, 2004 8:49 pm, edited 1 time in total.
Bob Cusick
bcusick
 
Posts: 1255
Joined: Wed Apr 23, 2003 11:27 pm
Location: Thousand Oaks, CA USA

Postby ROCLASI » Wed Dec 15, 2004 1:26 pm

teammascot wrote:Most of my SQL statements include joins, stragiht and left, and the joined fields are never opperated on - just for display, but I do need to be able to edit data and perform actions for fields belonging to the primary table of the statement. Can I do that with the HTML _AREA?

HTML_AREA's are great for displaying data. But you can't use them for editing in the way you use Servoy forms.
You can however call methods from within the HTML and pass parameters to it to let it edit/select/etc your data, like Bob said.
Ofcourse you do this in the method itself.

teammascot wrote:Your answer about using the function:
Code: Select all
databaseManager.refreshRecordFromDatabase(foundset, -1)

seems like it might be the solution though. So this technique will basically force fresh records on every query if I use it before selecting any records?

Yes, when you use Servoy forms. But when you use plain SQL by using the DatabaseManager.getDataSetByQuery() function somehow I think that Servoy will query directly on the datasource since it doesn't know what data is touched.
But I haven't tested this, it is a guess on my part. Maybe one of the Servoyans can chip in here.
Robert Ivens
SAN Developer / Servoy Valued Professional / Servoy Certified Developer

ROCLASI Software Solutions / JBS Group, Partner
Mastodon: @roclasi
--
ServoyForge - Building Open Source Software.
PostgreSQL - The world's most advanced open source database.
User avatar
ROCLASI
Servoy Expert
 
Posts: 5438
Joined: Thu Oct 02, 2003 9:49 am
Location: Netherlands/Belgium

Postby bcusick » Wed Dec 15, 2004 8:51 pm

getDataSetByQuery() directly queries the SQL backend at the moment of query. The refresh record command will refresh the record from the database.

Hope this clears it up.
Bob Cusick
bcusick
 
Posts: 1255
Joined: Wed Apr 23, 2003 11:27 pm
Location: Thousand Oaks, CA USA

Postby Jan Blok » Thu Dec 16, 2004 2:24 pm

teammascot wrote:...Most of my SQL statements include joins, stragiht and left, and the joined fields are never opperated on...

You can use controller.loadRecords(<your own very wild SQL>,<SQLArguments>) use the move sample code on load Records method to see how this works, this is also known as form-by-query...
Jan Blok
Servoy
Jan Blok
 
Posts: 2684
Joined: Mon Jun 23, 2003 11:15 am
Location: Amsterdam


Return to Web Development

Who is online

Users browsing this forum: No registered users and 4 guests

cron