Re: Global concept

Yes, it's a common pattern, a singleton-as-servlet-context-attribute.

Another way to do it is to create an application extension.

Where we've been headed with Tapestry is to ease adoption.  I like this 
suggestion, because it formalizes something you end up doing anyway.  For 
example, the Visit concept could be done (and re-done) in every application, 
but moving it into IEngine/AbstractEngine means that its done once and done 
right ... easier to explain how to leverage the existing tools that to describe 
how to build your own tools.

As Tapestry evolves, I'm continuing to see improvements where we replace 
inheritance with aggregation.

Having the framework formalize this means that the framework takes care of 
instantiation and provides a consistent, formal reference.

One idea I've been playing with is that the Visit (and, perhaps, the Globals) 
should have optional interfaces they can implement.  For example, if the Visit 
implements IEngineAware, then setEngine() will be invoked.  This gives the 
Visit a chance to hold a reference to the engine, or otherwise initialize using 
the engine.


--
[email protected]

http://tapestry.sf.net
> hi,
> 
> perhaps i'm a little daft, but i dont get it... if - as you said below -
> you're creating it as a singleton, why do you even need framework support
> for it, instead of just writing MyFoo.getInstance()?
> 
> i'm aware, there are some classloading issues with a singleton (although
> this has not come up as a problem for me in recent containers), so i keep
> my stuff in the ServletContext as it's supposed to be - but since that
> would be inconvenient to access, i usually wrap my stuff around with some
> code that sets it up as a ThreadLocal (that is statically accessible)...
> so it becomes very convenient to access (anywhere with no casting), since
> i can still say MyFoo.getInstance(), and have the flexibility as to where
> it's really coming from (eg. it doesnt strictly need to be "global")...
> also, i have some concerns about having only one global... you would
> probably need a Map of them... and you still need to the casting
> everywhere you need it...
> 
> so, i wouldn't bother to add this to the Tapestry framework itself, it
> already supports what you need, here's an example:
> http://flock.sourceforge.net/xref/net/sf/flock/webapp/FlockTapestryEngine.html
> http://flock.sourceforge.net/xref/net/sf/flock/webapp/FlockContext.html
> 
> ... and you set it up in the application servlet init() for example, or
> lazy-init, or whatever works for you.
> 
> best regards,
>     viktor
> 
> On Mon, 30 Dec 2002 06:37:36 -0500, "Howard M. Lewis Ship"
> <[email protected]> said:
> > A very good idea, I think.
> > 
> > ----- Original Message -----
> > From: "Malcolm Edgar" <[email protected]>
> > To: <tapestry-contrib-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> > Sent: Monday, December 30, 2002 5:59 AM
> > Subject: [Tapestry-contrib] Global concept
> > 
> > 
> > > After Howards email about Visit object names including Global, I started
> > > thinking it would be really good to have a shared global object in
> > Tapestry.
> > >
> > > I want to kick off a discussion before putting in a Feature Request.
> > >
> > > Regards Malcolm
> > >
> > > Global
> > > ======
> > >
> > > Aim
> > > ---
> > > Provide a shared global object that can be used for globally accessed data
> > > or utility methods. Currently it is recommended that the SimpleEngine be
> > > subclassed to provide a point to hang shared data off, or access global
> > data
> > > via the ServletContext accessed from the IRequestCycle.
> > >
> > > Conceptually it simpler to have a global object available throughout the
> > > framework.
> > >
> > > Design
> > > ------
> > > A global bean object modelled on the access style of the Visit object.
> > >
> > > The global object would have an accessor method added to IPage interface:
> > >
> > > public Object getGlobal();
> > >
> > > This object would be instantiated via a no args condtructor, with the
> > class
> > > name specified in the Application.specification as is done with the visit
> > > object. This object should follow a singleton style design pattern, so
> > their
> > > is only ever one instance available.
> > >
> > > This object should be stored in the ServletContext under the key
> > > 'net.sf.tapestry.global' so that it can potentially be shared with other
> > > Servlet components.
> > >
> > > Scope
> > > -----
> > > Global object: shared application data
> > > Visit object: user specific data
> > > Persistent page properties: user page specific data
> > >
> > > Example Usage
> > > -------------
> > > Application properties
> > > Application constants
> > > Cached data
> > > Connection DataSources
> > >
> > >
> > >
> -- 
>   
>   [email protected]
> 
> -- 
> http://fastmail.fm - Accessible with your email software
>                       or over the web
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Tapestry-contrib mailing list
> Tapestry-contrib-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/tapestry-contrib


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf