How to copy a server example to a standalone web app?

[stefanscottalexx]

Hi -

I'm trying to learn how to deploy a standalone CRUD app by customizing the DemoApp in the SmartClient 8.0 Evaluation, which can be viewed in the following three ways:

(a) online at smartclient.com,by clicking Showcase App:
http://www.smartclient.com/isomorphi...ml#showcaseApp

(b) locally within the Feature Explorer, by clicking Showcase App:
http://localhost:8080/isomorphic/sys...ml#showcaseApp

(c) locally standalone (slightly different-looking), by going here:
http://localhost:8080/examples/demoApp/demoAppJS.jsp

So I think I could start by copying the folder ../examples/demoApp and then customizing a few things.

I have a few questions:

1 - There are XML files for supplyCategory and supplyItem shown in the tabs in (a) and (b) above - but I don't see any such XML files in the folder ../examples/demoApp in (c). Are these files unnecessary for (c)?

2 - What is the recommended directory layout for the various components of a SmartClient app (eg, where to put the server, db, etc.)?

I assume I could use the Visual Builder to get started building a CRUD app, and maybe use NetBeans or Eclipse to help organize the project's files and directories, but I'm not sure how to get started with this.

Thanks for any help.

UPDATE:

I'm now reading the info here:

http://localhost:8080/isomorphic/sys...up..iscInstall

This seems like it will have what I need, I'm starting to read through it now.

For production I plan on deploying using Jetty as the container and PostgreSQL as the database.

[stefanscottalexx]

(Sorry for this lengthy post. To make it easier to skim, my actual questions are in bold.)

I would like to build a simple CRUD app starting from scratch - with no commitment to any existing server or ORM technology. I do have a preference regarding the database (Postgresql) and the container (Jetty) (and ideally do deployment and lifecycle management using maven) but I don't think these preferences have any impact on coding the app itself (except making sure to specify the Postgresql driver).

Based on the information from the SmartClient Reference quoted below, it seems that the best approach (when doing an SQL CRUD app from scratch) would be to use SQLDataSource and the SmartClient server. Is that correct?

Also: When using the SmartClient Server and SQLDataSource, can I totally avoid using Hibernate?


The SmartClient server accelerates Java integration and provides other useful facilities, including server-push and network performance enhancements...

http://www.smartclient.com/docs/8.0/...up..iscInstall


If you are free to choose which persistence mechanism your application will use, you should consider using the SmartClient SQL DataSource instead of a more heavyweight, bean-based solution. This article discusses the advantages of doing so.

http://www.smartclient.com/docs/8.0/...roup..sqlVsJPA


To use the built-in SQL engine, declare a DataSource in XML format with DataSource.serverType set to "sql", and place it in the shared dataSources directory ([webroot]/shared/ds by default) in a file called "[dataSourceId].ds.xml".

http://www.smartclient.com/docs/8.0/....sqlDataSource


This would suggest the following steps for creating a CRUD app:

(1) Define tables (eg, in PostgreSQL).

(2) Use the SmartClient Visual Builder to define a SQLDataSource for each SQL table.

(3) Create the JS or XML specifying the UI - including databound components referencing the datasources from (2).

(4) Deploy using the SmartClient Server.

Is the above the best approach for building an SQL CRUD app from scratch? Am I missing anything?

In particular, is it better to use XML (and not JS) in step (3) to enable enhanced functionality using the SmartClient Server? That's what the following section seems to be saying:

Whether a DataSource is specified in XML or JS, identical requests will ultimately be submitted to the server, so the server integration pattern is the same. However, DataSources created in XML can be loaded and used by the SmartClient Server, enabling many features including synchronized client-server validation, request bundling, file upload, and optional automatic SQL/Hibernate connectivity (see the Server Summary for details).

http://www.smartclient.com/docs/8.0/...rceDeclaration


In this situation, involving building an SQL CRUD app from scratch (with no commitment to Hibernate), the decision-making flowchart here:

http://www.smartclient.com/docs/8.0/...verIntegration

also clearly recommends using SQLDataSources. However, the term "SmartClient Server" does not occur on the above page, so I'm unsure if the flowchart is also recommending that SQL + No Hibernate => use the SmartClient Server...

At any rate, the SmartClient Server Summary here:

http://www.smartclient.com/docs/8.0/...oup..iscServer

seems to indicate that when using SQL the SmartClient server is the simplest and most powerful approach, so I'm going to try that.


I'm still a bit unsure about the directory layout for a this kind of simple app (CRUD using SQLDataSource and SmartClient server). There seems to be some info about directory layout under "Server Integration" here:

http://www.smartclient.com/docs/8.0/...up..iscInstall

but I would be interested in the specific directory layout(s) for development and deployment using the SmartClient server (along with SQLDataSource - presumably expressed using XML and not JS - plus using database Postgresql and container Jetty), not involving any other existing server or ORM technology.

Thanks for any suggestions.

[Isomorphic]

Hi Stefan,

It looks like you might have read all the relevant docs *except* the QuickStart Guide, which is the right starting point and refers to other docs.

Starting with the server framework chapter you'll find that we recommend using just SQLDataSource with no need for Hibernate, and that you can either generate a DataSource from tables or tables from a DataSource (this is a style choice), but that you should generate the DataSource via the autoDeriveSchema property, not Visual Builder.

You'll also find (in Chapter 4) a recommendation to use the .js format unless you have specific needs.

You have very few files to lay out that aren't already spoken for (just a .jsp file basically), generally you want to think about what URL you want your users to see when accessing the app and name & place this file accordingly.

[stefanscottalexx]

Thanks! Very helpful.