Jon Stevens wrote:
>
> on 10/16/2000 10:24 AM, "Fedor Karpelevitch" <[EMAIL PROTECTED]>
> wrote:
>
> > Hi!
> >
> > First of all I wand to say that all this makes a lot of sense to me and I
> > see this a a right way to go. Cuple of thought though:
> >
> > I do not really think the changes you propose really constitute a move from
> > "Push" to "Pull". If I understood everything correctly you simply put a
> > structure into the process by moving "Push" to the global level. Am I making
> > sense?
>
> Yes, but I needed a way to describe this and it is still a bit of a pull
> process since there is no concept of pushing stuff into a context.
> Essentially those objects will be placed there for you based on
> configuration options or hard coded into a single Default.java Screen.
>
> > Also I do not think it should eliminate the need for per-screen context.
> > Although a lot of stuff may be moved to the global level some would still be
> > better at the screen level for various reasons such as security or
> > performance.
>
> Right...I agree. I don't want to get rid of that, but I think that at this
> point, I can't think of a single 1 foot case where it would be needed
> anymore.
>
> > Another thought is that in addition to screen and global context it nmakes
> > sense to have a session context. First candidate to reside in it would be
> > User.
>
> Funny, I just wrote that in the IRC window before I got your email. :-)
>
> Here are the three contexts that I envision. We can consider them in
> different lifecycles.
>
> 10:16:19 AM: <jon> 1. session specific
> 10:16:24 AM: <jon> 2. instance specific
> 10:16:30 AM: <jon> 3. global specific
>
> #1. would be tied to a user's session.
> #2. would be available at the Module (screen/action/navigation/layout)
> level.
> #3. would be available to the particular application running within Turbine
> (determined after Shamil's changes go in effect).
>
> > I remember that in your discussion on IRC you were talking about merging
> > global context into the screen context on each request. I am not sure this
> > is the best way to do it. What about keeping all context separately and when
> > looking for an item simply look for it first in screen context then in
> > session and then in global. This looks a bit cleaner and I suspect it will
> > have somewhat better performance vs. merging Hashtables all the time... not
> > sure though.
>
> Yes, you have a very good point. However, the issue with this would be that
> this logic would probably need to be embedded within Velocity itself. Given
> that Turbine is agnostic to template engines, we would need another way to
> provide this functionality. The only way I can think of right now is to do a
> merge.
>
> > Last one. What do you think about explicit scope specification i.e:
I am trying to figure out how this is going to be implemented differently than
things are right now. You have an application, you create a base Screen/Page
that pushes objects that are generally useful. You subclass the base modules to
add objects that are more specific to a screen or two.
Why make the designer have to decide whether the object has global, session, or
page scope. I thought this was something in JSP that was overkill for a
template system. If there is something being stored in the session that is
global in scope add it to the context in a base module, if it is only relevant
to a few screens, add it in a child module.
> >
> > $abc looks for abc first in screen then in session then in global
> > $global.abc looks for abc only in global
> > $session.abc looks for abc only in session
>
Is "abc" the same class of object in each case? Is it fairly obvious to the
designer which one to use in which circumstance? Why not just give the designer
abc1, abc2 and abc3; and hopefully name them so that their purpose is clear.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
