> > 2) Change things so that global objects are made available at the top
> > level instead, so $toolbox.ui becomes $ui. This will break all templates
> > that are currently using $toolbox (mainly mine and Jason's I think - but
> > maybe some others), but has the advantage of consistency. I like this
> > option, because as you get to specifiy the tool names in a property file
> > I can't see a problem with name collisions. (It would be implemented by
> > building a global context which is then wrapped by the request-specific
> > context).
> >
> > This is my favoured option, but I need agreement from those who would
> > need to change their templates...
>
> This would cause namespace collisions because people could be putting
> something into the Context already.
This could potentially happen, but who will tell the designer
what they can and can't use the templates?
I think the pull model will be successful and will lead to
a relatively small number of tools with a specific purpose.
I think it will be unlikely that 5 UIManagers will surface,
and if everything is controlled from the TR.props file
then a collision will be fairly visible.
> > 3) Like (1) but provide the option to have other tools also available
> > via a handle. So TR.props would have lines like:
> >
> > toolbox.global.handle=toolbox
> > toolbox.request.handle=
> > toolbox.session.handle=
> >
> > and where no handle is given the tools go at the top level.
> >
> > This is the most complete solution, but involves a bit more work and I'm
> > not sure whether this level of flexibility will really be used. I'm
> > willing to do the extra work if (2) is rejectied though rather than go with
> > (1) which is a bit gnarly...
> >
> > Sean
>
> Damn. I'm not really sure the best way to go.
>
> Right now, we have (for tools in a global per-request scope):
>
> context.put ( "data", data );
> context.put ( "link", new TemplateLink(data) );
> context.put ( "page", new TemplatePageAttributes(data) );
> context.put ( "content", new ContentURI(data) );
>
> I'm starting to think that the current objects that are in this namespace
> should just remain in that namespace as breaking existing templates would be
> bad.
>
> I think that new objects should be configured via a $toolbox just like they
> are already. I don't like the idea of getting rid of $toolbox because of
> namespace issues as well as the fact that it helps keep the whole idea that
> there are "tools" in the "toolbox".
I think the templates would actually be much cleaner without
the $toolbox prefix, and I don't think the template engineer
really cares about the toolbox per se, they just want to
know what they are supposed to use. I have honestly found
$toolbox.ui.bgcolor a little cumbersome and would actually
prefer to use $ui.bgcolor. I think someone would have to
be fairly careless to run into a namespace problem given
that everything is setup in TR.props.
I'm still +1 for 2) :-)
jvz.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
