You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by John McNally <jm...@collab.net> on 2001/03/21 23:05:43 UTC
[Proposal] modify ApplicationTool interface
I would like to modify the ApplicationTool interface so that the init
method is
void init(String toolName, Object data);
It would be useful for tools to know the name given to them in the
properties file. They could use this to get other configuration
properties. For example right now UIManager is given the handle "ui" in
the context and it has a configuration property
tool.ui.skin
It could be that some tools are useful in more than one configuration,
so with the modification to the init method above you could have
tool.global.ui1=org.apache.turbine.services.pull.util.UIManager
tool.global.ui2=org.apache.turbine.services.pull.util.UIManager
tool.ui1.skin=default
tool.ui2.skin=alternate
(UIManager might need more properties, if this would actually be useful
for this tool, but this is the idea.)
I could define a different interface for tools that might be used this
way, but the Pull service is fairly new and I wonder if it would just be
better to keep the interface decision simple.
John McNally
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [Proposal] modify ApplicationTool interface
Posted by John McNally <jm...@collab.net>.
The basic idea is more torque/om oriented. I was trying to think of an
easy way to pull any object into the context based on a query
parameter. So a link might have issue_id=501 then a report template
could have
#set ($issue_id = $data.Parameter.getString("issue_id") )
#set ($issue = $om.Issue.setKey($issue_id) )
and then the template would show the various attributes of an issue.
In order to keep the coupling to the om/peer methods down I thought the
om tool would define a Factory responsible for retrieving the objects.
Torque would generate a Factory for the om objects but EJB objects could
be used as well, for instance.
I was thinking one might define a few of these to avoid namespace
conflicts or to match packages, so that the template designer does not
necessarily know about packages but they have a couple tools
$catalog and $admin that have objects appropriate to these tasks.
These tools could both be om tools but have a different Factory
configuration. But I think something like
$om.catalog.Department.setKey...
$om.admin.UserAccount.setKey...
is not much more difficult. I'm not sure where the factory classes
would be defined other than TR.props, but it could work this way
regardless.
That was the basic idea. I have added some code along these lines (see
o.a.t.om.OMTool), but I have not finished it as I had not figured out
how to enforce security policy and it might be better to have access to
the objects a little less open. So I am waiting till I need the
functionality before finishing it.
Anyone who sees any benefit to this approach and wants to push it ahead
let me know, and of course I would like to hear concerns before I start
down this path again.
John McNally
Jason van Zyl wrote:
>
> John McNally wrote:
> >
> > The idea is more related torque/intake though I am still working through
> > it and have not committed to anything. I was looking at the ui tool as
> > an example and did not like how it used a property to configure the tool
> > as it did make my idea difficult to implement. I was trying to get a
> > clean way to implement in place for when I needed it. I will try to
> > keep configuration of the tool out of TR.props and come back again if I
> > find another reason it makes sense. Proposal withdrawn.
>
> You mean setting the skin in the TR.props? Maybe the default can always
> be 'default' and we can get the tool to look for skins in a more
> dynamic fashion.
>
> I guess we still need some more tools to figure out how everything
> will work. In the particular case of the UIManager I don't think
> more instances are needed, but maybe for what you are doing with
> intake it will be.
>
> I didn't mean to shut down the conversation, I think it would be
> a good discussion. How would you be using intake? What would each
> instance of the tool be doing? If your tools require extra configuration
> in TR.props then that's cool. I was just stating my opinion that
> the UIManager could probably get away without it. Things that
> intake would do are probably less ephemeral then look and feel
> issues so maybe the intake tool configuration should be in
> TR.props ...
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@periapt.com
>
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
> http://tambora.zenplex.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [Proposal] modify ApplicationTool interface
Posted by Jason van Zyl <jv...@apache.org>.
John McNally wrote:
>
> The idea is more related torque/intake though I am still working through
> it and have not committed to anything. I was looking at the ui tool as
> an example and did not like how it used a property to configure the tool
> as it did make my idea difficult to implement. I was trying to get a
> clean way to implement in place for when I needed it. I will try to
> keep configuration of the tool out of TR.props and come back again if I
> find another reason it makes sense. Proposal withdrawn.
You mean setting the skin in the TR.props? Maybe the default can always
be 'default' and we can get the tool to look for skins in a more
dynamic fashion.
I guess we still need some more tools to figure out how everything
will work. In the particular case of the UIManager I don't think
more instances are needed, but maybe for what you are doing with
intake it will be.
I didn't mean to shut down the conversation, I think it would be
a good discussion. How would you be using intake? What would each
instance of the tool be doing? If your tools require extra configuration
in TR.props then that's cool. I was just stating my opinion that
the UIManager could probably get away without it. Things that
intake would do are probably less ephemeral then look and feel
issues so maybe the intake tool configuration should be in
TR.props ...
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [Proposal] modify ApplicationTool interface
Posted by John McNally <jm...@collab.net>.
The idea is more related torque/intake though I am still working through
it and have not committed to anything. I was looking at the ui tool as
an example and did not like how it used a property to configure the tool
as it did make my idea difficult to implement. I was trying to get a
clean way to implement in place for when I needed it. I will try to
keep configuration of the tool out of TR.props and come back again if I
find another reason it makes sense. Proposal withdrawn.
Thanks,
John McNally
Jason van Zyl wrote:
>
> John McNally wrote:
> >
> > I would like to modify the ApplicationTool interface so that the init
> > method is
> >
> > void init(String toolName, Object data);
> >
> > It would be useful for tools to know the name given to them in the
> > properties file. They could use this to get other configuration
> > properties. For example right now UIManager is given the handle "ui" in
> > the context and it has a configuration property
> >
> > tool.ui.skin
> >
> > It could be that some tools are useful in more than one configuration,
> > so with the modification to the init method above you could have
>
> I agree that tools could be used with more then one configuration
> but I think the tool should deal with multiple configuration issues.
> I see in the UIManager example that it would great to be able to use
> multiple
> skins, but I think the use of $ui1 and $ui2 isn't the way to go.
>
> Maybe the UI manager could take a skin as a parameter? Possibly
> something
> like:
>
> $ui.flashy.bgcolor
> $ui.sassy.bgcolor
>
> Where "flashy" and "sassy" are skins. What I am thinking about is the
> ability for the UI manager to deal with skins added without stopping
> the server. It currently doesn't deal with this but I think it should be
> possible for the designer to add skins and create new templates without
> having to alter TR.props and restart the server.
>
> I think all the tools should be like this: in that configuration changes
> can be made without altering the TR.props and having to poke the server.
> I think the proposal goes against the Pull Model and MVC.
>
> The UI manager is deficient in this respect right now, but I don't
> think it would take a lot of work to get it to work with skins added
> on the fly. It could try to access a skin, if it's not there it
> could look for it, load it if its there and cache it for later
> use. So new portions of a site could be added using newly
> created skins: the designer is free to do what they want.
>
> >
> > tool.global.ui1=org.apache.turbine.services.pull.util.UIManager
> > tool.global.ui2=org.apache.turbine.services.pull.util.UIManager
>
> I think there should only be a single instance of a pull tool. Do
> you have other thoughts regarding an intake tool that might need
> multiple instances?
>
> >
> > tool.ui1.skin=default
> > tool.ui2.skin=alternate
>
> I think this could be made more dynamic, and maybe using chained
> contexts we could even make something like a subclassed skin where
> you can create a new skin and just override what UI elements you
> want to be different. In the skin.properties something like:
>
> parent = sassy
> bgcolor = #aabbcc
>
> Just change the elements you want. I digress.
>
> > (UIManager might need more properties, if this would actually be useful
> > for this tool, but this is the idea.)
> >
> > I could define a different interface for tools that might be used this
> > way, but the Pull service is fairly new and I wonder if it would just be
> > better to keep the interface decision simple.
>
> Again, I personally don't see the need for multiple instances of a tool,
> but I'm not sure what you have in mind for the intake tool. Maybe I'm
> missing something?
>
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@periapt.com
>
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/turbine
> http://tambora.zenplex.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [Proposal] modify ApplicationTool interface
Posted by Jason van Zyl <jv...@apache.org>.
John McNally wrote:
>
> I would like to modify the ApplicationTool interface so that the init
> method is
>
> void init(String toolName, Object data);
>
> It would be useful for tools to know the name given to them in the
> properties file. They could use this to get other configuration
> properties. For example right now UIManager is given the handle "ui" in
> the context and it has a configuration property
>
> tool.ui.skin
>
> It could be that some tools are useful in more than one configuration,
> so with the modification to the init method above you could have
I agree that tools could be used with more then one configuration
but I think the tool should deal with multiple configuration issues.
I see in the UIManager example that it would great to be able to use
multiple
skins, but I think the use of $ui1 and $ui2 isn't the way to go.
Maybe the UI manager could take a skin as a parameter? Possibly
something
like:
$ui.flashy.bgcolor
$ui.sassy.bgcolor
Where "flashy" and "sassy" are skins. What I am thinking about is the
ability for the UI manager to deal with skins added without stopping
the server. It currently doesn't deal with this but I think it should be
possible for the designer to add skins and create new templates without
having to alter TR.props and restart the server.
I think all the tools should be like this: in that configuration changes
can be made without altering the TR.props and having to poke the server.
I think the proposal goes against the Pull Model and MVC.
The UI manager is deficient in this respect right now, but I don't
think it would take a lot of work to get it to work with skins added
on the fly. It could try to access a skin, if it's not there it
could look for it, load it if its there and cache it for later
use. So new portions of a site could be added using newly
created skins: the designer is free to do what they want.
>
> tool.global.ui1=org.apache.turbine.services.pull.util.UIManager
> tool.global.ui2=org.apache.turbine.services.pull.util.UIManager
I think there should only be a single instance of a pull tool. Do
you have other thoughts regarding an intake tool that might need
multiple instances?
>
> tool.ui1.skin=default
> tool.ui2.skin=alternate
I think this could be made more dynamic, and maybe using chained
contexts we could even make something like a subclassed skin where
you can create a new skin and just override what UI elements you
want to be different. In the skin.properties something like:
parent = sassy
bgcolor = #aabbcc
Just change the elements you want. I digress.
> (UIManager might need more properties, if this would actually be useful
> for this tool, but this is the idea.)
>
> I could define a different interface for tools that might be used this
> way, but the Pull service is fairly new and I wonder if it would just be
> better to keep the interface decision simple.
Again, I personally don't see the need for multiple instances of a tool,
but I'm not sure what you have in mind for the intake tool. Maybe I'm
missing something?
--
jvz.
Jason van Zyl
jvanzyl@periapt.com
http://jakarta.apache.org/velocity
http://jakarta.apache.org/turbine
http://tambora.zenplex.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org