I will step up to write this code. (if it is what I think it is)
I have responded to the message by beginning a requirements document.
http://www.officevision.com/pub/HTML-Widget/
Please read it and send me any comments.
The following are the questions I need advice on in order to
On Thu, May 24, 2001 at 08:20:01AM +1200, Stuart Frew wrote:
Greetings,
One problem with using cookies for session management is that the user
can have two browsers open doing the same process.
Which means the first cookie Session ID will be over writen by the
second one. Which can lead
Stuart Frew ([EMAIL PROTECTED]) said something to this effect on 05/23/2001:
Greetings,
One problem with using cookies for session management is that the user
can have two browsers open doing the same process.
Which means the first cookie Session ID will be over writen by the
second one.
darren chamberlain [EMAIL PROTECTED] writes:
Chip Turner ([EMAIL PROTECTED]) said something to this effect on 05/23/2001:
If I could make a suggestion -- don't depend upon a CGI.pm interface
for form variables. Abstract it away. One option would be to use
closures:
I agree with not
From: [EMAIL PROTECTED]
A better way for session ids is to put them in front of the URI:
http://www.nus.edu.sg/dfd3453/some/path/and/file.html
(...)
These session ids are sticky as long as you only use relative paths in your
html. Note: You may want to put your images in a directory that's
Yeah, create a safe link jumping point. Something that you'd link to
instead of the external link, and pass in the external link, without a
session_id so that the HTTP_REFERER won't have the session ID.
Don't rely on IP address for more reasons then you mentioned...
It might not hurt to
Hey all,
Let me describe what I have been imagining as the ideal widget for what I am
writing:
1 - it can look to its environment to determine how to render itsself
- am I on an HTML page or something else?
2 - it has properties that can be set and remain static no matter who's
At 08:50 PM 5/23/01 -0400, Adi Fairbank wrote:
Stephen,
I read your proposal and I like it a lot. I will help filling out the
HTML::Widget::HTML* space (in your package structure suggestion).
However, I like Gunther's suggestion for a namespace of Widget:: better than
HTML::Widget::, because
Related to the previous discussion of closures vs object interface (eg
param) for getting CGI form data into the widgets:
While I think that it is clever to allow an interface to change where the
parameters come from, I think in practice there are different things to
expect. eg how to deal
On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote:
darren chamberlain [EMAIL PROTECTED] writes:
The nice thing about closures is they could hide any interface at all
behind them; all that is required is that the function that generates
the closure follow the very simple convention
I have a couple modules that might be the start of what you are calling a
Widget system. I'm not sure if my modules are in line with the thoughts
expressed on this list. Pardon me if this is something different: I've been
loosely following this discussion..
Using my library, whenever I want a
[[ This is a resend.. did some cutting and pasting of code into telnet
windows that messed it up through shell expansion. My bad. ]]
I have a couple modules that might be the start of what you are calling a
Widget system. I'm not sure if my modules are in line with the thoughts
expressed on
This is an even more pronounced problem with sessions IDs in
URLs, though. With cookie based session tracking, the second
browser window will send the same cookie that the first browser
window received.
And there lies the rub.
The user is using the system to process client A. The cookie
At 08:39 25.05.2001 +1200, you wrote:
And there lies the rub.
The user is using the system to process client A. The cookie contains
stateful information including the client ID.
They then open an new browser window, and lookup client B, recieving a
new session ID with new state information,
I'm having a recurring problem that I can't find comment about in the docs, and
I was wondering if anyone might have some insight on this.
I have a web site where *everything* is mod_perl handlers. The problem that I'm
seeing is that I will go to the url http://hostname/foo and I get the content
i'd still use a cookie to indentify the user. why not include
the client id as part of the submission from the browser. it
is easy to keep detailed data in the cookie separate for each client
$sessionData{$clientKey}{$clientDataStuff}=$in{DATAKEY}
Stuart Frew wrote:
This is an even more
Morning,
this has come up a few times before, but I haven`t found the exact answer
yet.
I want to test if enabling keep-alive makes some pages load faster. I know
the disadvanteges (could use massive amounts memory), but hey, it might
just work.
I`m using the wellknown
My company, to my objections, recently decided to force all of our new
servers to running only Win2k. I won't go into the details, but let's just
say that in our standard hosting facilities, nothing runing Linux is allowed
anymore. This kinds of screws my department, as we have just finished
* Tom Gioconda ([EMAIL PROTECTED]) [010524 20:06]:
My company, to my objections, recently decided to force all of our new
servers to running only Win2k. I won't go into the details, but let's just
say that in our standard hosting facilities, nothing runing Linux is allowed
anymore. This
Opps forgot to CC the list
--
Cheers Stuart
---
New Zealand Revolution
[EMAIL PROTECTED]
+64 9 918 7663
On 24 May 2001 14:57:09 -0700, ___cliff rayman___ wrote:
Stuart Frew wrote:
On 24 May 2001 14:21:32 -0700, ___cliff
so who's doing the perl wrappers?
-- Forwarded message --
Date: 22 May 2001 23:48:06 -0400
From: Alex Graveley [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: ANNOUNCE: Soup (0.2)
Ximian is happy to announce the first release of Soup, a Simple Object Access
At 10:22 AM 5/24/2001 -0700, Paul Lindner wrote:
On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote:
darren chamberlain [EMAIL PROTECTED] writes:
The nice thing about closures is they could hide any interface at all
behind them; all that is required is that the function that
On 24 May 2001, [EMAIL PROTECTED] wrote:
I'm having a recurring problem that I can't find comment about in the docs, and
I was wondering if anyone might have some insight on this.
I have a web site where *everything* is mod_perl handlers. The problem that I'm
seeing is that I will go to the
It was my impression that PerlEx handled the persistance and what not, but
it wouldn't allow one to make a content handler using perl. I need some way
of processing every html file through my TemplateHandler::handler method.
The way I was doing this was telling Apache to use my method as the
Hi all,
I've been trying to compile apache with mod_perl and mod_php support.
I've been following the instructions from the mod_perl Guide
[http://perl.apache.org/guide/install.html#mod_perl_and_mod_php] (and
just assuming that it's similar for php3 and php4).
I haven't been able to get
On Thu, 24 May 2001, Chethan Pandarinath wrote:
Hi all,
I've been trying to compile apache with mod_perl and mod_php support.
I've been following the instructions from the mod_perl Guide
[http://perl.apache.org/guide/install.html#mod_perl_and_mod_php] (and
just assuming that it's similar
* Tom Gioconda ([EMAIL PROTECTED]) [010524 23:03]:
It was my impression that PerlEx handled the persistance and what not, but
it wouldn't allow one to make a content handler using perl. I need some way
of processing every html file through my TemplateHandler::handler method.
The way I
On Wed, 23 May 2001, Adam Prime wrote:
I was looking through the mod_perl archives and saw a post from doug about a
credit card processing system called 'creditor' i looked on the covalent
web site, but i couldn't find any info. Did this thing ever see the light
of day?
yes, credator
Jay,
I think that pretty much describes what I have in mind ...
plus a few other features.
Hopefully within a week or two (based on demands of other *paying* jobs),
I will have a working distribution with most of the bare-bones plumbing in
place and a little configurable date widget
Gunther Birznieks [EMAIL PROTECTED] writes:
While I think that it is clever to allow an interface to change where
the parameters come from, I think in practice there are different
things to expect. eg how to deal with multi-values? How to deal with
file upload field? I think there are quirks
Paul Lindner [EMAIL PROTECTED] writes:
On Thu, May 24, 2001 at 09:59:36AM -0400, Chip Turner wrote:
darren chamberlain [EMAIL PROTECTED] writes:
The nice thing about closures is they could hide any interface at all
behind them; all that is required is that the function that generates
31 matches
Mail list logo
