On 9/16/01 11:21 AM, "Dan Bachelder" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
