Hi,
I'm happy because I got exactly what I was looking for: a discussion about
Inline::HTML.
Here's a few points about how I did it:
1- I did in fact implement a mini HTTP server that communicates with the
browser. It way seem
like I'm reinventing the wheel here, but my idea was really to use the
browser only for it's GUI
capabilities. I didn't want to have to set up stuff under the user's
HTTP server or whatever. I
wanted it to be simple to use.
2- I also have an "stack" of HTML "calls", so one HTML function can "call"
another, and
when the second one terminates, then the first one is refreshed with
whatever variables
where set by the second call.
What I was interested in is the use of a web browser as a (limited) GUI
rendering engine. Any
web browser can create and allow interactivity with a certain number of
widgets. One of the
problems of creating GUI is portability across platforms. There is also
usually a lot of
dependencies (other packages) that are required on the user's part. The
browser seemed like
a nice portable solution.
I really like the Inline framework for this kind of stuff because it makes
everything look so clean and "magical". Even the Inline::SQL example I gave
yesterday seemed to have sparked interested because
Inline creates such a clean boundary between the Perl stuff and the "other"
stuff.
Cheers,
Patrick
----- Original Message -----
From: "Nadim Khemir" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 26, 2002 5:57 AM
Subject: RE: Inline::HTML...
>
> Hi all. I am not very interested in this Inline::HTML module but ...
>
> > -----Original Message-----
> > From: Sam Tregar [mailto:[EMAIL PROTECTED]]
> > > On Monday 25 February 2002 08:50 pm, Sam Tregar wrote:
> > > > It will need to somehow act as a web server in order to give the
> > > > launched browser something to make the initial request and submit
the
> > > > form to.
> > >
> > > Oh, I understand. That is why I recast Inline::HTML in a different
> > > light where it was a little more interesting. Otherwise you'd have to
> > > make a tmp file, write HTML into it, and launch the browser on that.
> > > That's just shell script -- no chanllenge. :-))
> >
> > Try it - it won't work. The browser needs somewhere to submit the form.
> > That's what I meant by "ACTION" since that's the attribute of the <FORM>
> > tag that tells the browser where to submit the form.
> >
> > -sam
> >
>
> 1/ Sam take it easy on Binkley you last mails were quite devastating (I
know
> you meant well) If Binkley wants to add another CPAN module that he like,
> let it be. Sam is right for one thing let's not reinvent the wheel.
>
> 2/ A browser does not need to have a server to do work. The statement Sam
> give in his mail (see above) is plain wrong. The scripts embedded in the
> html page can do some work. This is not theoretical, I did it (in perl)
and
> Binkley is right that no challenge.
>
> 3/ If all you need is is too get input locally (not from an extern system)
> and have it graphical.
> a/ Have a look at WxPerl it might surprise you.
> b/ Under windows, Win32::Gui may have something for you
> c/ The idea of embedding a web server was not that foolish
>
> Nadim.
>
>
>
