You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Dan Bachelder <ch...@chowda.net> on 2001/09/15 20:50:05 UTC
Re: getting a handle on the velocity engine... solution?
In order to make server info available to the scheduled job, I did the
following in my Index screen...
TurbineServices ts = (TurbineServices)TurbineServices.getInstance();
TurbineServletService servlet =
(TurbineServletService)ts.getService("ServletService");
servlet.init(data);
so as long as this page is accessed before the job runs everything is
fine...
does this mean the servletService does not get initialized unless you do it
manually?
This is unlike other services?
----- Original Message -----
From: "Dan Bachelder" <ch...@chowda.net>
To: <tu...@jakarta.apache.org>
Sent: Friday, September 14, 2001 1:30 PM
Subject: Re: getting a handle on the velocity engine...
> > I'm not saying that isn't the case. You can get a handle on the service
> > using the static helper or retrieving the instance of the service
directly
> > from the ServiceBroker and any information you need regarding the server
> > setup is available via the servlet service.
>
> am I doing something wrong here?
>
> TurbineServices ts = (TurbineServices)TurbineServices.getInstance();
>
> System.out.println("servelt service is registered: "
> + ts.isRegistered("ServletService")); // "is registered: true"
> TurbineServletService servlet =
> (TurbineServletService)ts.getService("ServletService");
> System.out.println("getservername: "
> + servlet.getServerName()); // "getservername: null"
> System.out.println("getserverport: "
> + servlet.getServerPort()); // "getserverport: null"
> System.out.println("getserverscheme: "
> + servlet.getServerScheme()); // "getserverscheme: null"
> System.out.println("getcontextpath: "
> + servlet.getContextPath()); // "getcontextpath: null"
>
> System.out.println("schedulerservice is registered: "
> + ts.isRegistered("SchedulerService")); // "is registered: true"
> TurbineSchedulerService ss =
> (TurbineSchedulerService)ts.getService("SchedulerService");
> System.out.println("number of jobs: "
> + ss.listJobs().size()); // "number of jobs: 1" --correct
>
> so the servlet service isn't behaving as I would expect... but
TurbineServices is... and so is SchedulerService.. am I missing something?
Is there a better way to get the Server info?
>
>
> </dan>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Dan Bachelder <ch...@chowda.net>.
> > (1) //TurbineServices ts =
(TurbineServices)TurbineServices.getInstance();
> > (2) //TurbineServletService servlet =
> > (TurbineServletService)ts.getService("ServletService");
> > (3) //servlet.init(data);
>
> So just to get this straight, using (1),(2), and (3) everything works
fine?
Yes, you are correct, sir.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Dan Bachelder <ch...@chowda.net>.
>Screens are associated with request level processing, I myself would never
>of thought to "render a screen in a scheduled job". The servlet service was
>originally made for use with scheduled jobs, or for processes that require
>server information but do not have access to RunData. I consider scheduled
>jobs and request level rendering to be separate things so I didn't even
>consider using your approach. ServerData was also never meant to be a class
>for public use, it probably should have had package scope to keep it from
>being used. As I said this class doesn't exist in Turbine 3.0 so your
>approach will not work there.
Good points... It never occured to me to treat non-request based pages
different from the request ones... I guess I will simply develop a context
tool to use with my email generator and my static page generator
scheduled jobs... It makes it a bit difficult to reuse templates in these
situations but what you're saying certainly makes sence...
>You are trying to use the request level methodology in a scheduled job
which
>does not require any request level information. The idea of the pull model
>is for request level processing. Now there could be a separate notion of a
Yeah... context tool it the way to go...
>You obviously have a different need so maybe we could give template link a
>new constructor as all it really does is append server information together
>so that it can spit out a string that looks like an URL. Actually this
might
>be the case in Turbine 3.0, I can't remember what I did once I removed
>ServerData.
there is no need to change anything for me... The code you sent a couple
emails back will certainly sufice.. I will slap together a quick context
tool
from it.. Now that I understand the fundementals I was missing, it seems
silly to continue down the path I was on...
>Or maybe we could add a method to Turbine.java to return a functioning
>template link: Turbine.getTemplateLink() or something that produced classes
>that need server info. Turbine will be the façade for all things Turbine
and
>there is obviously a need for the server info outside the request level
>processing. That's why I added the methods to Turbine.java in 3.0 because I
>figured that would be the easiest place to get the info from.
A context tool will handle this just fine... there is no need to muddle the
Turbine.java to support what was a bad approach in the first place.
>To make a long story short if I were to require server information in a
>process outside of normal request level processing than I would either get
>that information from the servlet service in 2.x (or you can get it
directly
>from Turbine.java if you want to change you're code) or use the public
>methods in Turbine.java in 3.0 to get the server information.
I've already changed my code to use the new methods.. It is working well.
Is there a way to populate this server information before the first request
comes in?
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Jason van Zyl <jv...@apache.org>.
On 9/16/01 11:21 AM, "Dan Bachelder" <ch...@chowda.net> wrote:
>> Do not use ServerData you don't need it and it doesn't exist in Turbine
> 3.0.
>> With the information you can now get the servlet service you don't need to
>> make a template link. You're actually just going around in a circle there
>> making a ServerData object because the template link just pulls out the
> info
>> you just fed into the ServerData constructor. When the getContextPath()
>> method is fixed to return the proper information you can just construct
> the
>> correct URL yourself.
>
> All my screens use $link so when I want to render a screen in my scheduled
> jobs, I need to instantiate TemplateLink and add it to the context...
Screens are associated with request level processing, I myself would never
of thought to "render a screen in a scheduled job". The servlet service was
originally made for use with scheduled jobs, or for processes that require
server information but do not have access to RunData. I consider scheduled
jobs and request level rendering to be separate things so I didn't even
consider using your approach. ServerData was also never meant to be a class
for public use, it probably should have had package scope to keep it from
being used. As I said this class doesn't exist in Turbine 3.0 so your
approach will not work there.
> I
> could go ahead and write my own $link type pull tool to use the new static
> methods on Turbine.. but I don't understand why placing this info in a
> ServerData and passing that to TemplateLink is bad...
You are trying to use the request level methodology in a scheduled job which
does not require any request level information. The idea of the pull model
is for request level processing. Now there could be a separate notion of a
general toolbox of tools for general processing in velocity but this wasn't
what the pull model was trying to address in the first place. But like I
said the idea could be expanded on or adapted to accommodate long lived text
processing with velocity or other templating solutions.
> it has to get that
> info from someplace, and right now it is set up to get it from a RunData or
> a ServerData.. it seems easier to create a ServerData in a scheduled job
> than a RunData...
As I've said I think the problem lies in mixing classes that were designed
for request level processing and classes that were not. Your eventually
going to run into problems, you certainly will in Turbine 3.0.
>>
>> What you're doing here is a prime example of what happens when there is a
>> lack of information and no API. I've never seen anyone do this before, not
>> to say that it's wrong but I certainly would never expect usage like this.
>> In short it shouldn't be necessary when you can properly retrieve all the
>> info from the servlet service.
>
> I guess I'm missing what I am doing that is so odd... could you elaborate?
The mixing of notions: request level processing versus a process that simply
requires some server information. I would state it as simply as that.
>> You you be able to construct the URL in the following manner
>>
>> String url = new StringBuffer().
>> append(TurbineServlet.getServerScheme()).
>> append("://").
>> append(TurbineServlet.getServerName()).
>> append(":").
>> append(TurbineServlet.getServerPort()).
>> append(TurbineServlet.getContextPath()).
>> append(pathToYourResource).
>> toString();
>
> I sure could.. but isn't that what TemplateLink is supposed to do?
Not in a scheduled job. Template link has always been a tool that has been
placed in a template context for use in request level processing.
You obviously have a different need so maybe we could give template link a
new constructor as all it really does is append server information together
so that it can spit out a string that looks like an URL. Actually this might
be the case in Turbine 3.0, I can't remember what I did once I removed
ServerData.
Or maybe we could add a method to Turbine.java to return a functioning
template link: Turbine.getTemplateLink() or something that produced classes
that need server info. Turbine will be the façade for all things Turbine and
there is obviously a need for the server info outside the request level
processing. That's why I added the methods to Turbine.java in 3.0 because I
figured that would be the easiest place to get the info from.
> I am not
> opposed to rewriting the $link tool to do this in a different way, but why
> is it in there if it is wrong?
It's not wrong, I just don't recommend it. The pattern you're using is
something I've never seen before which isn't good because you're using a
class that I believe was never intended for general use. This is a general
problem in 2.x IMO. There are far too many ways to dig in at a low level
which basically makes it impossible for us to know how people are using the
system which makes it almost impossible for Turbine to evolve without
breaking everyone's code.
I am all for having myriad ways to accomplish any task but we should know at
what level people are plugging in their solutions. Hopefully with the API in
Turbine 3.0 that people will be able to do whatever they need but we will
know where the extensions are happening.
To make a long story short if I were to require server information in a
process outside of normal request level processing than I would either get
that information from the servlet service in 2.x (or you can get it directly
from Turbine.java if you want to change you're code) or use the public
methods in Turbine.java in 3.0 to get the server information.
>
> thanks for your help!!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Dan Bachelder <ch...@chowda.net>.
> Do not use ServerData you don't need it and it doesn't exist in Turbine
3.0.
> With the information you can now get the servlet service you don't need to
> make a template link. You're actually just going around in a circle there
> making a ServerData object because the template link just pulls out the
info
> you just fed into the ServerData constructor. When the getContextPath()
> method is fixed to return the proper information you can just construct
the
> correct URL yourself.
All my screens use $link so when I want to render a screen in my scheduled
jobs, I need to instantiate TemplateLink and add it to the context... I
could go ahead and write my own $link type pull tool to use the new static
methods on Turbine.. but I don't understand why placing this info in a
ServerData and passing that to TemplateLink is bad... it has to get that
info from someplace, and right now it is set up to get it from a RunData or
a ServerData.. it seems easier to create a ServerData in a scheduled job
than a RunData...
>
> What you're doing here is a prime example of what happens when there is a
> lack of information and no API. I've never seen anyone do this before, not
> to say that it's wrong but I certainly would never expect usage like this.
> In short it shouldn't be necessary when you can properly retrieve all the
> info from the servlet service.
I guess I'm missing what I am doing that is so odd... could you elaborate?
> You you be able to construct the URL in the following manner
>
> String url = new StringBuffer().
> append(TurbineServlet.getServerScheme()).
> append("://").
> append(TurbineServlet.getServerName()).
> append(":").
> append(TurbineServlet.getServerPort()).
> append(TurbineServlet.getContextPath()).
> append(pathToYourResource).
> toString();
I sure could.. but isn't that what TemplateLink is supposed to do? I am not
opposed to rewriting the $link tool to do this in a different way, but why
is it in there if it is wrong?
thanks for your help!!
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: $ui.image() thing... again
Posted by Dan Bachelder <ch...@chowda.net>.
great, thanks for the help... sorry I didn't see the other method myself...
duh...
----- Original Message -----
From: "Jason van Zyl" <jv...@apache.org>
To: <tu...@jakarta.apache.org>
Sent: Saturday, September 29, 2001 6:20 PM
Subject: Re: $ui.image() thing... again
> On 9/29/01 6:17 PM, "Dan Bachelder" <ch...@chowda.net> wrote:
>
> >> Are you using CVS code? I think it's busted in there.
> >>
> >> In tambora we use $ui.image($ui.logo, $data) which is probably why
> >> I never noticed the problem.
> >
> > yes... i am using CVS... and yes image(String, RunData) works like I
would
> > expect...
>
> I will fix the image(String id) goof later tonight.
>
> > cool, thanks
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: $ui.image() thing... again
Posted by Jason van Zyl <jv...@apache.org>.
On 10/1/01 9:49 AM, "Age Mooy" <am...@home.nl> wrote:
>
> I just started experimenting with the UIManager tool and I have the same
> problem with stylesheets
>
> Using $ui.getStylecss()
>
> http://localhost:9000E:\wdk-dev\webapps\contentment//resources/ui/skins/defaul
> t/skin.css
>
> , using $ui.getStylecss($data)
>
> http://localhost:9000/contentment/resources/ui/skins/default/skin.css
>
> I also use the CVS version of UIManager but I checked and it's identical to
> the tdk-2.1 version.
>
> It is clearly the TurbineServlet.getContextPath() part of the URL construction
> that goes wrong but that leads
> to the init methods of Turbine.java and I can't find the exact cause there :(
I know where it is, I didn't get around to it this weekend as I'm in the
middle of making an end-user installer with the TDK. I'll fix that problem
as soon as I'm done the installer.
> Age
>
>
>> -----Original Message-----
>> From: Jason van Zyl [mailto:jvanzyl@apache.org]
>> Sent: Sunday, September 30, 2001 00:20
>> To: turbine-user@jakarta.apache.org
>> Subject: Re: $ui.image() thing... again
>>
>>
>> On 9/29/01 6:17 PM, "Dan Bachelder" <ch...@chowda.net> wrote:
>>
>>>> Are you using CVS code? I think it's busted in there.
>>>>
>>>> In tambora we use $ui.image($ui.logo, $data) which is probably why
>>>> I never noticed the problem.
>>>
>>> yes... i am using CVS... and yes image(String, RunData) works like I would
>>> expect...
>>
>> I will fix the image(String id) goof later tonight.
>>
>>> cool, thanks
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>>
>> --
>>
>> jvz.
>>
>> Jason van Zyl
>>
>> http://tambora.zenplex.org
>> http://jakarta.apache.org/turbine
>> http://jakarta.apache.org/velocity
>> http://jakarta.apache.org/alexandria
>> http://jakarta.apache.org/commons
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: $ui.image() thing... again
Posted by Age Mooy <am...@home.nl>.
I just started experimenting with the UIManager tool and I have the same problem with stylesheets
Using $ui.getStylecss()
http://localhost:9000E:\wdk-dev\webapps\contentment//resources/ui/skins/default/skin.css
, using $ui.getStylecss($data)
http://localhost:9000/contentment/resources/ui/skins/default/skin.css
I also use the CVS version of UIManager but I checked and it's identical to the tdk-2.1 version.
It is clearly the TurbineServlet.getContextPath() part of the URL construction that goes wrong but that leads
to the init methods of Turbine.java and I can't find the exact cause there :(
Age
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@apache.org]
> Sent: Sunday, September 30, 2001 00:20
> To: turbine-user@jakarta.apache.org
> Subject: Re: $ui.image() thing... again
>
>
> On 9/29/01 6:17 PM, "Dan Bachelder" <ch...@chowda.net> wrote:
>
> >> Are you using CVS code? I think it's busted in there.
> >>
> >> In tambora we use $ui.image($ui.logo, $data) which is probably why
> >> I never noticed the problem.
> >
> > yes... i am using CVS... and yes image(String, RunData) works like I would
> > expect...
>
> I will fix the image(String id) goof later tonight.
>
> > cool, thanks
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
> --
>
> jvz.
>
> Jason van Zyl
>
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: $ui.image() thing... again
Posted by Jason van Zyl <jv...@apache.org>.
On 9/29/01 6:17 PM, "Dan Bachelder" <ch...@chowda.net> wrote:
>> Are you using CVS code? I think it's busted in there.
>>
>> In tambora we use $ui.image($ui.logo, $data) which is probably why
>> I never noticed the problem.
>
> yes... i am using CVS... and yes image(String, RunData) works like I would
> expect...
I will fix the image(String id) goof later tonight.
> cool, thanks
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: $ui.image() thing... again
Posted by Dan Bachelder <ch...@chowda.net>.
> Are you using CVS code? I think it's busted in there.
>
> In tambora we use $ui.image($ui.logo, $data) which is probably why
> I never noticed the problem.
yes... i am using CVS... and yes image(String, RunData) works like I would
expect...
cool, thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: $ui.image() thing... again
Posted by Jason van Zyl <jv...@apache.org>.
On 9/29/01 6:05 PM, "Dan Bachelder" <ch...@chowda.net> wrote:
>>>
> http://127.0.0.1:80C:\dev\tdk\webapps\law//resources/ui/skins/default/images
>>> /yo
>>>>
>>>> Oops, that's my fault I'll fix that I used the application root instead
> of
>>>> the context path there.
>>>
>>> It looks like contextpath is being used now...
>>
>> What do you mean being used now? It has always been used.
>
> Oh... that is not what i inferred from the "oops" line above...
>
>>> but what is needed is
>>> scriptname...
>>
>> No the script name is not what's needed.
>
> right... i need the webapp name (is that the context path?)... sorry..
>
>> if id = logo.gif in your skin.props file than
>>
>> $image.id
>>
>> Should render to:
>>
>> http://host:port/<contextpath>/resources/ui/skins/default/images/logo.gif
>
> $ui.image("$ui.id")
>
> renders to
>
> http://127.0.0.1:80C:\dev\tdk\webapps\law//resources/ui/skins/default/images
> /logo.gif
>
>> I think the getContextPath() is pulling up the getScriptName(). I
> mentioned
>> this the last time you asked and I said I would fix it but I forgot. I'll
>> take a look at it now.
>
> okay... i assume this will fix the above... I made a change in my UIManager
> to fix it for now...
> why hasn't this broken anyone elses code i wonder? am i not using this
> correctly?
Are you using CVS code? I think it's busted in there.
In tambora we use $ui.image($ui.logo, $data) which is probably why
I never noticed the problem.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: $ui.image() thing... again
Posted by Dan Bachelder <ch...@chowda.net>.
> >
http://127.0.0.1:80C:\dev\tdk\webapps\law//resources/ui/skins/default/images
> > /yo
> >>
> >> Oops, that's my fault I'll fix that I used the application root instead
of
> >> the context path there.
> >
> > It looks like contextpath is being used now...
>
> What do you mean being used now? It has always been used.
Oh... that is not what i inferred from the "oops" line above...
> > but what is needed is
> > scriptname...
>
> No the script name is not what's needed.
right... i need the webapp name (is that the context path?)... sorry..
> if id = logo.gif in your skin.props file than
>
> $image.id
>
> Should render to:
>
> http://host:port/<contextpath>/resources/ui/skins/default/images/logo.gif
$ui.image("$ui.id")
renders to
http://127.0.0.1:80C:\dev\tdk\webapps\law//resources/ui/skins/default/images
/logo.gif
> I think the getContextPath() is pulling up the getScriptName(). I
mentioned
> this the last time you asked and I said I would fix it but I forgot. I'll
> take a look at it now.
okay... i assume this will fix the above... I made a change in my UIManager
to fix it for now...
why hasn't this broken anyone elses code i wonder? am i not using this
correctly?
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: $ui.image() thing... again
Posted by Jason van Zyl <jv...@apache.org>.
On 9/29/01 5:23 PM, "Dan Bachelder" <ch...@chowda.net> wrote:
>>> It looks good so far... some slight issues perhaps... in my Index.vm
>>>
>>> $ui.image("yo")
>>>
>>> renders to
>>>
>>>
> http://127.0.0.1:80C:\dev\tdk\webapps\law//resources/ui/skins/default/images
> /yo
>>
>> Oops, that's my fault I'll fix that I used the application root instead of
>> the context path there.
>
> It looks like contextpath is being used now...
What do you mean being used now? It has always been used.
> but what is needed is
> scriptname...
No the script name is not what's needed.
> unless I am just plain using this wrong... where can I get
> that from in UIManager? it is not on TurbineServlet in CVS... Are people
> using $ui.image?
if id = logo.gif in your skin.props file than
$image.id
Should render to:
http://host:port/<contextpath>/resources/ui/skins/default/images/logo.gif
I think the getContextPath() is pulling up the getScriptName(). I mentioned
this the last time you asked and I said I would fix it but I forgot. I'll
take a look at it now.
> public String image(String imageId)
> {
> StringBuffer sb = new StringBuffer();
>
> sb.append(TurbineServlet.getServerScheme()).
> append("://").
> append(TurbineServlet.getServerName()).
> append(":").
> append(TurbineServlet.getServerPort()).
> append(TurbineServlet.getContextPath()).
> append("/").
> append(resourcesDirectory).
> append(SKINS_DIRECTORY).
> append("/").
> append(getSkin()).
> append(IMAGES_DIRECTORY).
> append("/").
> append(imageId);
>
> return sb.toString();
> }
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
$ui.image() thing... again
Posted by Dan Bachelder <ch...@chowda.net>.
> > It looks good so far... some slight issues perhaps... in my Index.vm
> >
> > $ui.image("yo")
> >
> > renders to
> >
> >
http://127.0.0.1:80C:\dev\tdk\webapps\law//resources/ui/skins/default/images
/yo
>
> Oops, that's my fault I'll fix that I used the application root instead of
> the context path there.
It looks like contextpath is being used now... but what is needed is
scriptname... unless I am just plain using this wrong... where can I get
that from in UIManager? it is not on TurbineServlet in CVS... Are people
using $ui.image?
public String image(String imageId)
{
StringBuffer sb = new StringBuffer();
sb.append(TurbineServlet.getServerScheme()).
append("://").
append(TurbineServlet.getServerName()).
append(":").
append(TurbineServlet.getServerPort()).
append(TurbineServlet.getContextPath()).
append("/").
append(resourcesDirectory).
append(SKINS_DIRECTORY).
append("/").
append(getSkin()).
append(IMAGES_DIRECTORY).
append("/").
append(imageId);
return sb.toString();
}
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Jason van Zyl <jv...@apache.org>.
On 9/16/01 10:50 AM, "Dan Bachelder" <ch...@chowda.net> wrote:
>> Done. I have changed the Turbine.java and the servlet service so that the
>> server information is collected during the first request in Turbine.java
> and
>> the ServletService will delegate requests for the server info the
>> Turbine.java.
>
> It looks good so far... some slight issues perhaps... in my Index.vm
>
> $ui.image("yo")
>
> renders to
>
> http://127.0.0.1:80C:\dev\tdk\webapps\law//resources/ui/skins/default/images
> /yo
Oops, that's my fault I'll fix that I used the application root instead of
the context path there.
> which looks a bit funny.... I dont really use images, so this doesn't really
> matter to me.
What's above isn't right.
> anyway... it looks like the server data is populated on the first request...
> thanks!
>
> more on scheduled jobs below....
>
>> I've updated the ServletService screen and template in the sample/test app
>> and the values appear to be showing up correctly. I don't have a scheduled
>> job on hand to easily test this so if you could try what's in CVS with
> your
>> scenerio that was giving you problems I'd appreciate it.
>
> after making the initial request my scheduled jobs work as follows...
>
> I have to instantiate TemplateLink with the following serverdata for it to
> work...
> are you supposed to have to hand in so much for a script name?
Do not use ServerData you don't need it and it doesn't exist in Turbine 3.0.
With the information you can now get the servlet service you don't need to
make a template link. You're actually just going around in a circle there
making a ServerData object because the template link just pulls out the info
you just fed into the ServerData constructor. When the getContextPath()
method is fixed to return the proper information you can just construct the
correct URL yourself.
What you're doing here is a prime example of what happens when there is a
lack of information and no API. I've never seen anyone do this before, not
to say that it's wrong but I certainly would never expect usage like this.
In short it shouldn't be necessary when you can properly retrieve all the
info from the servlet service.
I will add another example to tdk servlet service example and construct an
URL the way I suggest above to make sure it works and I'll let you know.
> ServerData sd = new ServerData(Turbine.getServerName(),
> Integer.parseInt(Turbine.getServerPort()),
> Turbine.getServerScheme(),
> "/law/servlet/law",
> Turbine.getContextPath());
>
> which gives me a link like the following... note the lack of port...
>
> http://127.0.0.1/law/servlet/law/template/NewReminder.vm
>
> this is much better than before... thanks...
You you be able to construct the URL in the following manner
String url = new StringBuffer().
append(TurbineServlet.getServerScheme()).
append("://").
append(TurbineServlet.getServerName()).
append(":").
append(TurbineServlet.getServerPort()).
append(TurbineServlet.getContextPath()).
append(pathToYourResource).
toString();
Something close to that anyway.
> Now I also know how to use jakartas cvs and how to build turbine and place
> the new build in my tdk so everything works! way cool... thanks for that too
> :)
>
I'll get the context path fix in later on today. I'll post something when
it's in there sorry for the first round glitch.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Dan Bachelder <ch...@chowda.net>.
> Done. I have changed the Turbine.java and the servlet service so that the
> server information is collected during the first request in Turbine.java
and
> the ServletService will delegate requests for the server info the
> Turbine.java.
It looks good so far... some slight issues perhaps... in my Index.vm
$ui.image("yo")
renders to
http://127.0.0.1:80C:\dev\tdk\webapps\law//resources/ui/skins/default/images
/yo
which looks a bit funny.... I dont really use images, so this doesn't really
matter to me.
anyway... it looks like the server data is populated on the first request...
thanks!
more on scheduled jobs below....
> I've updated the ServletService screen and template in the sample/test app
> and the values appear to be showing up correctly. I don't have a scheduled
> job on hand to easily test this so if you could try what's in CVS with
your
> scenerio that was giving you problems I'd appreciate it.
after making the initial request my scheduled jobs work as follows...
I have to instantiate TemplateLink with the following serverdata for it to
work...
are you supposed to have to hand in so much for a script name?
ServerData sd = new ServerData(Turbine.getServerName(),
Integer.parseInt(Turbine.getServerPort()),
Turbine.getServerScheme(),
"/law/servlet/law",
Turbine.getContextPath());
which gives me a link like the following... note the lack of port...
http://127.0.0.1/law/servlet/law/template/NewReminder.vm
this is much better than before... thanks...
Now I also know how to use jakartas cvs and how to build turbine and place
the new build in my tdk so everything works! way cool... thanks for that too
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Jason van Zyl <jv...@apache.org>.
On 9/15/01 11:24 PM, "Jason van Zyl" <jv...@apache.org> wrote:
> On 9/15/01 11:19 PM, "Jason van Zyl" <jv...@apache.org> wrote:
>
>>
>> Actually I do something simpler to fix the servlet service. I'll just
>> collect the information from the ServletConfig object during the
>> init(ServletConfig) and that should fix things. I'll change the code now and
>> you can try it in a few minutes.
>
> Ignore that. I need the request info, was a little fast with the response. I
> make the fix now storing the server info in Turbine.java. I'll let you know
> when I'm done.
Done. I have changed the Turbine.java and the servlet service so that the
server information is collected during the first request in Turbine.java and
the ServletService will delegate requests for the server info the
Turbine.java.
I've updated the ServletService screen and template in the sample/test app
and the values appear to be showing up correctly. I don't have a scheduled
job on hand to easily test this so if you could try what's in CVS with your
scenerio that was giving you problems I'd appreciate it.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Jason van Zyl <jv...@apache.org>.
On 9/15/01 11:19 PM, "Jason van Zyl" <jv...@apache.org> wrote:
>
> Actually I do something simpler to fix the servlet service. I'll just
> collect the information from the ServletConfig object during the
> init(ServletConfig) and that should fix things. I'll change the code now and
> you can try it in a few minutes.
Ignore that. I need the request info, was a little fast with the response. I
make the fix now storing the server info in Turbine.java. I'll let you know
when I'm done.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Jason van Zyl <jv...@apache.org>.
Actually I do something simpler to fix the servlet service. I'll just
collect the information from the ServletConfig object during the
init(ServletConfig) and that should fix things. I'll change the code now and
you can try it in a few minutes.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Jason van Zyl <jv...@apache.org>.
On 9/15/01 7:21 PM, "Dan Bachelder" <ch...@chowda.net> wrote:
> okay... I see the service getting initialized early in my console...
>
> in my Index.java I have the following code... all 4 sout statements are null
> until I uncomment these first 3 lines...
>
> (1) //TurbineServices ts = (TurbineServices)TurbineServices.getInstance();
> (2) //TurbineServletService servlet =
> (TurbineServletService)ts.getService("ServletService");
> (3) //servlet.init(data);
So just to get this straight, using (1),(2), and (3) everything works fine?
> System.out.println("NAME: " + TurbineServlet.getServerName());
> System.out.println("PORT: " + TurbineServlet.getServerPort());
> System.out.println("SCHEME: " + TurbineServlet.getServerScheme());
> System.out.println("CONTEXT: " + TurbineServlet.getContextPath());
>
> Once this is executed (including those first 3 lines) my scheduled job runs
> with those same sout lines outputing the right stuff....
>
> also.. if i do..
>
> $ui.image("yo")
>
> in my Index.vm
>
> I see
>
> null://null:nullnull//resources/ui/skins/default/images/yo
>
> rendered...
>
> UNLESS.. I uncomment those first 3 lines again... so it seems like
> servletservice is not getting initialized when turbine starts up...
It gets initialized but the service has two init methods, and if I remember
there is a general problem with init(RunData) which is why the whole service
framework was completely overhauled in 3.0.
> maybe
> because at startup there is no rundata to use for the initialization...
The rundata object is there for use but I don't believe the init(RunData)
method is being called.
> I
> have started digging around in the source code that deals with all this, but
> there is quite a bit there, so it will be a while before I understand it
> enough to comment with any kind of authority...
I'll run a couple more tests and I think in a few minutes I can backport
what is being done in 3.0 to get the the server info. We'll gather it in the
servlet itself like we're doing in 3.0 and than the servlet service can just
delegate the calls to Turbine.java as is happening in 3.0. This can be done
relatively quickly and I know this works. I'll take a look at this tomorrow
as this is something that a lot of people have complained about.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Dan Bachelder <ch...@chowda.net>.
> There is a static helper, you shouldn't be using that code above. You
should
> be using things like:
>
> TurbineServlet.getServerName()
> TurbineServlet.getServerScheme()
> TurbineServlet.getServerPort()
>
Ha.. missed those... they basically do what I was doing... but I switched
over to using these helpers... same results... a bit more detail below...
> The servlet service in 2.x should be initialized automatically when the
> servlet starts. Like I've said before, if these values appear to be null
> than something is wrong with the service. I only use the servlet service
in
> the UI manager in the sample app and there are no unit tests so I can't
say
> for certainty that it works in all cases.
okay... I see the service getting initialized early in my console...
in my Index.java I have the following code... all 4 sout statements are null
until I uncomment
these first 3 lines...
//TurbineServices ts = (TurbineServices)TurbineServices.getInstance();
//TurbineServletService servlet =
(TurbineServletService)ts.getService("ServletService");
//servlet.init(data);
System.out.println("NAME: " + TurbineServlet.getServerName());
System.out.println("PORT: " + TurbineServlet.getServerPort());
System.out.println("SCHEME: " + TurbineServlet.getServerScheme());
System.out.println("CONTEXT: " + TurbineServlet.getContextPath());
Once this is executed (including those first 3 lines) my scheduled job runs
with those same sout lines outputing the right stuff....
also.. if i do..
$ui.image("yo")
in my Index.vm
I see
null://null:nullnull//resources/ui/skins/default/images/yo
rendered...
UNLESS.. I uncomment those first 3 lines again... so it seems like
servletservice is not getting initialized when turbine starts up... maybe
because at startup there is no rundata to use for the initialization... I
have started digging around in the source code that deals with all this, but
there is quite a bit there, so it will be a while before I understand it
enough to comment with any kind of authority...
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: getting a handle on the velocity engine... solution?
Posted by Jason van Zyl <jv...@apache.org>.
On 9/15/01 2:50 PM, "Dan Bachelder" <ch...@chowda.net> wrote:
> In order to make server info available to the scheduled job, I did the
> following in my Index screen...
>
> TurbineServices ts = (TurbineServices)TurbineServices.getInstance();
> TurbineServletService servlet =
> (TurbineServletService)ts.getService("ServletService");
> servlet.init(data);
There is a static helper, you shouldn't be using that code above. You should
be using things like:
TurbineServlet.getServerName()
TurbineServlet.getServerScheme()
TurbineServlet.getServerPort()
>
> so as long as this page is accessed before the job runs everything is
> fine...
> does this mean the servletService does not get initialized unless you do it
> manually?
The servlet service in 2.x should be initialized automatically when the
servlet starts. Like I've said before, if these values appear to be null
than something is wrong with the service. I only use the servlet service in
the UI manager in the sample app and there are no unit tests so I can't say
for certainty that it works in all cases.
> This is unlike other services?
>
It is not unlike the other services. In turbine 2.x a service is either
initialized early by using the init(ServletConfig) method or it is lazily
initialized. The servlet service uses the former and is started early so in
theory it should be available for your scheduled jobs.
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org