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:
>
> $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
Hmmm...that is another good idea and would not require changes to the
template engine. However, it would be nice to not have to embed the logic
for where to look for the object into the template. It should be automatic
IMHO.
I'm really glad this has everyone thinking about solutions. :-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
