Re: [xwt-users]Shouldn't the server be as easy.

On Tue, Jul 08, 2003 at 08:03:29AM -0700, Eric Merritt wrote:

>  I am not really planning to replicate any of these
> things. j2ee runs a broad gamut of technologies none
> of which are simple or easy to do (not especially
> hard, just not as easy as they should be).

OK, we may have different experiences in this regard. I find the basic
Java stuff easy, it makes the harder stuff possible, and there's lots of
work already done.

> I can't say
> much about .Net I have never used it but it may be
> something similar, I just don't know. Zope is an full
> blown Http application server with plenty of nice
> server side and client side technologies. ASP/PHP are
> client side and don't really apply.

Neither ASP nor PHP are client side.

> With the client side stuff my main goal is not to
> replace Eclipse or VisualStudio. I just need a
> distributed client that is easy to deploy and can
> easily manipulate the server I am planning. This
> currently doesn't exist and it looks like I can save
> myself allot of hassle by using XWT. I will try to put
> all the features you mention in the client but they
> are incidental and not core to the needs of the
> client. 

I'm confused here... I may not be understanding you right. Eclipse and
VS are not client-side technologies...

>  But we are straying from the main argument. Let me
> give you a little user story and maybe that will help
> you to understand my goal. I will also provide a
> similar one for Eclipse so the differences may be
> compared.
> 
> With Polar --
> 
>  The user request a change in a search/query in the
> companies main business application, perhaps he wishes
> for his query to return active as well as inactive
> contracts instead of just the active ones it now
> returns. The change is reviewed and accepted by the
> developers and scheduled for one of the devs.
> 
>  The developer assigned pops over to the url that
> launches the IDE for the development server. He finds
> the service he wishes to modify in some type of tree
> select that lists all services on that server. When he
> selects it the source for that service appears in the
> editing area (There would probably be some locking
> mechanism if another dev was editing it, but thats not
> relevant). He then proceeds to modify the script
> slightly and save it. When he saves it, it is written
> to the development server that served the IDE he is
> using. Once saved, it is immediately available. He
> tests it out on the client (XWT, PHP, whatever) and
> sees  that it works. 

OK, so I'm now *definately* confused. What you describe is pretty much
what you can do with PHP using any number of DAV/FTP aware editors;
phpMOLE seems nice enough, and there are others whose name escapes me
right now. PHP as a client... as a consumer of webservices, which then
generates HTML or somesuch? Unless this script would run client-side...
but then the backend wouldn't really matter.

>  He goes back to his IDE and schedules the script to
> be moved to the QA environment. The testers test it
> and certify that it works. He makes a request to his
> lead to have it moved to production. His lead moves
> the script to production with a click of the IDE and
> its all done.
> 
> 
> Eclipse
> 
>  The user request a change in a returned query,
> perhaps he wishes for his query to return active as
> well as inactive contracts instead of just the active
> ones it now returns. 
> 
>  The developer starts eclipse and makes sure that the
> project is in his workspace and synched with the
> cvs/source control repository. He finds the class he
> wishes to modify in whatever package its in. When he
> double clicks it the source for that service appears
> in the editing area. He then proceeds to modify the
> class slightly and save it locally. Once he saves it,
> he runs the ant script that builds the war file. He
> then ftps the war file to the development server and
> waits for the app server to redeploy it (this can be
> done as part of the ant script as well).

I usually test my stuff straight from Eclipse using the tomcat plugin.

> He tests it
> and sees  that it works. He then commits the changed
> source to cvs and requests that a qa build take place
> so that his changes may be tested (along with any
> other changes that occured) by the dedicated testers.
> 
>  Either the developer or his lead then builds a qa war
> in a separate build environment (maybe on his box,
> maybe a dedicated server) and deploys it to the QA
> server. The testers test it and certify that it works.
> He makes a request to his lead to have it moved to
> production. Once his change and any others are
> scheduled they make the move to production.

A lot of these steps can be automated if you so wish, but I catch your
drift.

> Of course this example is a bit contrived, if you
> designed your query/search right activity would just
> be a flag you selected but it serves for illustration.
> Also, it depends on how your build/testing/production
> cycle is set up whether you have to go through all
> these steps, but this is a common setup. There may
> also be a few shortcuts for some of these areas on the
> eclipse side as well.
> 
>  It does, I hope, illustrate how much easier server
> side coding can be though. One thing it doesn't
> illustrate is how much simpler a scripting langauge is
> to make changes in as opposed to a systems language
> like Java.

A lot of this could be covered with the BSF.

>  Ahh, but you see the back end is usually not that
> intelligent either. Not only that but the stuff the
> standard business app does is usually pretty similar
> across services.  I have been doing server side stuff
> in Java for the last six or seven years 90% of the
> time the business logic fits a very small set of
> process. Usually something like 
> 
>   Test input for correctness
>   Do something with a database/filesystem/etc.
>   Possibly do some reformating and return a result.
> 
>   There are variations on this, and the other 10%
> doesn't really fit into this mold and thats fine,
> vanilla Polar wouldn't be a good fit for these areas.
> But for the larger case of business applications you
> can very easily write a set of APIs for each of the
> major areas (in short order) and provide a fairly
> simple and extremely fast way to script most of the
> stanard type of services. 

OK. Our environments differ enough that quick-deploy is less of an
issue over having stuff like j2ee available. I can still not entirely
visualize how using a non-standard development environment would yield
enough of a benefit to make a move, but that would be entirely particular
to my situation.

> btw, I don't think this conversation is really
> relevant to XWT anymore. If anyone wishes to continue
> it may be best to take it off line. No need to tick
> anyone off.

*grin* there's been loads of OT discussion. I think I have all the info
I need and will just see where Polar goes, but this list is pretty
flexible in what is on-topic. We were at least still talking
webservices.

-- 
Emiliano