Re: Q:Converting Forms to J2EE

"Malcolm Dew-Jones" <yf110_at_vtn1.victoria.tc.ca> wrote in message news:42fb9964_at_news.victoria.tc.ca...
> Frank van Bortel (frank.van.bortel_at_gmail.com) wrote:
> : Mark C. Stock wrote:
>
> : >
> : > That was exactly my point -- it is not simple to move from Forms to
> HTML
> : > DB -- it's a total rewrite.
>
> : Does it now show that English is not my native tongue?
> : Haven't thought in that direction at all, and yes - it's a
> : complete rewrite, not a migration.
>
> : >
> : > Most of the stuff I've coded into Forms apps over the past 2 centuries
> can
> : > also be coded into HTML apps, so it's not a given that an HTML app has
> to be
> : > less functional, but it's a major shift in development techniques.
> : >
> : > ++ mcs
> : >
>
> : Yup - but as HTML DB will give you a development boost, it
> : (the rewrite process) could be as fast as migration of
> : forms to - what, J2EE? Newer Forms?
>
>
> How about "migrating" the forms to the new forms browser environment? I
> tried it once with a trivial form, and it looked like it must be just a
> straight port of the old forms runtime into a java browser plugin. The
> form itself and its usage appeared to be near identical to what it would
> have been in the original client server environment.
>
> --
>
> This space not for rent.

Web-deployed forms (only option for Forms 9) uses essentially the same runtime engine as the client/server version, but the presentation is handled with the java plugin -- so it's really just a redeployment, not a migration (except for some very small gotchas)

Web deployment makes sense for a shop that has a major investment in Forms applications and does not see itself rewriting them any time soon, but does not make sense for new development in a shop that isn't already Forms-centric.

But Forms is dying -- does not support new datatypes like TIMESTAMP and INTERVAL -- and it expensive ($$ and resources).

++ mcs Received on Thu Aug 11 2005 - 14:21:35 CDT