[albatross-users] Levelling the "random vs non-random" field

[Dave Cole]

>>>>> "Matt" == Matt Goodall <matt at pollenation.net> writes:

Matt> Hmm, just a random thought, but would it be useful/possible to
Matt> take the page_enter/leave concept and make pages with persistent
Matt> state? I'm thinking along the lines of pickling the
Matt> non-transient properties of a page instance to the session
Matt> rather than mucking about with add_session_vars. Woah, best stop
Matt> this train of thought now or I'll want to play even more ;-).

You could get a poor mans version of the same thing by just placing
all persistent information about each page in a single object.  That
single object could then be placed into the session.

Some funny untested code:

    class MyCtx(albatross_ctx):
        def set_page_state(self, name):
            # Create a page state dictionary in the session if it does
            # not already exist
            if not hasattr(self.locals, '_page_state'):
                self.locals._page_state = {}
                self.add_session_vars('_page_state')

            # Find the state for the current page
            state = self.locals._page_state.get(name)
            if not state:
                state = Vars()
                self.locals._page_state[name] = state

            # Place current page state information in _state for
            # template access
            self.locals._state = state
            return state

Then in your page module or whatever...

    def page_enter(ctx):
        ctx.set_page_state('blah')

    def page_process(ctx):
        ctx.locals._state.something = 'or other'

    def page_display(ctx):
        ctx.run_template('blah.html')

The in blah.html...

    <al-value expr="_state.something">

>>  That would be cool to have.  I spent a little time looking at
>> Twisted when I had to build a forking server.  I could not get
>> Twisted to do what I wanted and did not have the time to figure it
>> out.
>> 
Matt> Twisted doesn't fork, could that be why you had trouble? ;-). At
Matt> least, I don't think it forks?!

I used the wrong term.  What I meant to say was that the server had to
talk a TCP protocol then fork and monitor child processes.

Matt> I think scgi forks. I was wondering about that as yet another
Matt> request adapter but its lacking that "itch to scratch" quality
Matt> for me now that there is fastcgi support.

Matt> Perhaps a FeatureRequest page to go alongside the
Matt> ProposedChanges page on the wiki would be a good way of
Matt> gathering ideas for future versions? That might also help keep
Matt> track of things as people wander in and out of the project, as
Matt> invariably happens with open source.

Good idea.

- Dave

-- 
http://www.object-craft.com.au