Thanks, Slava
Would the responder then have a namespace in common among HTTP threads using
an explicit bind? Sure, thanks.
Mostly I was trying to take advantage of the 'look in a chain of assocs
until you find it' functionality, and thought I could do so with a
combination of make-assoc and bind fairly cheaply. I had a list of general
replacements, and specific ones, and ones that change rapidly, and thought
that chaining would be 'better' than cloning & adding specifics each time.
One of the reasons I was drawn to Factor for web is that I understood it to
have less startup costs - it's always in memory, etc. I am doing a local
(desktop) website that will have a lot of quick interaction, and didn't want
to save/load all of it each ping. So I keep it in global memory,
serializing to disk after n changes. Please feel free to point me in some
direction if this seems foolish.
The only odd problem I've had so far, that I don't have pinned down enough
to report, is that occasionally chrome and firefox on an xp box where I do
most development (day job) will clearly be interacting with a different
webserver. Usually I've been in both, correctly interacting, then make some
change (or possibly have a crash). I'll restart factor & the primary
browser (usually chrome) and it initializes properly, but the other browser
(usually ff), which was open all along, still retains the old in-mem data.
I can interact with it successfully, and it is clearly the version from
before the factor restart, but task manager does not list factor. I can
even close all ff windows and restart ff and still have this happening,
although as I type that I realize I didn't check the task manager to make
sure some hidden ff process wasn't keeping it open.
Once I even tried gradually killing random processes until I found the
culprit. I killed all for me, most for system, when I killed one I
shouldn't have. But throughout, I had a responsive web server in the other
browser.
This has happened across many factor builds since mid November, but I can't
swear to you the first time I saw it.
Jim
On Sat, Jul 10, 2010 at 4:32 AM, Slava Pestov <[email protected]> wrote:
> Hi Jim,
>
> Every thread has its own namestack. The listener runs in its own
> thread and so does every HTTP request. So dynamic variables are not
> the right abstraction here unfortunately. What you should do instead
> is have the furnace action set form values with set-value, and access
> those values from the fhtml template. The best way to save a value
> between invocations of an action is to persist it in a database,
> because then your web app will support transparent fail-over. Another
> good approach is to subclass the dispatcher responder and store them
> in there, and add your actions to the dispatcher as well. If you're
> interested I'll write up an example of this pattern.
>
> Slava
>
> On Sat, Jul 10, 2010 at 4:21 AM, Jim mack <[email protected]> wrote:
> > When rendering an fhtml page within the furnace.alloy framework, I am
> trying
> > to get to the same namespace that the listener is in. In other words, I
> > expected to use set in the listener, then get (on the same key) in the
> fhtml
> > page, but it returns f. I see that the page has a namestack 11 deep, my
> > listener's is 4.
> >
> > I think I understand cset and cget, sset and sget, and html forms'
> set-value
> > and value, but am trying for something a little more global but not quite
> > global-global. Is the 4th namespace when in listener unreachable from
> the
> > furnace.alloy namestack?
> >
> > --
> > Jim
> > "I'm for extending the working Medicare program for our seniors all the
> way
> > back to contraception, so Americans can concentrate on living their lives
> > without fear of changing a job, going bankrupt from deductibles or
> fighting
> > HMO bureaucracy."
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Factor-talk mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/factor-talk
> >
> >
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Factor-talk mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
Jim
"I'm for extending the working Medicare program for our seniors all the way
back to contraception, so Americans can concentrate on living their lives
without fear of changing a job, going bankrupt from deductibles or fighting
HMO bureaucracy."
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk
