17 replies to this topic

[Cleve Haynes]

This may have been posted elsewhere,  but Glovia (an ERP package) has what they refer to as an e-client product. Its a server side based software that allows the Genned functions to be seen on the web (must be Java) just like in the normal client. Total functionality of the menus, buttons, function keys, etc. were usable and visually
laid out identically the same. The only thing as a developer was you could not shell out; that was about it. Licensing is very expensive (by no. users) so my company never implemented it. But I got to see it in action at my other company and it looked great.

Hi Kevin

This sounds suspiciously like the "JavaSuite" product that ProIV had. No doubt Glovia bought this along with the rest of the ProIV source code when Northgate IS sold it to them a couple of years ago.

I used it, had lots of problems, and certainly wouldn't recommend it. Maybe Glovia have improved it...

JavaSuite was a fudge, - because once the applet loaded in the browser, it was still a Client/Server architechure using a telnet connection - just as the standard client does... It could not be used on the Internet because of security issues...

ProIV have now replaced JavaSuite with the "ProIV Web Client". I'm not sure how good this is now, as I haven't looked at it now for about a year. This uses the standard ProIV client as an active-x control within the browser. Apparently this supports SSL.

As far as I am concerned, web clients for ProIV are a waste of time (they look ugly, and you need a licence per seat). You may as well write web front ends for the stuff that needs web exposure.

P.S - My apologies on talking about stuff not related to the thread... But Kevin started it!

Cleve

[Richard Bassett]

Hi Claudio,

I am no talking about a new language, rather a framework that takes care of the “assumed” running environment

I'm not able to visualize what you mean. What is it the developers will actually edit? What editors will they use for this and for which "parts" of the application? Do they have a free choice of editors?

The ProIV security stuff is not something I would try to put in a new RAD tool – I don't think it works particularly well and a better approach would be proper integration with security infrastructure(s) external to the tool.

I presume your reference to "Automatic design of screens and reports" refers to capabilities of Superlayer? Some visitors to this forum (including me) do not usually think of Superlayer as included by the general term "ProIV". For clarity it may be better to mention Superlayer explicitly when relevant.

Note it might be argued that, overall, Superlayer has been a failed experiment in RAD and looking at why that was could be very instructive for your proposed project!

Some (including probably me) would argue that screen modes (UI modality) are a BAD thing and a modern tool should strive to avoid this feature of ProIV.

Java could be arguably too verbose for "RAD logic" (declarations mandatory for all variables as an example). I also note again that you need to consider what subset would be legitimate/safe and how you'd enforce that.

For me, the "quality" issue as far as the tool is concerned is prevention of defects. The relevant question is what language/tool features help prevent application defects and how do they do so?

Starting by supporting only open software would be fine I guess - beware though that it's very hard to be "smart enough" to support the proprietary targets well later unless one knows enough about them right from the start..

I'd agree there's no point bothering with ISAM filesystems – just Object-Relational SQL databases (targeting an ORDBMS is probably important to properly exploiting Oracle etc.. later). I'd agree PostgreSQL is functionally rich but note that all the commentary suggests its performance is poor. I notice MySQL has teamed up with SAP to offer the SAP database rebadged as "MaxDB". I don't know if this has any O-O capabilities but performance is supposed to be pretty good. The cynic in me says the folks at MySQL finally decided that if you don't design transactions and performance in from the start then you can't retrofit them

"Integration" at the level of common database access is of course available with almost any programming tool. It's OK to aim for that but it would leave little reason for the ProIV community to prefer your theoretical new tool to any other RAD tool they could try.

My problem with the "bootstrap model" is that I can't use standard tools on my source code! For example none of the following can be exploited:
vi/ctags, sccs/rcs/cvs, grep/awk/sed, diff, make, cpp/m4, code-formatters

No modern app is developed using only one tool and one wants to be able to build the whole app in a "common tool framework" (the openness of Eclipse is advantageous in precisely this way). Scriptability of development tools is an important issue. Inadequate execution profiling, coverage testing and debugging support is also a problem in ProIV (although that is not necessarily the fault of the "bootstrap" approach, I think it hasn't helped).

There's plenty of open-source .NET stuff happening – just throw "open-source" ".NET" at a search engine.

And just to note the obvious finally, file processing PER FIELD is relevant only to the screen function 'model', not reports or updates

[CSuarezdelReal]

Hi Richard!

I was thinking on something like a “Virtual Machine” that can interpret a structure similar to Pro IV (Characteristics, files, properties, etc.) and then, for the non-standard behavior, use logics (just as Pro IV) written in Java.

Security is not flexible in Pro IV, but it is there, and you may rely on it, if you do not have a better choice. I think that it has to be a crucial piece of a RAD. If it has to be quite different from Pro IV’s, that’s OK.

The automatic generation of layouts for simple screens and reports is, as you said, as what SuperLayer offers, sorry for not mentioning it. I guess that is the only SuperLayer-specific point I proposed.

Screen modes is a matter we could evaluate, I am still thinking they help us to give some automatic behavior to the application, mainly setting what you can do to a table, depending on the mode. One thing less to worry when programming.

I think that we could define/declare any type/variable we use as long as the application provide us with a very intuitive “grid” to do it, easily available (at the stroke of two keys?). After all I am talking about a RAD, not an editor. Should I access the “Logic 0” easily, I would define more variables.

I suggested PostgreSQL, because I would like to state, clearly, from the start, that we are creating “professional” applications that needs a place to save the data they process. I want to save the code in a database too. I am sure, now that SAP is working on MaxDB, we will have another important option. At the end, the RAD could be very flexible, as for using PostgreSQL, MaxDB, Oracle, DB2, etc.

Even now, I was wondering if an ORDBMS is good enough. I was thinking on heavily using XML. In that case, we should look for NXD (Native XML Databases) as Xindice or Db4XML options. Being XML documents, functions could work with Unix commands as vi/ grep/awk/sed/diff, etc., but more than that, they would be immediately transportable, and we could use all the power tools currently available for XML.

I think that if we design “everything” from the start as a XML documents (from functions to data), we could define an XML document as the input of a function, and an XML document as the output of a function, then we could work pretty well on batch an interactive mode.

By the way, thanks for your note on “Disruptive Programming Languages Technologies”. I share the idea of Increasing programmer productivity by writing programs correctly, quickly and easily. “The problem is how to get wide adoption of the new language”… to get wide adoption of “something”... that is innovation.

Saludos,