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
