jRev, Java and CORBA (None Specified)
At 22 JAN 1999 02:18:18AM Jim Weir, Algo Research wrote:
On Netscape's Web page describing server-side JavaScript (SSJS), they state that a SSJS application using LiveConnect functionality can access Java and CORBA distributed-object applications. They go on to say that to access methods and properties of a Java Class you simply create an instance of the Class from within the SSJS code.
Since jRev is going to allow us to deploy components as Java Classes, does this mean that we will be able to call jRev procedures including jLH IO from a Netscape Web Server using SSJS?
At 22 JAN 1999 09:26AM Cameron Purdy wrote:
Hi Jim,
On Netscape's Web page describing server-side JavaScript (SSJS), they state that a SSJS application using LiveConnect functionality can access Java and CORBA distributed-object applications.
They go on to say that to access methods and properties of a Java Class you simply create an instance of the Class from within the SSJS code.
That sounds very cool – especially since we are planning to support the JavaScript syntax for scripting components.
Since jRev is going to allow us to deploy components as Java Classes, does this mean that we will be able to call jRev procedures including jLH IO from a Netscape Web Server using SSJS?
The answer is YES. Every component developed in jRev is a JavaBean – which is a Java class that is very easy to "create an instance of" and very predictable in terms of the way its methods are named.
This will all make more sense when we roll out our technical preview to our Works customers (in 9 days!). The part of your question about jRev procedures including jLH IO is worth clarifying as well. First, you must call them "methods" instead of "procedures" or the object oriented police will get you
. Second, the jLH integration will probably appear in jRev in the first migration release, which is scheduled for 31 Dec 1999. I do not know any details of how jLH will be packaged for commercial release; we do have both "local mode" and "service" supported already. Lastly, the data model in jRev is significantly evolved from the current Arev/OI model, so chances are you will not have to work directly with jLH but rather with a set of JavaBeans that represent your data at a logical level, much like the dictionary does for you data now.
See also:
Cameron Purdy
Revelation Software
At 22 JAN 1999 02:04PM [email protected] wrote:
Cameron,
Once again I must say that I very thankful that you and gene are leading this.
It looks that jRev will be everything that long time revelation/arev people would have wished for OI but never got.
Waiting in eager anticipation ..
[email protected] onmouseover=window.status=you have seen the rest .. now try the best!;return(true)"
David Tod Sigafoos ~ SigSolutions
voice: 503-639-8080
At 22 JAN 1999 06:28PM Cameron Purdy wrote:
Jim,
Here are some relevant posts I made on the newsgroup.
Cameron Purdy
Revelation Software
] I've heard that jRev was demo'ed at the Texas conference.
A prototype of jRev was shown. jRev is currently being built in the jRev
prototype, and when it gets functionally to the point where the prototype, we
will:
1) Switch over to building jRev in the actual jRev
2) Ship a technology preview
Our schedule is January (next month) for this step.
] Does anyone have
] any impressions of the product. What is it like?
Yes, I do. It is very cool. It is component-based development done right.
My opinion may be influenced by my frame of reference, though.
] Does it still have multivalued/variable-length data?
May I answer that twice, please?
1) No. All application logic works against components. For example, where
you used to access a record using "record" or "{name}" and modified by
"record=…", you now use a "record.name" construct (component.property)
for both. 2) Yes. The database format of LH remains unchanged. LH data
components (like the record discussed above) internally work with data
knowing its multi- valued/variable-length structure. (And now it supports
Unicode too. No more single byte character limitations.)
So application logic (e.g. logic on a form) will primarily deal with data in a
generic component manner, but LH-specific database logic can deal with data
using the same stuff you are used to.
] What is it like to create forms - similar to OI?
Right now, creating a form is accomplished by using a simple set of tools (the
same tools that can design any other component, visual or not) which are the
containment manager, property sheet, and script editor. When we complete the
visual layout extension (mid-99) it will be drag&drop like OI, but you will
stil be able to use the simpler set of tools to get down&dirty.
The tools in jRev are "views" of the component data. All of the component
data is represented in three tools: containment manager, property sheet, and
script editor. More "advanced" views of the data, such as visual layout,
wizards, etc., work against the same underlying data, just making it simpler
to build specific types of components. In a way, it is like Arev with its
editor that could be used to build/examine any Arev component, but
dictionaries, menus, and templates had more specific tools.
] Dicts still exist?
Yes, but as components. (The difference being that a dictionary in Arev/OI is
passive … it is data about data. In jRev, the equivalent functionality is
actual executable code (a Javabean component) that represents and facilitates
access to the underlying data.)
] What language does one use for application development - Basic or Java?
In a word: Yes. We will support Java in the technology preview and BASIC+ in
the first migration release (Dec 1999).
] Any other tidbits would be interesting.
It will be delivered as part of the OpenInsight Works program. For more
information on the OpenInsight Works program:
mailto:[email protected]
(800)262-4747 within the USA
(978)946-7100 outside the USA
+44 (0) 1908 233 255 UK/Europe/Africa sales
] I'm intrigued. I like the bean approach — it seems entirely
] appropriate.
All jRev components are Javabeans. That is to say you cannot create something
in jRev that is not a Javabean.
] Also, it's nice to be accessing fields consistently
] using the name of the field.
Agreed. It also lets you put both symbolic (logic on "get") and functional
(logic on "set") functionality right where it belongs – on the data!
] I'm assuming the field number must be
] compiled into each field/property name of the record bean to avoid the
] speed penalty one would normally incur by going thru the dictionary.
Yes. (BTW The speed penalty of the dictionary is in I/O, not in
calculations. I don't know if you have used CACHE for Arev which was
available on CIS, but it would speed up Arev apps up to 1600% by caching
read-only info like dicts, object code, messages, etc.)
] Say I added an attribute to the end of a record, and I don't care to
] access that attribute via java, would I have to recompile my record
] bean?
First, the LH implementation is inherited from the abstract bean. That is to
say that you design your data (for example, I have an "invoice" which has an
"invoice number" and "invoice date" and "status" and contains "invoice
lines") like you would a dictionary, but minus any LH (or any other specific)
information. Then a second component inherits from that and provides an
optimized implementation for a particular back-end, for example JDBC or LH.
(You can even inherit from that to provide more specific functionality for
Oracle over JDBC, and inherit from that to take advantage of Oracle8i
features, etc. Thus building from the abstract definition of the data to the
specific back-end implementation.)
Second, in jRev, you won't "compile" anything. You will do design work, and
save it. The underlying component management model is responsible for
supplying the corresponding up-to-date Java class files when needed, whether
they are compiled on the fly or stored persistently.
] Does jREV store UNICODE in LH files by
] default? If so, what characters are reserved for LH delimiters?
The Java platform provides ways of compacting Unicode into binary. We plan to
use the UTF8 format. That means (obviously) that Unicode data in LH would not
be easily shared with OI or Arev.
The LH delimiters are selected from a region of Unicode which is vendor and
user assignable. We have reserved a range of 256.
] Is the 64k limitation now gone? It seems you'd have to
] preserve it, at least selectively, to access legacy tables.
It is an option to preserve the limit on LH files. LH never had a 64k limit,
since it is based on variable-length offsets and lengths (each byte has 7 bits
data and one bit continuation).
Variants (variables) do not have a 64k limit. That is an artifact of the
intel 16-bit memory model which Arev (DOS, not OS/2) and OI were built for.