•GZIP compression/decompression of ILOB and/or response object
•Security (LDAP lookup, Validation lists, etc.)
•Replace substring inside an ILOB
•Search of a substring within an ILOB
•Get an entry from a ZIP-file into an ILOB (also functionality to read filename, filesize etc.)
•Put an entry into a ZIP-file from an ILOB (also functionality of creating subfolders within the archive)
•DOM parser to support retrieval of element value (value1 and value3) of fx. <p> in: <p>...value1...<s>value2</s>...value3...</p>
•SAX parser for XML
•Description of how to integrate to C API's on AS/400 from RPG
•WebService consumer functionality
•Base64 encoding and decoding
•MD5 of a string and/or ILOB content
•Regular Expression support
•Set the content from ILOB into a Marker
•Import several file uploads directly into ILOB's without the use of temporary files
•Default values for a marker if SetMarker is never called: <%$ MyMarker : "My default text" %>
•Make it possible to support a URL like "/id/1234" where "id is the asp program and the rest is a parameter to the program.
•Customized error pages.
•Make it possible to write free-format code beyond the "comment" fixed-format column (is it column 80?).
•Make it possible for trace.txt to have *PUBLIC set to *RWX automatically.
•Make it possible for trace.txt to "round robin" after fx. 100K.
•Create functionality to execute Statements and getting MetaResults like in Java where you can get the name of column no. 5, type of data for column 10 etc.
•Functionality to create and send (S/)MIME based emails with as many attachments as you like (both text and html based etc.)
Most of these you already have from my "wishlist" emails (was the latest number 11?), and some of them might already have been implemented.... or....??
Anyway... before implementing any of the above... please call me to discuss so that you do not limit the functionality
I'll post more functionality another day.... trust me!
Ohh - the more i answer - the more questions I receive ...
I'll do it shortly:
* GZIP compression/decompression of ILOB and/or response object
-- Sceduled 2007 q1, for request/response - ILOB's later
* Security (LDAP lookup, Validation lists, etc.)
-- Sceduled 2007 q1, for LDAP lookup - validation list: use IBM API now
* Replace substring inside an ILOB
-- You can do that with a normal %subst in RPG
* Search of a substring within an ILOB
-- You can do that with a normal %scan in RPG
* Get an entry from a ZIP-file into an ILOB (also functionality to read filename, filesize etc.)
-- Sceduled 2007 q2,
* Put an entry into a ZIP-file from an ILOB (also functionality of creating subfolders within the archive)
-- Sceduled 2007 q2,
* DOM parser to support retrieval of element value (value1 and value3) of fx. <p> in: <p>...value1...<s>value2</s>...value3...</p>
-- not scheduled
* SAX parser for XML
-- You already go one build in XML parser that work from V5.1 - and now SAX for RPGle ... how many do you want ???
* Description of how to integrate to C API's on AS/400 from RPG
-- This is not the scope of IceBreak- but you can find fine samples here on code400
* WebService consumer functionality
-- can be made the "hard way" to day see the KRAK tutorial - the super easy way are not scheduled yet .... Portlets for WebSphere Portal server comes first...
* Base64 encoding and decoding
-- Sceduled 2007 q1,
* MD5 of a string and/or ILOB content
-- Sceduled 2007 q1 for strings, ILOBS later ...
* Regular Expression support.
-- Use the new C++ feature it has buildin reg.exp ...
Originally Posted by Niels Liisberg: "Ohh - the more i answer - the more questions I receive ..."
Maybe you can find someone that can answer most of the questions for money
Originally Posted by Niels Liisberg: "* GZIP compression/decompression of ILOB and/or response object
-- Sceduled 2007 q1, for request/response - ILOB's later"
(1)
Originally Posted by Niels Liisberg: "* Security (LDAP lookup, Validation lists, etc.)
-- Sceduled 2007 q1, for LDAP lookup - validation list: use IBM API now"
Okay...
Originally Posted by Niels Liisberg: "* Replace substring inside an ILOB
-- You can do that with a normal %subst in RPG"
Ohh... I was sure that %subst only worked on strings (max 32K)
Originally Posted by Niels Liisberg: "* Search of a substring within an ILOB
-- You can do that with a normal %scan in RPG"
Ohh... I was sure that %scan only worked on strings (max 32K)
Originally Posted by Niels Liisberg: "* Get an entry from a ZIP-file into an ILOB (also functionality to read filename, filesize etc.)
-- Sceduled 2007 q2,"
(1)
Originally Posted by Niels Liisberg: "* Put an entry into a ZIP-file from an ILOB (also functionality of creating subfolders within the archive)
-- Sceduled 2007 q2,"
(1)
Originally Posted by Niels Liisberg: "* DOM parser to support retrieval of element value (value1 and value3) of fx. <p> in: <p>...value1...<s>value2</s>...value3...</p>
-- not scheduled"
Okay... just keep in mind that it is valid XML so it should be possible to parse... but (1)
Originally Posted by Niels Liisberg: "* SAX parser for XML
-- You already go one build in XML parser that work from V5.1 - and now SAX for RPGle ... how many do you want ???"
Just the two of them Well okay... this one has the lowest priority of all my wishes.
Originally Posted by Niels Liisberg: "* Description of how to integrate to C API's on AS/400 from RPG
-- This is not the scope of IceBreak- but you can find fine samples here on code400"
Okay... I'll take a look around.
Originally Posted by Niels Liisberg: "* WebService consumer functionality
-- can be made the "hard way" to day see the KRAK tutorial - the super easy way are not scheduled yet .... Portlets for WebSphere Portal server comes first..."
I know... but it is not "nice" code, so I'm looking forward to an implementation of it.
Originally Posted by Niels Liisberg: "* Base64 encoding and decoding
-- Sceduled 2007 q1,"
(1)
Originally Posted by Niels Liisberg: "* MD5 of a string and/or ILOB content
-- Sceduled 2007 q1 for strings, ILOBS later ..."
(1)
Originally Posted by Niels Liisberg: "* Regular Expression support.
-- Use the new C++ feature it has buildin reg.exp ..."
Do you have an example of how to use a regular expression this way on a string and retrieve fx. parameter 1 and 2 from it?
Notes:
(1) Damn... we need this to create the applications of tomorrow!
I can't image why I forgot to put this issue on the list as it is one of the things that we have been talking about for more than a year now. I have just looked at your implementation of "pre-request exit program" and it would be cool to have an "error exit program" of some kind if errors occur.
It should run on the following situations:
•If a resource is not available... the program or file referenced in the URL does not exists
•If in a program I call a function SetErrorValue('CustomName' : 'CustomValue') multiple time it should add my name/value pairs to an array that I can access in the error exit program. When I wan't to pass the array on to the post-request exit program I call the SetError().
In both cases the response object of the original program should be discarded, and only the response object from the exit program should be valid.
It might be valuable to put an ILOB into a value and pass it on in the array
It would also be cool to have an "post-request exit program".
It should be possible to get the response object from the original program and manipulate it; fx. GZIP it ... or call the before-mentioned Error exit program.
Originally Posted by Niels Liisberg: ""post-request exit program" is not a good name ... lets refer to it as "pre-response exit program"
If we can agree on that, I'll put it on the list - it make totally sence."
Whatever.... :-)
Originally Posted by Niels Liisberg: ""SetErrorValue" is already there: Use the "marker" feature to implement your own error list."
I'm not sure I understand... What I wan't is to parse my ILOBs, strings etc. from the called program to the "pre-response exit program". If I use the "marker" feature they will just be inside a response object and then I can't reference each of them directly... am I correct? I'm thinking ahead of what is possible today and tomorrow... thinking of what we can do with IceBreak in the "future"...
In the 'Official' Ajax code supplied with IceBreak would it be possible to add some additional JavaScript routines to allow the format of the returned data to be specified ('text' or 'xml'), also to allow the name of the call back back procedure that handles the returned data to be passed to the Ajax call.
I have attached some files that I use - ccsAjax makes the Ajax call to the server. Note that the doGet() and doPost() accept the required return data format and the name of the data handling procedure.
The other attached file, customerSelBox.js, shows an example of the use of this technique. The procedure self.loadData() makes the Ajax call specifying 'xml' for the returned data format. it passes self.dataTableHandler as the name of the procedure used to handle the returned data. self.dataTableHandler() then reads through the data and formats it for display in the HTML page.
It would be very nice if these features were included as standard in the 'Oficial' Ajax code for IceBreak.
The files I have attached work OK in IE6, opera, mozilla - but will almost certainly need to be checked/modified for other browsers and/or IE7!
Originally Posted by Syd Nicholson: "In the 'Official' Ajax code supplied with IceBreak would it be possible to add some additional JavaScript routines to allow the format of the returned data to be specified ('text' or 'xml'), also to allow the name of the call back back procedure that handles the returned data to be passed to the Ajax call.
I have attached some files that I use - ccsAjax makes the Ajax call to the server. Note that the doGet() and doPost() accept the required return data format and the name of the data handling procedure.
:
It would be very nice if these features were included as standard in the 'Oficial' Ajax code for IceBreak."
I haven't checked you code to see if you take this into account, but you [and the IceBreak Development Team] should remember that even though you POST or GET and knows that your service will return fx. "XML", it might in fact return HTML which can not be validated in the client. If your session has expired and you call a function that should return XML it might return a HTML login page instead.
I haven't checked you code to see if you take this into account, but you [and the IceBreak Development Team] should remember that even though you POST or GET and knows that your service will return fx. "XML", it might in fact return HTML which can not be validated in the client. If your session has expired and you call a function that should return XML it might return a HTML login page instead.
Just a thought...."
Hi John,
I my case this is not a problem - this is from a client project of mine and I write both sides (server and client) part of the code. I know exactly the format and structure that will be returned.
However, I agree, that in a more commercial product a robust implemation is advisable. The code I supplied is provided only as an example, and might need modification to timprove it's suitability for other environments. I leave this up choice up to the developers - should they decide to include this type of feature in the IceBreak Ajax implementation.
I want to have access to three more parameters. If my request looks like:
https : / /mydomain.com/mypath/myapp.asp?param1=A¶m2=B#top (please remove the spaces around ' : / /'... forum will truncate the URL and wrap it in URL syntax).
1) GetServerVar('REQUEST_RESOURCE_FULL_PATH')
This should return '/mypath/myapp.asp'
2) GetServerVar('REQUEST_RESOURCE_FULL_URL')
This should return '/mypath/myapp.asp?param1=A¶m2=B#top'
"I haven't checked you code to see if you take this into account, but you [and the IceBreak Development Team] should remember that even though you POST or GET and knows that your service will return fx. "XML", it might in fact return HTML which can not be validated in the client. If your session has expired and you call a function that should return XML it might return a HTML login page instead."
Just a further thought on this matter.
In 'xml' format a javascript object is returned - this is not text. With 'text' format, text is returned and could be HTML.
The 'xml' object needs to be parsed with a siutable xml parser. The code for the parsing of the xml object could be included in a 'try-catch' construct to eliminate errors if the parsing should fail.
In the example code I provided I am looking for specific record types in the xml. If these record types are not present the length of the array of records that results from the parsing of the xml is zero. You will see that my code does indeed react to a no data situation - outputing a 'no data to display' message.
If the return type is 'text' - it would be necessary to analyse the text string to determine if it contained the expected response.
It would be great if you could group IceBreak server instances so that we could have option 12 to show the groups and then make it possible to go into a group to show the server instances of that group.
Yes, but we have to obey RPG rules for parameters. However, it might be possible to add this feature if we decide that if all other parameters is input.
We have ILOBs (User Spaces) and very useful they are -- but when searched they must be searched sequentially, or part of the ILOB must be converted to an array for %LOOKUP. GSORT is another possibility when several data structure records must be searched
There could be another large object type that stores data - a User Index. Lets call these XLOBs or ULOBs
A user index comprises two parts - 1. the index (any character string/data structure) and 2. the associated data (another character string/data structure). Data can be placed in storage and retrieved in key sequence, much like using a database file.
A user index created as a session object would be automatically deleted when the session ends. User management of temporary objects would be eliminated
User indexes have the advantage of being faster than database files, do not require the creation (and management) of temporary data base files, do not hold record locks, and can easily be created and deleted.
Unlike user spaces, user indexes allow random access, so searching a user index merely requires retrieving a records by key.
Good idea - or should this be shot down in flames?? Your thoughts?
Originally Posted by Niels Liisberg: "Yes, but we have to obey RPG rules for parameters. However, it might be possible to add this feature if we decide that if all other parameters is input.
Is that acceptable?"
Niels, I have no idea what you are talking about? "...that if all..."!!?
Originally Posted by Syd Nicholson: "There could be another large object type that stores data - a User Index. Lets call these XLOBs or ULOBs
A user index comprises two parts - 1. the index (any character string/data structure) and 2. the associated data (another character string/data structure). Data can be placed in storage and retrieved in key sequence, much like using a database file.
A user index created as a session object would be automatically deleted when the session ends. User management of temporary objects would be eliminated
User indexes have the advantage of being faster than database files, do not require the creation (and management) of temporary data base files, do not hold record locks, and can easily be created and deleted.
Unlike user spaces, user indexes allow random access, so searching a user index merely requires retrieving a records by key.
Good idea - or should this be shot down in flames?? Your thoughts?"
At present the server can be set to require the user to log on - this must be a OS/400 user.
It would be great if the server could be set such that it recognized either of two types of user - either an OS/400 User ID, or a 'virtual' user based on a userID/password file kept within IceBreak.
The maintenance of this User/Password file could be added to Admin server, and these user/passwords could then be applied system wide. The user table could also hold other data (eg. Name, telephone number, e-mail etc.)
The LogOn(), LogOff() and LoggedOn() functions could be modified to check the logon requirement of the server and process either type of log on.
It would also be great if the userID/Password fields were long enough to include e-mail addresses.
Additional functions could be added to provide access to the user data held in the user table allowing modification/listing of this data using IceBreak .asp pograms.
Such a feature would be a great addition, because, when implementing web sites that require this type of log on, developers would not need to 're-invent the wheel' for each site that was created.
"Funny that you mention this with the log in - We are skipping the IceMenu framework that is addressing that topic.
It also contains tools to organize users into groups and design menu to those user and groups...
It is ready and will be shipped here in January"
That sounds great.
Would I be correct in assuming that that the menu page that shows the folder structure can be modified for other purposes. - eg. To show the contents and structure of IFS folders.
I am creating code to do just that and have had difficulty with the JavaScript. I have run into problems with JavaScript objects greater than 32K in size. The folder structures I am trying to display are much bigger (100 times perhaps) than 32K and it simply does not work!
At the moment I am creating code to display the folder structure one page at a time, with the folder structure held in ILOBs on the server.
Can your new menu system handle what would be a very large menus (say 500K up to 5MB). If it can then this would be extremely useful.
Originally Posted by John Foldager: "I want to have access to three more parameters. If my request looks like:
https : / /mydomain.com/mypath/myapp.asp?param1=A¶m2=B#top (please remove the spaces around ' : / /'... forum will truncate the URL and wrap it in URL syntax).
1) GetServerVar('REQUEST_RESOURCE_FULL_PATH')
This should return '/mypath/myapp.asp'
2) GetServerVar('REQUEST_RESOURCE_FULL_URL')
This should return '/mypath/myapp.asp?param1=A¶m2=B#top'
Remember: None of the above should convert characters to uppercase!"
Hi John;
They are on the way exept for the full url. The names is a litle different however:
•REQUEST_URL: The complete URL. E.g. the resource filename with path and extension and parameters: tutorials/ex01server.asp?parm1=1&parm2=2
•REQUEST_FULL_PATH The resource filename with path and extension: tutorials/ex01server.asp
•REQUEST_PATH The path portion only of the request: tutorials
•REQUEST_FILE The filename and extension only: ex01server.asp
Originally Posted by Niels Liisberg: "Hi John;
They are on the way exept for the full url. The names is a litle different however:
•REQUEST_URL: The complete URL. E.g. the resource filename with path and extension and parameters: tutorials/ex01server.asp?parm1=1&parm2=2
•REQUEST_FULL_PATH The resource filename with path and extension: tutorials/ex01server.asp
•REQUEST_PATH The path portion only of the request: tutorials
•REQUEST_FILE The filename and extension only: ex01server.asp"
Originally Posted by Niels Liisberg: "Yes, but we have to obey RPG rules for parameters. However, it might be possible to add this feature if we decide that if all other parameters is input.
Is that acceptable?"
I have no idea... I think we need to see some examples and the pros and cons of it before we can decide.
Re: New features
Hi Niels,
just some thoughts in no relevant order:
•GZIP compression/decompression of ILOB and/or response object
•Security (LDAP lookup, Validation lists, etc.)
•Replace substring inside an ILOB
•Search of a substring within an ILOB
•Get an entry from a ZIP-file into an ILOB (also functionality to read filename, filesize etc.)
•Put an entry into a ZIP-file from an ILOB (also functionality of creating subfolders within the archive)
•DOM parser to support retrieval of element value (value1 and value3) of fx. <p> in: <p>...value1...<s>value2</s>...value3...</p>
•SAX parser for XML
•Description of how to integrate to C API's on AS/400 from RPG
•WebService consumer functionality
•Base64 encoding and decoding
•MD5 of a string and/or ILOB content
•Regular Expression support
•Set the content from ILOB into a Marker
•Import several file uploads directly into ILOB's without the use of temporary files
•Default values for a marker if SetMarker is never called: <%$ MyMarker : "My default text" %>
•Make it possible to support a URL like "/id/1234" where "id is the asp program and the rest is a parameter to the program.
•Customized error pages.
•Make it possible to write free-format code beyond the "comment" fixed-format column (is it column 80?).
•Make it possible for trace.txt to have *PUBLIC set to *RWX automatically.
•Make it possible for trace.txt to "round robin" after fx. 100K.
•Create functionality to execute Statements and getting MetaResults like in Java where you can get the name of column no. 5, type of data for column 10 etc.
•Functionality to create and send (S/)MIME based emails with as many attachments as you like (both text and html based etc.)
Most of these you already have from my "wishlist" emails (was the latest number 11?), and some of them might already have been implemented.... or....??
Anyway... before implementing any of the above... please call me to discuss so that you do not limit the functionality
I'll post more functionality another day.... trust me!
Best regards,
John Foldager
www.izone.dk
Re: New features
Ohh - the more i answer - the more questions I receive ...
I'll do it shortly:
* GZIP compression/decompression of ILOB and/or response object
-- Sceduled 2007 q1, for request/response - ILOB's later
* Security (LDAP lookup, Validation lists, etc.)
-- Sceduled 2007 q1, for LDAP lookup - validation list: use IBM API now
* Replace substring inside an ILOB
-- You can do that with a normal %subst in RPG
* Search of a substring within an ILOB
-- You can do that with a normal %scan in RPG
* Get an entry from a ZIP-file into an ILOB (also functionality to read filename, filesize etc.)
-- Sceduled 2007 q2,
* Put an entry into a ZIP-file from an ILOB (also functionality of creating subfolders within the archive)
-- Sceduled 2007 q2,
* DOM parser to support retrieval of element value (value1 and value3) of fx. <p> in: <p>...value1...<s>value2</s>...value3...</p>
-- not scheduled
* SAX parser for XML
-- You already go one build in XML parser that work from V5.1 - and now SAX for RPGle ... how many do you want ???
* Description of how to integrate to C API's on AS/400 from RPG
-- This is not the scope of IceBreak- but you can find fine samples here on code400
* WebService consumer functionality
-- can be made the "hard way" to day see the KRAK tutorial - the super easy way are not scheduled yet .... Portlets for WebSphere Portal server comes first...
* Base64 encoding and decoding
-- Sceduled 2007 q1,
* MD5 of a string and/or ILOB content
-- Sceduled 2007 q1 for strings, ILOBS later ...
* Regular Expression support.
-- Use the new C++ feature it has buildin reg.exp ...
Niels
Re: New features
Originally Posted by Niels Liisberg:
"Ohh - the more i answer - the more questions I receive ..."
Maybe you can find someone that can answer most of the questions for money
Originally Posted by Niels Liisberg:
"* GZIP compression/decompression of ILOB and/or response object
-- Sceduled 2007 q1, for request/response - ILOB's later"
(1)
Originally Posted by Niels Liisberg:
"* Security (LDAP lookup, Validation lists, etc.)
-- Sceduled 2007 q1, for LDAP lookup - validation list: use IBM API now"
Okay...
Originally Posted by Niels Liisberg:
"* Replace substring inside an ILOB
-- You can do that with a normal %subst in RPG"
Ohh... I was sure that %subst only worked on strings (max 32K)
Originally Posted by Niels Liisberg:
"* Search of a substring within an ILOB
-- You can do that with a normal %scan in RPG"
Ohh... I was sure that %scan only worked on strings (max 32K)
Originally Posted by Niels Liisberg:
"* Get an entry from a ZIP-file into an ILOB (also functionality to read filename, filesize etc.)
-- Sceduled 2007 q2,"
(1)
Originally Posted by Niels Liisberg:
"* Put an entry into a ZIP-file from an ILOB (also functionality of creating subfolders within the archive)
-- Sceduled 2007 q2,"
(1)
Originally Posted by Niels Liisberg:
"* DOM parser to support retrieval of element value (value1 and value3) of fx. <p> in: <p>...value1...<s>value2</s>...value3...</p>
-- not scheduled"
Okay... just keep in mind that it is valid XML so it should be possible to parse... but (1)
Originally Posted by Niels Liisberg:
"* SAX parser for XML
-- You already go one build in XML parser that work from V5.1 - and now SAX for RPGle ... how many do you want ???"
Just the two of them Well okay... this one has the lowest priority of all my wishes.
Originally Posted by Niels Liisberg:
"* Description of how to integrate to C API's on AS/400 from RPG
-- This is not the scope of IceBreak- but you can find fine samples here on code400"
Okay... I'll take a look around.
Originally Posted by Niels Liisberg:
"* WebService consumer functionality
-- can be made the "hard way" to day see the KRAK tutorial - the super easy way are not scheduled yet .... Portlets for WebSphere Portal server comes first..."
I know... but it is not "nice" code, so I'm looking forward to an implementation of it.
Originally Posted by Niels Liisberg:
"* Base64 encoding and decoding
-- Sceduled 2007 q1,"
(1)
Originally Posted by Niels Liisberg:
"* MD5 of a string and/or ILOB content
-- Sceduled 2007 q1 for strings, ILOBS later ..."
(1)
Originally Posted by Niels Liisberg:
"* Regular Expression support.
-- Use the new C++ feature it has buildin reg.exp ..."
Do you have an example of how to use a regular expression this way on a string and retrieve fx. parameter 1 and 2 from it?
Notes:
(1) Damn... we need this to create the applications of tomorrow!
Re: New features
I can't image why I forgot to put this issue on the list as it is one of the things that we have been talking about for more than a year now. I have just looked at your implementation of "pre-request exit program" and it would be cool to have an "error exit program" of some kind if errors occur.
It should run on the following situations:
•If a resource is not available... the program or file referenced in the URL does not exists
•If in a program I call a function SetErrorValue('CustomName' : 'CustomValue') multiple time it should add my name/value pairs to an array that I can access in the error exit program. When I wan't to pass the array on to the post-request exit program I call the SetError().
In both cases the response object of the original program should be discarded, and only the response object from the exit program should be valid.
It might be valuable to put an ILOB into a value and pass it on in the array
Best regards,
John Foldager
www.izone.dk
Re: New features
Another one...
It would also be cool to have an "post-request exit program".
It should be possible to get the response object from the original program and manipulate it; fx. GZIP it ... or call the before-mentioned Error exit program.
Best regards,
John Foldager
www.izone.dk
Re: New features
Hi John;
"post-request exit program" is not a good name ... lets refer to it as "pre-response exit program"
If we can agree on that, I'll put it on the list - it make totally sence.
"SetErrorValue" is already there: Use the "marker" feature to implement your own error list .
Niels
Re: New features
Originally Posted by Niels Liisberg:
""post-request exit program" is not a good name ... lets refer to it as "pre-response exit program"
If we can agree on that, I'll put it on the list - it make totally sence."
Whatever.... :-)
Originally Posted by Niels Liisberg:
""SetErrorValue" is already there: Use the "marker" feature to implement your own error list."
I'm not sure I understand... What I wan't is to parse my ILOBs, strings etc. from the called program to the "pre-response exit program". If I use the "marker" feature they will just be inside a response object and then I can't reference each of them directly... am I correct? I'm thinking ahead of what is possible today and tomorrow... thinking of what we can do with IceBreak in the "future"...
Best regards,
John Foldager
www.izone.dk
Re: New features
Hi Guys,
In the 'Official' Ajax code supplied with IceBreak would it be possible to add some additional JavaScript routines to allow the format of the returned data to be specified ('text' or 'xml'), also to allow the name of the call back back procedure that handles the returned data to be passed to the Ajax call.
I have attached some files that I use - ccsAjax makes the Ajax call to the server. Note that the doGet() and doPost() accept the required return data format and the name of the data handling procedure.
The other attached file, customerSelBox.js, shows an example of the use of this technique. The procedure self.loadData() makes the Ajax call specifying 'xml' for the returned data format. it passes self.dataTableHandler as the name of the procedure used to handle the returned data. self.dataTableHandler() then reads through the data and formats it for display in the HTML page.
It would be very nice if these features were included as standard in the 'Oficial' Ajax code for IceBreak.
The files I have attached work OK in IE6, opera, mozilla - but will almost certainly need to be checked/modified for other browsers and/or IE7!
Regards
Syd
Attached Files: files2.zip (3.6 KB, 90 views)
Re: New features
Hi Syd,
Originally Posted by Syd Nicholson:
"In the 'Official' Ajax code supplied with IceBreak would it be possible to add some additional JavaScript routines to allow the format of the returned data to be specified ('text' or 'xml'), also to allow the name of the call back back procedure that handles the returned data to be passed to the Ajax call.
I have attached some files that I use - ccsAjax makes the Ajax call to the server. Note that the doGet() and doPost() accept the required return data format and the name of the data handling procedure.
:
It would be very nice if these features were included as standard in the 'Oficial' Ajax code for IceBreak."
I haven't checked you code to see if you take this into account, but you [and the IceBreak Development Team] should remember that even though you POST or GET and knows that your service will return fx. "XML", it might in fact return HTML which can not be validated in the client. If your session has expired and you call a function that should return XML it might return a HTML login page instead.
Just a thought....
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Originally Posted by John Foldager:
"Hi Syd,
I haven't checked you code to see if you take this into account, but you [and the IceBreak Development Team] should remember that even though you POST or GET and knows that your service will return fx. "XML", it might in fact return HTML which can not be validated in the client. If your session has expired and you call a function that should return XML it might return a HTML login page instead.
Just a thought...."
Hi John,
I my case this is not a problem - this is from a client project of mine and I write both sides (server and client) part of the code. I know exactly the format and structure that will be returned.
However, I agree, that in a more commercial product a robust implemation is advisable. The code I supplied is provided only as an example, and might need modification to timprove it's suitability for other environments. I leave this up choice up to the developers - should they decide to include this type of feature in the IceBreak Ajax implementation.
Regards
Syd
Re: New features
I want to have access to three more parameters. If my request looks like:
https : / /mydomain.com/mypath/myapp.asp?param1=A¶m2=B#top (please remove the spaces around ' : / /'... forum will truncate the URL and wrap it in URL syntax).
1) GetServerVar('REQUEST_RESOURCE_FULL_PATH')
This should return '/mypath/myapp.asp'
2) GetServerVar('REQUEST_RESOURCE_FULL_URL')
This should return '/mypath/myapp.asp?param1=A¶m2=B#top'
3) GetServerVar('REQUEST_URL')
This should return 'https://mydomain.com/mypath/myapp.asp?param1=A¶m2=B#top'
Remember: None of the above should convert characters to uppercase!
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Also...
GetServerVar('REQUEST_RESOURCE') should not convert to UPPERCASE!
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Originally Posted by John Foldager:
"I haven't checked you code to see if you take this into account, but you [and the IceBreak Development Team] should remember that even though you POST or GET and knows that your service will return fx. "XML", it might in fact return HTML which can not be validated in the client. If your session has expired and you call a function that should return XML it might return a HTML login page instead."
Just a further thought on this matter.
In 'xml' format a javascript object is returned - this is not text. With 'text' format, text is returned and could be HTML.
The 'xml' object needs to be parsed with a siutable xml parser. The code for the parsing of the xml object could be included in a 'try-catch' construct to eliminate errors if the parsing should fail.
In the example code I provided I am looking for specific record types in the xml. If these record types are not present the length of the array of records that results from the parsing of the xml is zero. You will see that my code does indeed react to a no data situation - outputing a 'no data to display' message.
If the return type is 'text' - it would be necessary to analyse the text string to determine if it contained the expected response.
Regards
Syd
Re: New features
It would be great if you could group IceBreak server instances so that we could have option 12 to show the groups and then make it possible to go into a group to show the server instances of that group.
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
What do you mean with group? Do you mean you would like to resequence e.g. in port order?
Bent
Re: New features
Originally Posted by Bent
"What do you mean with group? Do you mean you would like to resequence e.g. in port order?"
Instead of having 50-100 IceBreak server instances I want an overview with fx.:
•Administration
•CustomerA applications
•CustomerB applications
•CustomerC applications
•Projects
•Test
•Websites
under each of these "Groups" I can then have 1 or more IceBreak server instances.
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Make it possible to create a function in a WebService so that you can do the following (with return values):
Instead of only this syntax:
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Hi John;
Yes, but we have to obey RPG rules for parameters. However, it might be possible to add this feature if we decide that if all other parameters is input.
Is that acceptable?
Niels
Re: New features
Hi Guys,
A happy New Year to all readers.
I have an idea for a new type of IceBreak object.
We have ILOBs (User Spaces) and very useful they are -- but when searched they must be searched sequentially, or part of the ILOB must be converted to an array for %LOOKUP. GSORT is another possibility when several data structure records must be searched
There could be another large object type that stores data - a User Index. Lets call these XLOBs or ULOBs
A user index comprises two parts - 1. the index (any character string/data structure) and 2. the associated data (another character string/data structure). Data can be placed in storage and retrieved in key sequence, much like using a database file.
A user index created as a session object would be automatically deleted when the session ends. User management of temporary objects would be eliminated
User indexes have the advantage of being faster than database files, do not require the creation (and management) of temporary data base files, do not hold record locks, and can easily be created and deleted.
Unlike user spaces, user indexes allow random access, so searching a user index merely requires retrieving a records by key.
Good idea - or should this be shot down in flames?? Your thoughts?
Regards
Syd
Re: New features
Originally Posted by Niels Liisberg:
"Yes, but we have to obey RPG rules for parameters. However, it might be possible to add this feature if we decide that if all other parameters is input.
Is that acceptable?"
Niels, I have no idea what you are talking about? "...that if all..."!!?
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Hi Syd,
Originally Posted by Syd Nicholson:
"There could be another large object type that stores data - a User Index. Lets call these XLOBs or ULOBs
A user index comprises two parts - 1. the index (any character string/data structure) and 2. the associated data (another character string/data structure). Data can be placed in storage and retrieved in key sequence, much like using a database file.
A user index created as a session object would be automatically deleted when the session ends. User management of temporary objects would be eliminated
User indexes have the advantage of being faster than database files, do not require the creation (and management) of temporary data base files, do not hold record locks, and can easily be created and deleted.
Unlike user spaces, user indexes allow random access, so searching a user index merely requires retrieving a records by key.
Good idea - or should this be shot down in flames?? Your thoughts?"
This sounds like a great feature! I'm in for it!
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Another really, really great feature would be to have the same functionality in IceBreak as we have in fx. Java regarding java.sql -- especially:
•DatabaseMetaData
•PreparedStatement
•ResultSet
•ResultSetMetaData
•Statement
I really hate the way embedded SQL works in RPG... I use it, yes... but it has so much limitations or requires so much coding to be dynamic.
Please implement this (we have already talked about this over a year ago) and integrate CLOB/BLOB fields of the resultsets with ILOBs!
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Hi Syd.
It sounds like a great feature
If I got it right: XLOB's is session base userindexes - just like ILOB's are session based userspaces.
Niels
Re: New features
"Hi Syd.
It sounds like a great feature
If I got it right: XLOB's is session base userindexes - just like ILOB's are session based userspaces.
Niels"
Yes - you got it right. Any timescales??
Re: New features
There is another new feature that would be great.
At present the server can be set to require the user to log on - this must be a OS/400 user.
It would be great if the server could be set such that it recognized either of two types of user - either an OS/400 User ID, or a 'virtual' user based on a userID/password file kept within IceBreak.
The maintenance of this User/Password file could be added to Admin server, and these user/passwords could then be applied system wide. The user table could also hold other data (eg. Name, telephone number, e-mail etc.)
The LogOn(), LogOff() and LoggedOn() functions could be modified to check the logon requirement of the server and process either type of log on.
It would also be great if the userID/Password fields were long enough to include e-mail addresses.
Additional functions could be added to provide access to the user data held in the user table allowing modification/listing of this data using IceBreak .asp pograms.
Such a feature would be a great addition, because, when implementing web sites that require this type of log on, developers would not need to 're-invent the wheel' for each site that was created.
Regards
Syd
Re: New features
Hi Syd;
Funny that you mention this with the log in - We are skipping the IceMenu framework that is addressing that topic.
It also contains tools to organize users into groups and design menu to those user and groups...
It is ready and will be shipped here in January
Niels
Re: New features
"Funny that you mention this with the log in - We are skipping the IceMenu framework that is addressing that topic.
It also contains tools to organize users into groups and design menu to those user and groups...
It is ready and will be shipped here in January"
That sounds great.
Would I be correct in assuming that that the menu page that shows the folder structure can be modified for other purposes. - eg. To show the contents and structure of IFS folders.
I am creating code to do just that and have had difficulty with the JavaScript. I have run into problems with JavaScript objects greater than 32K in size. The folder structures I am trying to display are much bigger (100 times perhaps) than 32K and it simply does not work!
At the moment I am creating code to display the folder structure one page at a time, with the folder structure held in ILOBs on the server.
Can your new menu system handle what would be a very large menus (say 500K up to 5MB). If it can then this would be extremely useful.
Regards
Syd
Re: New features
Originally Posted by John Foldager:
"I want to have access to three more parameters. If my request looks like:
https : / /mydomain.com/mypath/myapp.asp?param1=A¶m2=B#top (please remove the spaces around ' : / /'... forum will truncate the URL and wrap it in URL syntax).
1) GetServerVar('REQUEST_RESOURCE_FULL_PATH')
This should return '/mypath/myapp.asp'
2) GetServerVar('REQUEST_RESOURCE_FULL_URL')
This should return '/mypath/myapp.asp?param1=A¶m2=B#top'
3) GetServerVar('REQUEST_URL')
This should return 'https://mydomain.com/mypath/myapp.asp?param1=A¶m2=B#top'
Remember: None of the above should convert characters to uppercase!"
Hi John;
They are on the way exept for the full url. The names is a litle different however:
•REQUEST_URL: The complete URL. E.g. the resource filename with path and extension and parameters: tutorials/ex01server.asp?parm1=1&parm2=2
•REQUEST_FULL_PATH The resource filename with path and extension: tutorials/ex01server.asp
•REQUEST_PATH The path portion only of the request: tutorials
•REQUEST_FILE The filename and extension only: ex01server.asp
Re: New features
Originally Posted by Niels Liisberg:
"Hi John;
They are on the way exept for the full url. The names is a litle different however:
•REQUEST_URL: The complete URL. E.g. the resource filename with path and extension and parameters: tutorials/ex01server.asp?parm1=1&parm2=2
•REQUEST_FULL_PATH The resource filename with path and extension: tutorials/ex01server.asp
•REQUEST_PATH The path portion only of the request: tutorials
•REQUEST_FILE The filename and extension only: ex01server.asp"
Cool! ... I'm looking forward to this!
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Hi Niels,
Originally Posted by Niels Liisberg:
"Yes, but we have to obey RPG rules for parameters. However, it might be possible to add this feature if we decide that if all other parameters is input.
Is that acceptable?"
I have no idea... I think we need to see some examples and the pros and cons of it before we can decide.
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Hi Niels,
I haven't been able to find this anywhere in the documentation, so this is a request for it:
SesClearAll();
This should clear all previous set session variables for the active session.
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
Originally Posted by John Foldager:
"Hi Niels,
I haven't been able to find this anywhere in the documentation, so this is a request for it:
SesClearAll();
This should clear all previous set session variables for the active session."
You can actually do that by deleting generic
SesClrVar('*');That deletes everything
Re: New features
Originally Posted by Niels Liisberg:
"You can actually do that by deleting generic
SesClrVar('*');That deletes everything"
I assume that it only deletes "everything" for the current session?! Thanks!
From which build was this possible?
Best regards,
John Foldager
www.izone.dk
www.icebreakforum.org
Re: New features
yes it does
:-)
Bent