> Taavi, I like your controller ref/id idea, but I am going to start > without it just because I am not the XSLT pro I'd like to be.
If you like to read some tutorials about XSLT, I recommend you to check these: http://www.xfront.com/xsl.html At first I didn't like the idea that views call other Maverick commands (with jsp:include or for example with SiteMesh), but now I think that it is a proper way to do composite views that need data from many different, but separate actions. I mainly use three different controllers: a) BaseController that extends Throwaway2 - implements ModelLifetime (that closes Hibernate session) - processes both multipart and normal requests - populates this (with beanutils - but maybe I check ognl) - sets model as this Base controllers flow is something like this: go) ... return this.validate() validate) return this.authenticate() authenticate) return this.authorize(); authorize) return this.execute(); execute) return this.SUCCESS; b) ValidationController - extends BaseController - overrides validate - if this.getCtx().getParam("form") != null then validate - validation is done by FormProc. - return INPUT or super.validate(), whether validation succeeds c) AuthenticationController - extends ValidationController - overrides authenticate - I have my own database authentication routine - if user is authenticated then return super.authenticate() else return AUTH_REQUIRED or AUTH_FAILED d) AuthorizationController - extends AuthenticationController - overrides authorize - I have this.getCtx parameter caller rolesRequired - if user belongs to role then return super.authorize() else return AUTHORIZARION_FAILED That's it, :-)! Then if user needs to create controller that just populates, he/she extends BaseController and overrides execute. If user wants to validate, then he/she extends ValidationController and puts form parameter in place and overrides execute. If user wants to have authentication.... and so on? You might as that if user wants to have authorization but not validation, then what does he do? The overhead of checkin if form parameter is in place is not huge. Maybe I should create a few interfaces (eg. Validation, Authentication, Authorization) and then just check that and then user writes that he implements the interfaces he needs. And also this is easy to controller writer as only thin he/she needs to know is to extend correct controller and then just override execute. This is the base functionality I need. And I don't think that I use too much inheritance here and reusability is reosanable. I was whinking a lot about this controller chaining and I started the discussion some time ago. I did get great answers then and this discussion has been even better, but what I rhink right now is that to archieve the goal (that is composite view) is to use jsp:include or something similar (with sitemesh you can do this quite nicely). But maybe you requirements are different. Maybe you just want to execute one command in one request that graps the information out from several distinct commands and then you just have a view that outputs everything. I think that this way your model gets pretty confusing as it has everything from every command and the view is going to be quite complex (maybe I'm wrong). Only thing I need is SiteMesh to support Velocity (my view technology), but I'm quite comfortable with jsp and taglibs in decorators and velocity in those composite view components or whatever you call them. Kind Regards Aapo Laakkonen ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com [INVALID FOOTER]
