My two cents:
The only way IceBreak or any other toolset could support ASP.Net would be to run under the Microsoft .Net Framework stack and support Microsoft Code-Behinds, Event Model, etc...
Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site:
http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
----------------------------------------------------------------------
message: 1
date: Tue, 4 Jan 2011 21:11:44 -0000
from: "Maurice O'Prey" <Maurice.Oprey@xxxxxxxxx>
subject: Re: [WEB400] Fwd: IceBreak as an alternative to Apache?
Henrik
Who is using fancy buzzwords, either IceBreak supports Microsoft ASP.NET pages or it doesn't (and from what I've read so far in these responses) it doesn't?
Please stop mixing the term ASP with ASPX (they are completely different technologies). The rest of the echo stuff is complete crap.
- Maurice O'Prey
Let me try to explain this without fancy buzzwords:
In Icebreak you place your sourcecode in an IFS files. This file looks and behaves like an ASP or PHP page where you with a special syntax can switch between server side code and client code (HTML etc.) so the sourcecode can hold both.
What Icebreak does, is that it translate this IFS file to a RPGLE sourcemember where all client code (HTML etc.) is imbedded in procedure call like WrtNoSection('bla bla bla') in CGIDEV2 or echo('bla bla bla') in my frame- work that both write the embedded client code into the HTTP output buffer.
The smart thing is that you do not have to code ...
echo('<html>');
echo('<body>');
echo('hello world');
echo(</body>');
but can code large sections of client code like this
some rpgle serverside code
%> // start client code
<html>
<body>
hello world
</body>
<% // end client code
*inlr =on;
midrange.com
