Q:Converting Forms to J2EE

If you are using Designer, than JHeadstart is a good start.
Else i would suggest that you first migrate your forms to forms 10g and than
migrate new functionality to J2EE.
Forms user a very "soiled" user, so moving them from forms to html db will
be difficult. And i doubt that migrating full featured forms to html db
will be simple.

HTH

Oliver
 >> Stay informed about: Q:Converting Forms to J2EE 

Oliver Gehlert wrote:

> Forms user a very "soiled" user, so moving them from forms to html db will
> be difficult. And i doubt that migrating full featured forms to html db
> will be simple.
>

Soiled?

But moving from forms to htmldb is simple. Unless the users
fail to accept the changes due to HTML handling the front end.

--
Regards,
Frank van Bortel
 >> Stay informed about: Q:Converting Forms to J2EE 

"Frank van Bortel" wrote in message

> Oliver Gehlert wrote:
>
>> Forms user a very "soiled" user, so moving them from forms to html db
>> will
>> be difficult. And i doubt that migrating full featured forms to html db
>> will be simple.
>>
>
> Soiled?
>
> But moving from forms to htmldb is simple. Unless the users
> fail to accept the changes due to HTML handling the front end.
>
> --
> Regards,
> Frank van Bortel

Simple?

If the forms application has any validation logic at all, or any triggers at
all, or any transaction logic, it would all have to be rewritten -- major
work, based on the forms apps I've seen over the last 20 years.

HTML DB is a great tool, but it's a different paradigm than Forms -- even if
you're using really, really, simple Forms.

++ mcs
 >> Stay informed about: Q:Converting Forms to J2EE 

i meant spoiled. Must forms offer more comfort than any html frontend can
provide. So it will be a major rewrite andunhappy users

Oliver
 >> Stay informed about: Q:Converting Forms to J2EE 

Oliver Gehlert wrote:
> i meant spoiled. Must forms offer more comfort than any html frontend can
> provide. So it will be a major rewrite andunhappy users
>
> Oliver
>

Stick to Java, then

--
Regards,
Frank van Bortel
 >> Stay informed about: Q:Converting Forms to J2EE 

Mark C. Stock wrote:
> "Frank van Bortel" wrote in message
>
>
>>Oliver Gehlert wrote:
>>
>>
>>>Forms user a very "soiled" user, so moving them from forms to html db
>>>will
>>>be difficult. And i doubt that migrating full featured forms to html db
>>>will be simple.
>>>
>>
>>Soiled?
>>
>>But moving from forms to htmldb is simple. Unless the users
>>fail to accept the changes due to HTML handling the front end.
>>
>>--
>>Regards,
>>Frank van Bortel
>
>
> Simple?
>
> If the forms application has any validation logic at all, or any triggers at
> all, or any transaction logic, it would all have to be rewritten -- major
> work, based on the forms apps I've seen over the last 20 years.
>
> HTML DB is a great tool, but it's a different paradigm than Forms -- even if
> you're using really, really, simple Forms.
>
> ++ mcs
>
>
Yes - HTMLDB is simple, and straighforward.
Validation can only be basic, as one would expect from HTML.
Triggers in a form - to do what? Same comment on HTML applies.
Transaction logic should not be in a form alone - it is allowed
as duplicate of the db transactional code, nothing more.
Thus - HTMLDB will cope (with the db-centric code).

And did I not say "Unless .... changes due to HTML..."?
As I replies to Oliver: stick to Java, then.

--
Regards,
Frank van Bortel
 >> Stay informed about: Q:Converting Forms to J2EE 

"Frank van Bortel" wrote in message

> Mark C. Stock wrote:
>> "Frank van Bortel" wrote in message
>>
>>
>>>Oliver Gehlert wrote:
>>>
>>>
>>>>Forms user a very "soiled" user, so moving them from forms to html db
>>>>will
>>>>be difficult. And i doubt that migrating full featured forms to html db
>>>>will be simple.
>>>>
>>>
>>>Soiled?
>>>
>>>But moving from forms to htmldb is simple. Unless the users
>>>fail to accept the changes due to HTML handling the front end.
>>>
>>>--
>>>Regards,
>>>Frank van Bortel
>>
>>
>> Simple?
>>
>> If the forms application has any validation logic at all, or any triggers
>> at
>> all, or any transaction logic, it would all have to be rewritten -- major
>> work, based on the forms apps I've seen over the last 20 years.
>>
>> HTML DB is a great tool, but it's a different paradigm than Forms -- even
>> if
>> you're using really, really, simple Forms.
>>
>> ++ mcs
>>
>>
> Yes - HTMLDB is simple, and straighforward.
> Validation can only be basic, as one would expect from HTML.
> Triggers in a form - to do what? Same comment on HTML applies.
> Transaction logic should not be in a form alone - it is allowed
> as duplicate of the db transactional code, nothing more.
> Thus - HTMLDB will cope (with the db-centric code).
>
> And did I not say "Unless .... changes due to HTML..."?
> As I replies to Oliver: stick to Java, then.
>
> --
> Regards,
> Frank van Bortel

That was exactly my point -- it is not simple to move from Forms to HTML
DB -- it's a total rewrite.

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
 >> Stay informed about: Q:Converting Forms to J2EE 

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?

--
Regards,
Frank van Bortel
 >> Stay informed about: Q:Converting Forms to J2EE 

Frank van Bortel ( ) 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.
 >> Stay informed about: Q:Converting Forms to J2EE 

"Malcolm Dew-Jones" wrote in message

> Frank van Bortel ( ) 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
 >> Stay informed about: Q:Converting Forms to J2EE 

"Frank van Bortel" wrote in message

> 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?
>
> --
> Regards,
> Frank van Bortel

We'll see -- after a very nice presentation at our user group last night by
one of the HTML DB team of developers, it looks like I'll be putting
together a fairly sophisticated PM system with it. I'll see how much can be
done before resorting to javascript and custom mod_plsql routines.

++ mcs
 >> Stay informed about: Q:Converting Forms to J2EE