|
Hello! Issue1: Hmmm, I remember fixing a bug related to
this. Try using the CVS version of
Maverick and let me know if it fixes the problem. The FormBeanUser
controllers should only be instantiated once, and there are no synchronization
issues (as long as you code your FormBeanUser
controller thread-safe, which should be easy). I seem to remember the synchronization/gc discussion was related to the performance (dis)advantages of pooling controllers – we don’t
do that. Issue2: I agree,
sophisticated inheritance chains become painful with ThrowawayBean-style
controllers. For most of my
personal work, I actually use ThrowawayFormBeanUser
to get the best of both worlds. Issue3: The friendbook
example shows you how to redirect to the correct page after logging in when you
went to a deep link without authenticating first. You could make the redirect a forward
instead if you want to. In either
case it goes to a different controller.
Perhaps I am misunderstanding your question? Jeff Schnitzer [EMAIL PROTECTED] -----Original Message----- Issue 1 It would seem to me on the surface,
that the FormBeanUser - Singleton is a better choice of controller for
scallable systems then the Throwaway controller but through the examples and
discussions in the past (Most notably "reusable controllers and session
objects") this is not the case. Also through my own tests with the
FormBeanUser, I noticed that it gets instantiated every time so how is it
considered to be a singleton. An issue raised in thread
"reusable controllers and session objects" was the case of GC vs
Synchronisation, well I wonder how much synchronisation there would be. The SingletonControllers could be
created at load time and I would not think there would be a requirement to
synchronize the look them up of when needed. And since they would act upon
FormBeans that would be created locally within the go method or passed in
externally, then there are no issues of synchronisation that I can see. Also the abillity to have multi
action controllers would be a simple to setup. Issue2 Which brings me to multiple actions,
There is a thread ( I can't find it at the moment ) about these where the reply
is to have multiple controllers instead of a controller with multiple
action methods. These controllers would all be deriving from a base controller
that can hand common issues such as exception handling, but since most of the
uses of the controllers that I have seen stem from ThrowawayBean2 which I
think implies that the model is getting mixed into the controller, I think that
having base controller functionality followed by form bean properties and
then followed by individual actions all in one class hierachy is
starting to get a bit deep and you've mixed data with action, which seems wrong
to me because form data may be resusable accross different action domains. Issue3 I have a login command that returns
the "home" view when the user successfully logs in. I was thinking that my login form
would generally be called from a user trying to access a protected page in
which case I would want to redirect to that page after login, or alternatively
a prewritten url such as
/login.m?user=dave&password=newbie&fowardto=todo. which could attempt
login and if successfule call the todo command. From what I can tell, the result of
commands is just a string representing global views or embedded views in the
command, what if I wan't to halt proccessing of the login controller once the
user is validated and redirect through to a different controller (which has its
on view). Esentially I want to change controllers on the fly. Now I know that an answer for
this particular situation is to put the login code into the base
controller as is the case with sample app, but I don't wan't to do it this way,
plus I can see other reasons for having the ability to change controllers on
the fly anyway. How do I acheive this ? Issue4 Maverick is Brilliant, Die Struts
Die Cheers Dave the Newbie And the lord said unto the
Java-Guru, have mercy on the newbie for he/she is a dumbass who does not know
what their saying. |
- [Mav-user] Best Practices Please David Cruwys
- Re: [Mav-user] Best Practices Please Eelco Hillenius
- RE: [Mav-user] Best Practices Please David Cruwys
- RE: [Mav-user] Best Practices Please Schnitzer, Jeff
- RE: [Mav-user] Best Practices Please David Cruwys
- Re: [Mav-user] Best Practices Please Eelco Hillenius
- RE: [Mav-user] Best Practices Please David Cruwys
- [Mav-user] Internationalization David Cruwys
- Re: [Mav-user] Internationalization Eelco Hillenius
- Re: [Mav-user] Internationalization Eelco Hillenius
- Re: [Mav-user] Internationalization toby cabot
- RE: [Mav-user] Best Practices Please Schnitzer, Jeff
- RE: [Mav-user] Best Practices Please Eric Kreiser
