Re: Reporting tools



I always find it a little suspect when people mention "linux" in context
with "dotnet"...

If you are writing a major web application, then deploying it in IIS/Win2003
is surely the best route.

If the Linux requirement is a customer "must have" then of course, the
apache/mono etc stuff comes to play.

But some of the comments appear to be simple Microsoft bashing (I'm not
suggesting that Glen is a Microsoft basher in any way!).

Regards
Simon
"Tony Gravagno" <g6q3x9lu53001@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7hjlu1lepaf7hhem9jg3dfeqe6dsjoltej@xxxxxxxxxx
"Glen B" wrote:

.NET is fine, unless you happen to be in a *nix environment and want to
build the reports there.

That's not entirely correct. Using a tool like Visual MainWin you can
write all of your code in .NET and deploy it in *nix. It does this by
(re)compiling the .NET Intermediate Language code into Java byte code
via Mono.

So let's connect the dots here: Write ASP.NET code using the free
Visual Studio Web Developer Express Edition, compile to Java with the
free MainWin, deploy using free Apache/Tomcat. Not bad, eh?


Now let's say I have a software application with the UI in a browser
(e.g. AJAX front-end) and I want to give it a .NET plug. What would I
do to the application to allow it to play in the .NET world?


It's not that simple because .NET is a local Windows service and client
architecture. Javascript is a platform independant technology, so you
wouldn't be able to build a cross-browser/cross-platform product with it
and
.NET. That's not to say you can't make them all work together with
ASP.NET.
However, that limits your HTTP services options.

Well... If you look around you'll see companies offering lots of
cross-browser compatible components for ASP.NET. This is how they
work: You drop a component on your ASP.NET design page. The visual
widget that you see is only a generic instance of the control. At
runtime, a browser connects to the server and identifies the
browser-type in the headers. A properly coded control will call a
subroutine to return the proper JavaScript, DHTML, and CSS specific to
that browser. For Ajax-enhanced controls, the script that goes to the
client contains the browser-specific nuances required to implement
Ajax.

ASP.NET doesn't care what kind of client you have - Opera, Safari,
PDA, SmartPhone, Linux, Mac, what-evah. Anyone can write an
Ajax-enabled component like this provided they understand how to
properly code for each browser type - it's essentially just another
CASE statement to support a new client technology. For what it's
worth, you can just as easily export Flash/ActiveScript/Flex using
this same methodology.

Of course you can do this in any language: PHP, Perl, and other
languages all have a CASE/SWITCH statement. Even Pick BASIC can serve
up Ajax via FlashCONNECT, Coyote, etc.

But I don't think any of this answers Dawn's question about plugging
into .NET from some other language. As I mentioned in my other post -
HOW you do it depends on WHAT you're plugging to/from.


I proposed an RFC for communication of MV data, back in 2000. It got zero
interest, apart from a few other propeller heads.

I remember all of that and I think you just hit it on the head. It
was a bit too cerebral Glen, you needed to be a real geek to
appreciate the potential. With the advent of Web Services it seems
your work might be appreciated more these days - some ideas are just
ahead of their time.

T


.



Relevant Pages

  • RE: Seek advice for ASP/PHP
    ... They only need a browser. ... * Can Mac and Linux machines run these web forms? ... > client side web forms, but for all browsers and operating systems. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Which Is The Better Approach To Working With Javascript?
    ... It wasn;t origally deigned as a general purpose language at all. ... developed without context and implementation in mind. ... that js was originally developed for the browser - strictly. ... client and server functionality...the context would be the service of http ...
    (comp.lang.php)
  • Re: Attempt to de-mystify AJAX
    ... > conviction when we know the client is leading ... > code into the browser that it's now just as thick as anything people ... > 1) IT used to think BUI development was easy. ... > 2) Therefore IT people advocated thin client. ...
    (comp.databases.pick)
  • Re: form field/spreadsheet question
    ... There is no compiler for Javascript, ... I am comparing the language features supported by different ECMAScript ... It runs fine in my browser. ... program that will output a stand-alone EXE file to provide equivalent ...
    (comp.lang.javascript)
  • Re: Several questions about the LG Voyager
    ... thing has got iPhone-style WebTV browser device written all over it. ... attaches to without a sellphone company interference. ... file off the main computer on the tablet far away, ... N800 or N810 Linux internet tablet the sellphone company DOESN'T get to ...
    (alt.cellular.verizon)