>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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
