Submitted by Syd Nicholson on Fri, 12/08/2006 - 00:00
Forums
IceBreak

When HTML code is stored in a separate file form the program source, IceBreak does not recompile the program, and hence any changes to the HTML are not live. In order to activate any HTML changes, it is necessary to force IceBreak to recompile the original source program.

It would be a nice touch if the IceBreak program automatically recompiled if any of its associated HTML was changed. This would make development a little easier.

It would be even better, but probably not practical, to read the HTML code from the HTML file dynamically when the page is displayed.

Regards
Syd

Niels Liisberg

Fri, 12/08/2006 - 00:00

Permalink

Hi Syd;

You are not the first that have mentioned it, and we are looking into a solution for that.

You might have seen the "intermediate" directory appear in your development path. Soon  you will see a .DEP - dependency file which will be used for the JIT compiler.

e.g if you have "myApp.asp" it will create a "/intermediate/myApp.dep" file with all references to includes: html , inc, XML etc .. and you might add your own.

Files can be in any sub-directory but only one /intermediate directory exists, so take care of using the same name many places....

I don't know which build it will be in however .... 

Niels

Hi Syd,

It is true that IceBreak do not automatically compile the program until the Source for the RPG/COBOL program is changed. We have it on the prospect list and I think we will come up with a solution I the near future.

It is not possible to have HTML dynamically loaded when you have RPG/COBOL variables in the HTML, but you can of cause at any time refer to HTML files without variables.

Bent

There is a possible and interesting away around this that I have been playing with.

Use an Ajax only application - ie. an HTML file, mith HTML markup and JavaScript, making Ajax calls to get data.

This method does not require an .asp program to send HTML to the browser. The URL contains an HTML file, not a .ASP file.

So far, - experimentation has prooved that this can be a very effective and high performance method of dealing with data pages. And the HTML mark up can be dynamic. Depends upon how much JavaScript you want to use.

Regards
Syd

The stuff I have is actually quite complicated - Done for a client. I also created my own Ajax call in order to customize the call back routine used when the ajax call is complete.

Being able to specify custom AJAX call back routines when the XMLHttpRequest is made is the key to this technique

I will create something simple next week and include sample souce files in the post.

Regards
Syd

Niels,

could you PLEASE change the "/intermediate" subfolder to "/IceBreak/intermediate" instead? As you know I already do NOT like the "/System" subfolder [ehh... link] (because of it's potentionally security threat) and if you keep introducing new subfolders we will also have to change our Apache configuration accordingly to keep users from the "outside" away of referencing anything in these folders. If you put everything beneath an "IceBreak" folder instead then we need only one (or make it two as you have already the "System" folder and you probably won't change this!?) setting for each VirtualHost in our configuration files (we have a LOT!).

Best regards,

John Foldager
www.izone.dk

Hi John;

I got your point.

We have had similar questions regarding the "/system" - since it is a shortcut. So if you delete it - it will be removed from all server instances, which tends to cause problems.

One solution addressing both problems is to create a "real" directory called "/system" and the put "/intermediate" into that.

"/intermediate" is only used from the C++ compiler now but will also include Cobol / RPG / VB in the future. But since C++ is only a pre-release we can easy do the change now.

We can also place the soon coming dependency file there .....

Any comments ??

Niels

Hi Niels,

I haven't put much thought into this, but if you can control the build of "frameworks" which could include or exclude the /System directory then I see no problems so far.

Just think of this scenario... I might create a framework on build 100 which is deployid to a build 81 on another machine... how will it function with or without the /system for build 100? Ajax? ...?

Best regards,

John Foldager
www.izone.dk

Last week week I mentioned using an Ajax only method, hence there is no .asp program delivering HTML. The attached file contains a simplified example which I hope is useful.

The Ajax routine I use I created myself with the help of a book - "Build your own Ajax Web Applications" by M. EERNISSE. ISBN 0-9758419-4-7. The XML parse java script is also by the same author abd available at http://www.fleegix.org

The system is basic, and can be improved/extended.

I chose this method of handling ajax because it allows me to specify the procedure used to handle the returned data from the server. Perhaps this option could be added to the ajax routine provided with IceBreak.

The application is a simple list program for a Purchase Order Header file. It is based on work I am doing at a client site of mine. DDS for the PO Header file is supplied.

The application html (pPurch.html) shows a few fields in a simple table with buttons that allow 'page up/down', 'refresh', 'position to' and 'change page size'. The previous page button is disabled if the top of the list is shown, similarly, the next page button is disabled if the last record in the list is shown.

The handling for this page is done using the javascript pPurch.js file. All page control and ajax calls are in this object.

There are a number of service programs - GPProcs.rpgle has general purchase procedures used by the system, Purchasing.rpgle is the database interface layer and handles the PO Header file interface.

The program pPurchX.rpgle is used in the ajax url call from the browser. The program represents the business logic and output layer for the system.

As supplied this software should run on OS/400 V5R2 and upwards. If required the software can be adjusted to run on V5R1 by
1. Placing the copy source GPProcsC.rpgle, PurchasingC.rpgle, HSpecs.rpgle and DSpecs.rpgle in an appropriate OS/400 source file.
2. In the RPG programs replace the /INCLUDE statements such that the selected source file is used. (suggested /INCLUDE statements are included and commented out in the rpgle source code).

Limitations of the this approach - XML and/or javascript objects are limited to 32KB. The page size cannot be too large or the xml parsing with fail. Even if you increase the size of the string used to hold the XML, the browser cannot handle more than 32KB.

This XML size limit has posed a number of serious problems in the work I doing for my client. A number of the <SELECT> boxes have long lists, and attempts to handle lists longer than 32KB using XML always fail. I need to work on a custom select list that is only loaded one page (say 10 records) at a time using ajax. This will reduce the load on the network as well.

Regards
Syd

Attached Files: files.zip (33.2 KB, 91 views)