I know I’m being a pain, but it needs to be said. I didn’t see anything about it here or the web dev forum section. Servoy needs to provide developers with the option to deploy to the web in addition to the lovely Servoy client.
HTTP isn’t going away anytime soon. This forum is a case in point. Yes, we can go build PHP sites or whatever using the same backend database, but that’s not good enough. That would mean we weren’t developing in Servoy.
I want to immerse myself in Servoy and do all my development there and get really good, become really fast, and be really efficient at doing about anything that needs to be done at whatever scale - all without a huge development team. Hey, it’s your fault for allowing me/us to think so greedily!
I know this will be hard as you will have to convert Servoy Developer produced code into servlets and a server for a different interface. I hate it for you. But we need a way to decide what client a specific form may be served to, i.e. http or servoy.
The servoy client is great for many things, but it isn’t a one stop shop (and doesn’t claim to be). However, it inherently makes this promise by using so many technologies that are part and parcel for web development and by replacing so many of the features offered by Filemaker. For the same reasons that Filemaker bought the Blueworld developed web companion, Servoy need to allow its developers to build dynamic websites and webservices from within Servoy developer. XML web services, SOAP, etc., etc. And of course, it won’t be as lame as the web companion. The poor web/networking capability of filemaker and its poor scaling sent me to Servoy in the first place. My initial application is perfect for the thin client, but I keep having to catch myself when I think about a web site and how I could do it in Servoy.
Anyway, it’s inevitable that Servoy will provide web capability given time so you don’t have to tell us when - unless you want to???. But by all means do tell if you have some strong opposition to offering a web interface so we developers can team up and try to convince you otherwise.
We do not have plans to support html web interfaces.
Servoy runs very well over the internet even over a 56K modem (compare this with any other desktop db alike )
Another reason is there are so many product available for making html interfaces which can interact with the data in the SQL database, that it seems to us we are better of spending time on the Servoy Client
Your rich thin client is certainly your key differentiator and is far more important for establishing Servoy that just being another web interface builder. I for one applaud your forsight to not become “just another web tool”. I encourage you to focus on the Servoy client/server product until you have it pretty much “done”. At the rate you are going, that will be sooner than later. Perhaps Servoy version 3 or 4 could introduce a web interface? Please don’t eliminate the possibility. The competing “desktop databases” are ahead in this important category.
This is more importaant than just feature maatching with the competition. The promise of connected web services is growing in its appeal. Specialized data services can be delivered with only an XML interface and I the demand for such services will continue to increase. For one of my Filemaker clients, I am using Filemaker’s XML capabilities to provide real-time mailing address correction. In another, I’m extracting interest rates from another website updated frequently. For aanpother, I’m using XML to populate a PDF form dynamically. This is powerful stuff from my client’s perspective.
Making use of existing web services is but one example, delivering such services is another. I have one customer that wants a service I can offer, but only as an XML/SOAP type service (integrating with .net) so they can use it in their own applications, much like I’ve described above.
Then from a developers perspective, it would be wonderful to consolidate business logic into a single repository regardless of the client. Using one IDE is also nice and fewer languages to manage a key benefit. rather than providing one tool to access a database for one client type, Servoy would become the means to deliver content to web browsers, XML/web services, and of course your rich client. That would be big.
Of course if this is such a dramatic departure to your plans and would be a major undertaking, it probably isn’t worth it - for awhile anyway.
iI know, you note have plans to do something like the web companion in Filemaker. But if you interact with the data in the SQL database via the web there is no update in Servoy without restart the application or flushing the cache.
You have to do it in Servoy.
If you ever have plans what do you think about this one
But if you interact with the data in the SQL database via the web there is no update in Servoy
I agree, it would be wonderfull, if there was a webservice which is closely working together with Servoy. So that changes on the webservice-side would be instantly seen in the Servoy Client.
So what we are looking for are not tools to build a webinterface, but a kind of webservices closely connected to Servoy
I think this option is there, through the plugin abilities of Servoy. Just a matter of writing the plugins.
You can, for example, register webservices, so you can access the Servoy environment through HTTP. I’ve looked briefly at it, but didn’t have time to really go into it, but from the looks of it, I would say you would be able to do updates to the DB, through a HTTP call.
I think that when you do this, the standard Servoy functionality of broadcasing datachanges to clients looking at that data would still work.
What I do not know, though, is in what kind of usersession the update would take place.
I would be wonderful if Servoy Server would be a database provider so you can hook it up to any other middleware (ASP/JSP/PHP/Lasso Proffesional/ColdFusion/etc).
This way the Servoy services know what is touched in the database and can repond to the Servoy clients accordingly.
So no need for a full fledged middleware solution, just let Servoy Server be a datasource (bridge).
Maybe people will argue that this is bridge function might be slow for the websolutions. Well they can always connect to the original datasource directly for the selects and perform the updates/inserts through the Servoy datasource connection.
I don’t know why we should look at jetty (it is a nice jsp/servlet based container/server) but we already embed tomcat at the moment. And the use of a server is only a very very small part to what really would be needed for a full web client.
What we could do in time (earlier then a complete web interface) is the abillity to talk to a engine through the web. So that you can get and set some data through a servoy server/service. And that all updates are also broadcasted to clients.
Does this mean that registering of a webservice through a plugin, by which you can do updates through the DB and get the datachanges broadcasted over the clients doesn’t work currently?
jcompagner:
What we could do in time (earlier then a complete web interface) is the abillity to talk to a engine through the web. So that you can get and set some data through a servoy server/service. And that all updates are also broadcasted to clients.
jcompagner:
What we could do in time (earlier then a complete web interface) is the abillity to talk to a engine through the web. So that you can get and set some data through a servoy server/service. And that all updates are also broadcasted to clients.