Conversion of 1.2 JATO project (non-Forte IDE) to S1AF (JATO) 2.0

Question

JATO Team,
First of all, thank you very much for the Studio integration. It
looks very promising in terms of development time consumption,
deployment to S1AS7, etc., etc. It is impossible to observe all
advantages for so short period of time.
The SOAF (JATO) 2.0 is installed on the top of the Sun ONE Studio 4,
update 1 (EE) with JDK 1.4 along with the Sun One Application Server
7 (W2000). Everything looks okay, at least all basic tasks listed in
the "Getting Started" manual (project/view/model creation, basic db
connection, running of a test application with the usage of the
Studio's default Tomcat container, etc.) work proper.
During the installation of S1AF module on the top of the Sun ONE
Studio 4, update 1 (EE) I've got an invitation to convert the
existing project to the new environment. As I realized the only JATO
project integrated/created with Forte IDE is applicable for this auto-
conversion (please correct me, if I am wrong. It could solve a lot of
my problems).
Since we are using JBuilder5 IDE and our JATO 1.2 project is
integrated with this IDE I manually re-created project in the Studio
with its file structure, adjusted the project web.xml file, etc. This
new project looks like a proper one (Studio recognize all methods,
fields, bean patterns, e.g.) except at least one "small" thing. All
java files (project viewBeans, Models, custom viewBeanHelpers a.k.a.
pure java) came up with the same wizard image:java class. Stutio with
the S1AF module reserves the special images (and appropriate studio
properties, of course!) for View and Model. Namely this allows to see
the following structure for a ViewBean, for example, in the Studio:
Modules
ProjectName.ModuleName
FooViewBean
JavaSource
JSPs
Non-Visual Components
View Components
On the other hand, I could add either new View or Model in my
manually converted project and add any View Component or bind the
Model fields, for example. Also, the ProjectModuleServlet has been
converted proper. I tried to convert each View/Model class inside the
Studio to its proper wizard image and failed. Addition of a View
Components (with an appropriate code fragments) via the Studio or
auto-binding of model fields is an essential part of 2.0 and should
drastically speed up the development process as it is designed.
Questions:
1. What I missed in my manual conversion of 1.2 JATO project to the
SOAF (JATO) 2.0 realm? What should I correct in my JATO 1.2
compatible classes (Views and Models) to be recognizable by Studio
wizard (JATO 2.0)?
To be more specific. Some deltas between JATO 1.2 and JATO 2.0 are as
follows (related to a ViewBean):
====++++++++++++++======
JATO 1.2 viewBean extension upon creation:
public class FooViewBeanViewBean extends ViewBeanBase
implements ViewBean
========================
JATO 2.0 (S1AF) version: viewBean extension upon creation:
public class FooViewBean extends BasicBeanBase
====++++++++++++++======
JATO 1.2 viewBean createChild(...) method for one static looks
like:
protected View createChild(String name)
if (name.equals(CHILD_STATICTEXT1))
StaticTextField child = new StaticTextField
(this,
getDefaultModel(),
CHILD_STATICTEXT1,
CHILD_STATICTEXT1,
CHILD_STATICTEXT1_RESET_VALUE,
null);
return child;
========================
JATO 2.0 (S1AF) version: viewBean createChild(...) is renamed (as
a least) to createChildReserved(...):
protected View createChildReserved(String name) {
if (name.equals(CHILD_STATICTEXT1)) {
com.iplanet.jato.view.BasicDisplayField child =
new com.iplanet.jato.view.BasicDisplayField(this,
STATICTEXT1);
return child;
====++++++++++++++======
JATO 1.2 viewBean registerChildren() method for the basic field
types looks like:
private void registerChildren() {
registerChild(CHILD_STATICTEXT1, StaticTextField.class);
registerChild(CHILD_TEXTFIELD1, TextField.class);
registerChild(CHILD_BUTTON1, Button.class);
========================
JATO 2.0 (S1AF) version: viewBean registerChildren() method:
private void registerChildren() {
registerChild(CHILD_STATICTEXT1,
com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_TEXTFIELD1,
com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_BUTTON1,
com.iplanet.jato.view.BasicCommandField.class);
Is it correct to say that all existing custom Views/Models
(compatible with JATO 1.2) should be converted to their JATO 2.0
variants to be visible by the Studio?
On the other hand, fast overview of 2.0 API shows that the JATO 1.2
is a sub-set of the 2.0 (BasicViewBean extends ViewBeanBase, for
example). What exactly (only deprecated methods?) should be adjusted
in the project code (1.2), if necessary, to be visible by Studio as a
View or Model component?
2. Where it is possible to find the list of deprecated methods (from
JATO 1.2 to JATO 2.0 versions). It is difficult sometimes to compare
two versions of API docs (1.2 and 2.0) or compare logs between
versions. Also, JATO 2.0 is significantly larger than 1.2 version. If
the later obviously inherits the ND conversion stage (via the
previous versions), the former obviously has additions incoming from
the integration with the Studio (a.k.a. Forte 4.0).
3. What is the current/future Sun/JATO Team policy with regards to
JATO source code access (version 2.0, at least)? The reason of this
question is as follows: in order to display dates formatted on the
screens we adjusted a couple of JATO 1.2 core classes, for example.
The only minimal, absolutely necessary changes in JATO 1.2 was made,
but anyway...
Sorry for so long multiple question. As Todd wrote in his
announcement mail: "We think you will be very pleased with the new
product...". This is exciting moment, I believe, for JATO Team as
well as for any team involved into the conversion of the full size
application/product from ND to J2EE realm with the JATO as
an application framework (1.0, 1.1.x, 1.2.X, and 2.0 finally). The
last step is left in this spiral process to enjoy the ND_Studio
attractive features in the open source environment.
Thank you very much in advance.
Vladimir Ivanov

Answer 1

I'll get some file templates ASAP and provide them to the group.
As for source code, I'm not sure what the policy is. JATO 1.2 is very
close to what JATO 2.0 is, so that should suffice for now.
The community will be informed when we know more about source availibility.
craig
vivanov4114 wrote:
Craig,
Thank you for the answer. To be honest with you I tried to do exactly
the same: I created the small test project and made an attempt to
adjust the existing *.xml files to the new ones. I got some results,
otherwise I couldn't even see my original 1.2 project in the Studio.
Since I am a newcomer in the Studio, I definitely missed something in
my adjustments. I'll try to observe my changes with the fresh head.
On the other hand, I am afraid that my samples are very pure. If you
could post or send me examples of jatoapp.xml and web.xml files (say
for any of you test project) or excerptions from them with the
appropriate patterns (ViewBean and Model peers, at least), I would be
very appreciated. My mail is: vivanov@b...
In the worst-case scenario I see the workaround: to re-create the
project for one of our releases with the Forte 4.1 IDE and auto-
convert it into the JATO 2.0/Studio world using the Studio
facilities. We must get the current project fully
integrated/converted with/to the Studio (at certain point) because,
first, we expect massive coding with the GUI components involved soon
and, secondly, we have around thousand classes related to JATO only
(and a lot of extras).
Coming back to the question #3 from this post. Now we have full
access to the version 1.2, not only to the JATO 1.2 jar file(I
explained some reasons below). Would we expect the same Sun/JATO Team
policy with JATO 2.0?
Thank you again,
Vlad
--- In SunONE-JATO@y..., "cvconover" <craig.conover@s...> wrote:
It doesn't appear that anyone has responded to this so I am goingto
give you the short answer:
The reason you don't see your ViewBeans and Models showing up with
there "wizard created" icons is because of just that. They weren't
created via the wizards. The wizards create xml formatted filesthat
contain metadata of how/what to generate for the ViewBeans and
Models.
ViewBeans will have a .viewbean fiel, Models will have a .sqlmodel
file (for SQL Models), etc. The content of these files describesthe
code that needs to be generated in the corresponding Java classfile.
So LoginViewBean.java will have a peer LoginViewBean.viewbean file.
The code that is generated is place in protected code blocks thatcan
not be modified in the Studio and should not be modified outsidethe
Studio because the code will likely be regenerated and custom mods
inside the protected blocks will be lost.
Now you can make a JATO 1.2 app appear in the Studio just like aJATO
2.0 app by adding a jatoapp.xml file with the proper content and
adjusting your web.xml properly, but it's much more work to getyour
v1.2 ViewBeans and Models to show up like wizard created versions.
Furthermore, even more work to get the display fields to show up
visually.
The good news is that v1.2 ViewBeans will work with newly wizard
created ViewBeans. And if you do go through the trouble of making
your ViewBeans Studio visible like your wizard created ViewBeans,
adding new display fields visually will work along side yourmanually
created fields.
Try creating a new JATO app using the Studio wizards and then go to
the Filesystems tab and look for the jatoapp.xml file and theweb.xml
file.
I am looking for an email that I have that explains how to do a
partial, manual upgrade.
Also, you will get rid of your JATO 1.2 jar and replace with theJATO
2.0 jar in your lib dir.
Hope this will suffice for now.
craig
--- In SunONE-JATO@y..., "vivanov4114" <vivanov@b...> wrote:
JATO Team,
First of all, thank you very much for the Studio integration. It
looks very promising in terms of development time consumption,
deployment to S1AS7, etc., etc. It is impossible to observe all
advantages for so short period of time.
The SOAF (JATO) 2.0 is installed on the top of the Sun ONE Studio4,
update 1 (EE) with JDK 1.4 along with the Sun One ApplicationServer
7 (W2000). Everything looks okay, at least all basic tasks listedin
the "Getting Started" manual (project/view/model creation, basic
db
connection, running of a test application with the usage of the
Studio's default Tomcat container, etc.) work proper.
During the installation of S1AF module on the top of the Sun ONE
Studio 4, update 1 (EE) I've got an invitation to convert the
existing project to the new environment. As I realized the onlyJATO
project integrated/created with Forte IDE is applicable for thisauto-
conversion (please correct me, if I am wrong. It could solve a
lot
of
my problems).
Since we are using JBuilder5 IDE and our JATO 1.2 project is
integrated with this IDE I manually re-created project in theStudio
with its file structure, adjusted the project web.xml file, etc.This
new project looks like a proper one (Studio recognize all
methods,
fields, bean patterns, e.g.) except at least one "small" thing.All
java files (project viewBeans, Models, custom viewBeanHelpersa.k.a.
pure java) came up with the same wizard image:java class. Stutiowith
the S1AF module reserves the special images (and appropriate
studio
properties, of course!) for View and Model. Namely this allows tosee
the following structure for a ViewBean, for example, in the
Studio:
Modules
ProjectName.ModuleName
FooViewBean
JavaSource
JSPs
Non-Visual Components
View Components
On the other hand, I could add either new View or Model in my
manually converted project and add any View Component or bind the
Model fields, for example. Also, the ProjectModuleServlet hasbeen
converted proper. I tried to convert each View/Model class insidethe
Studio to its proper wizard image and failed. Addition of a View
Components (with an appropriate code fragments) via the Studio or
auto-binding of model fields is an essential part of 2.0 and
should
drastically speed up the development process as it is designed.
Questions:
1. What I missed in my manual conversion of 1.2 JATO project tothe
SOAF (JATO) 2.0 realm? What should I correct in my JATO 1.2
compatible classes (Views and Models) to be recognizable byStudio
wizard (JATO 2.0)?
To be more specific. Some deltas between JATO 1.2 and JATO 2.0are
as
follows (related to a ViewBean):
====++++++++++++++======
JATO 1.2 viewBean extension upon creation:
public class FooViewBeanViewBean extends ViewBeanBase
implements ViewBean
========================
JATO 2.0 (S1AF) version: viewBean extension upon creation:
public class FooViewBean extends BasicBeanBase
====++++++++++++++======
JATO 1.2 viewBean createChild(...) method for one static looks
like:
protected View createChild(String name)
if (name.equals(CHILD_STATICTEXT1))
StaticTextField child = new StaticTextField
(this,
getDefaultModel(),
CHILD_STATICTEXT1,
CHILD_STATICTEXT1,
CHILD_STATICTEXT1_RESET_VALUE,
null);
return child;
========================
JATO 2.0 (S1AF) version: viewBean createChild(...) is renamed(as
a least) to createChildReserved(...):
protected View createChildReserved(String name) {
if (name.equals(CHILD_STATICTEXT1)) {
com.iplanet.jato.view.BasicDisplayField child =
new com.iplanet.jato.view.BasicDisplayField(this,
STATICTEXT1);
return child;
====++++++++++++++======
JATO 1.2 viewBean registerChildren() method for the basic field
types looks like:
private void registerChildren() {
registerChild(CHILD_STATICTEXT1,
StaticTextField.class);
registerChild(CHILD_TEXTFIELD1, TextField.class);
registerChild(CHILD_BUTTON1, Button.class);
========================
JATO 2.0 (S1AF) version: viewBean registerChildren() method:
private void registerChildren() {
registerChild(CHILD_STATICTEXT1,
com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_TEXTFIELD1,
com.iplanet.jato.view.BasicDisplayField.class);
registerChild(CHILD_BUTTON1,
com.iplanet.jato.view.BasicCommandField.class);
Is it correct to say that all existing custom Views/Models
(compatible with JATO 1.2) should be converted to their JATO 2.0
variants to be visible by the Studio?
On the other hand, fast overview of 2.0 API shows that the JATO1.2
is a sub-set of the 2.0 (BasicViewBean extends ViewBeanBase, for
example). What exactly (only deprecated methods?) should beadjusted
in the project code (1.2), if necessary, to be visible by Studio
as
a
View or Model component?
2. Where it is possible to find the list of deprecated methods(from
JATO 1.2 to JATO 2.0 versions). It is difficult sometimes tocompare
two versions of API docs (1.2 and 2.0) or compare logs between
versions. Also, JATO 2.0 is significantly larger than 1.2
version.
If
the later obviously inherits the ND conversion stage (via the
previous versions), the former obviously has additions incomingfrom
the integration with the Studio (a.k.a. Forte 4.0).
3. What is the current/future Sun/JATO Team policy with regards
to
JATO source code access (version 2.0, at least)? The reason ofthis
question is as follows: in order to display dates formatted onthe
screens we adjusted a couple of JATO 1.2 core classes, forexample.
The only minimal, absolutely necessary changes in JATO 1.2 wasmade,
but anyway...
Sorry for so long multiple question. As Todd wrote in his
announcement mail: "We think you will be very pleased with the
new
product...". This is exciting moment, I believe, for JATO Team as
well as for any team involved into the conversion of the fullsize
application/product from ND to J2EE realm with the JATO as
an application framework (1.0, 1.1.x, 1.2.X, and 2.0 finally).The
last step is left in this spiral process to enjoy the ND_Studio
attractive features in the open source environment.
Thank you very much in advance.
Vladimir IvanovTo download the latest version of JATO, please visit:
http://www.sun.com/software/download/developer/5102.html
For more information about JATO, please visit:
http://developer.iplanet.com/tech/appserver/framework/index.jsp
[Non-text portions of this message have been removed]