Thank you Richard
Regards
Maurice
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
