I also found a HttpServletRequestFilter.
Thanks for the response, it helps to explain a lot.
I am finding my biggest problem is the documentation. I have OReilley
safari access, and the Tapestry 5 book there leaves out about half
features. What is needed is a tapestry cookbook/recipe style thing.
How to make a service, How to make a filter.
One final question. In the document examples on service building,
sometimes the build method is called build, othertimes buildFoo where
foo is the service being built. Which is correct, or does it matter?
-Daniel
On Thu, Apr 9, 2009 at 7:10 PM, Robert Zeigler <robe...@scazdl.org> wrote:
> Autobuilder vs. builder vs. constructor:
>
> Depends on your needs. These aren't mutually exclusive, either.
>
> a) Tapestry's ioc container will attempt to use an "ObjectLocator" to fill
> in the arguments to the constructor; one such object provider is a service
> injection provider.
> So, though it used to be that you /had/ to specify @InjectService on
> constructor arguments, it's not so anymore. There are cases where using
> @InjectService with a specific service id is still useful (to avoid
> dependency recursion issues, for example). But often, you can just put the
> service interface in and have it "work".
>
> b) Builder: a builder method is useful when you're constructing certain
> types of services. For example, pipelines. You might use tapestry's
> pipeline builder service to build your pipeline for you, so you don't have
> an actual "PipelineXImpl" class lying around; instead, you use a builder
> method to construct the service "on the fly".
>
> c) Autobuilding - the ability to "autobuild" objects is very nice.
> Typically, I use this when the object I'm building is /not/ a "standalone
> service" that I'm going to reference from somewhere else (not something that
> will directly injected or contributed to). In that sense, the
> CayenneRequestFilter could have been autobuilt, since I could have done a
> "contributeRequestHandler(OrderedConfiguration<RequestFilter> conf,
> @Autobuild CayenneRequestHandler handler) {...}
>
> I don't need to inject CayenneRequestHandler anywhere else, so there's no
> real need to define it as a separate service. But @Autobuild didn't exist
> when I wrote the module. ;)
> If I were to write it today (or refactor it today), I would probably use
> @Autobuild for that one. Keep in mind that @Autobuild is going to use the
> constructor parameters to determine what to inject*. :)
>
> Regarding HttpServletRequest, if you need it directly, you can inject it, as
> tapestry provides a thread-based proxy around it. Something like:
>
> public MyRequestFilter implements RequestFilter {
>
> private final HttpServletRequest servletRequest;
>
> public MyRequestFilter(HttpServletRequest request) {
> servletRequest = request;
> }
>
> public boolean service(Request request, Response response,
> RequestHandler handler)
> {
> //do stuff with the servlet request.
> return handler.service(request,response);
> }
> }
>
> Robert
>
> * Recently, field-based injection support was added for services, so this
> isn't strictly true anymore. But I still prefer constructor injection for
> services.
>
> On Apr 9, 2009, at 4/95:54 PM , daniel joyce wrote:
>
>> How/where do I inject it? It's not obvious from the docs on when/how I
>> should user autobuilder vs builder vs constructor.
>>
>> The docs say you need to inject services explicitely inside the
>> constructor, yet the CayenneRequestFilter has a constructor w/o Inject
>> annotations.
>>
>> Also, the Tapestry 5 Request object supposedly wraps the
>> HttpServletRequest ( where remote user is set ), but provides no way
>> to get the raw request, from which I can grab RemoteUser which tells
>> me which user tomcat logged in.
>>
>> -Daniel
>>
>> On Thu, Apr 9, 2009 at 1:57 PM, daniel joyce <daniel.a.jo...@gmail.com>
>> wrote:
>>>
>>> Awesome, Thanks!
>>>
>>> So far, the nice thing about Tapestry has been its very fluid
>>> component based nature. I am so used to having to do things in a
>>> certain order with other frameworks. Here, things are very orthogonal,
>>> and my reasoning about how to use Tapestry keeps improving.
>>>
>>> -Daniel
>>>
>>> On Thu, Apr 9, 2009 at 12:51 PM, Robert Zeigler <robe...@scazdl.org>
>>> wrote:
>>>>
>>>> Here's a sample request filter that plays with application state objects
>>>> (which are backed by the http session):
>>>>
>>>> http://code.google.com/p/tapestry5-cayenne/source/browse/trunk/tapestry5-cayenne-core/src/main/java/com/googlecode/tapestry5cayenne/services/CayenneRequestFilter.java
>>>>
>>>> You can also use the tapestry-provided Request object (which wraps
>>>> HttpServletRequest), which provides access to the wrapper "Session"
>>>> object.
>>>> You can also directly inject HttpServletRequest.
>>>>
>>>> Cheers,
>>>>
>>>> Robert
>>>>
>>>> On Apr 9, 2009, at 4/92:11 PM , daniel joyce wrote:
>>>>
>>>>> What about using a requestfilter? Any better docs on how to implement
>>>>> one? I see bits and pieces here and there, but nothing as coherent as
>>>>> the Dispatcher howto.
>>>>>
>>>>> -Daniel
>>>>>
>>>>>
>>>>> On Thu, Apr 9, 2009 at 11:38 AM, daniel joyce
>>>>> <daniel.a.jo...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I looked at spring security, and it required yet-another annotation,
>>>>>> and annotating a class to protect it didn't protect the methods as
>>>>>> well. This struck me as too hit-or-miss
>>>>>>
>>>>>> With Tomcat, I can simply protect whole paths or pages, no need to
>>>>>> worry about annotating a class, and then annotating each method. Bit
>>>>>> too fine-grained for my needs.
>>>>>>
>>>>>> On Thu, Apr 9, 2009 at 11:00 AM, manuel aldana <ald...@gmx.de> wrote:
>>>>>>>
>>>>>>> Maybe you should look at the tapestry-spring-security plugin
>>>>>>> (http://www.localhost.nu/java/tapestry-spring-security/index.html).
>>>>>>> It
>>>>>>> works
>>>>>>> great and integrating is also not that difficult.
>>>>>>>
>>>>>>> Good thing is that you can both secure by single page or by page
>>>>>>> folders.
>>>>>>>
>>>>>>> Beware that it is not compatible with 5.1.x yet (works only for
>>>>>>> 5.0.18).
>>>>>>>
>>>>>>> daniel joyce schrieb:
>>>>>>>>
>>>>>>>> So I want to use pages with context so that it is easily
>>>>>>>> bookmarkable.
>>>>>>>>
>>>>>>>> My website uses a DataSourcerealm to determine which pages can be
>>>>>>>> accessed by a user.
>>>>>>>>
>>>>>>>> So normal flow is user logs in, first page he gets directed to sets
>>>>>>>> up
>>>>>>>> the User object as a ASO, other pages use this user.
>>>>>>>>
>>>>>>>> But if he bookmarks a url with context, say
>>>>>>>> "configureProject/124332",
>>>>>>>> and he clickes on the bookmark, logs in to tomcat, and gets
>>>>>>>> redirected
>>>>>>>> to it, the User object may not have been initialized yet. Now
>>>>>>>> configure project is fine, since it is mostly working with projects.
>>>>>>>> But I want the user object to exist so that I confirm the user
>>>>>>>> actually owns it.
>>>>>>>>
>>>>>>>> Now I could have a basepage, whose onActivate() grabs the auth'd
>>>>>>>> user
>>>>>>>> string from the Httpsession, runs a query, and either sets up the
>>>>>>>> User
>>>>>>>> object, or bounces out the login page. And every other page could
>>>>>>>> inherit from this one, and call super.OnActivate in their onActivate
>>>>>>>> method.
>>>>>>>>
>>>>>>>> But I was wondering, is there a service I can write that can examine
>>>>>>>> the HttpSession, and populate the User object. Is HttpSession
>>>>>>>> available to services already? IE, can I inject it in the usual
>>>>>>>> method
>>>>>>>> via my builder?
>>>>>>>>
>>>>>>>> -Daniel
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> manuel aldana
>>>>>>> ald...@gmx.de
>>>>>>> software-engineering blog: http://www.aldana-online.de
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
