Hi. Reply inline.
On Wed, Jul 7, 2010 at 15:19, Marc Grue <[email protected]> wrote: > For my own needs I want to use Wicket for a more "down-up" approach where I > have a lot of customized (no-template friendly) Wicket Pages/Panels that > call/compose each other. That, I presume, moves the responsibility of > calling the Context away from a central place in the application layer > (like > CommandQueryRestlet) to the Wicket java Pages in the Web layer, right? Is > the difference wether or not the Context layer defines what part of the > domain (through Context) the Web layer can access in each particular page? > With the Streamflow approach I would need to change the Context layer (the > link building) if I wanted some link in my Web layer pointing to some other > part of the domain, or? > How about this approach? Object graph Page - Implement DCI \ Panel - Implement DCI \ AjaxSubmitButton (Persist) \ AjaxFallbackLink (Delete user) \ Form - User form - Implement DCI In Persist AjaxSubmitButton#onSubmit(AjaxRequestTarget target, Form form) { UserContext context = ContextHelper.applyContext( form ); context.update( ); } In Delete AjaxFallbackLink#onClick() { UserContext context = ContextHelper.applyContext( form ); context.delete(); } In Panel#applyContext( HasUserContext context ) { User user = getModelObject(); return context.user( user.identity().get() ); } In ContextHelper.getContext( Component component ) { Component parent = component.getParent(); if( parent == null ) { return null; } // Get contex Object context = getContext( parent ); if( component instanceOf DCI ) { DCI dci = (DCI) component; return dci.applyContext( context ); } return context; } With this scheme, Wicket component are "reusable", as we assume that the parent component knows how to navigate to "user context". Wicket > Wicket java Page runs the show: > - Wicket handles GET/POST > - RequestCycleProcessor.onBeginRequest(): newUnitOfWork() // should uow > start here or around each context call? > I'm not sure about this. Perhaps context? > - Wicket Page form (or any other component) calls the Context for data: > - UserDTO userDTO = getContext().user("123"); // retrieval through > interactions chain > - Wicket CustomForm("form", (IModel) userDTO); // some conversion of > userDTO > to a Wicket IModel > - Form/IModel is shown, edited and validated > - UserDTO userChangedDTO = (UserDTO) getModel(); // IModel cast back to a > UserDTO > - onSubmit(): getContext().user("123").update(userChangedDTO); > - Some redirect to results page > - RequestCycleProcessor.onEndRequest(): uow.complete() // or around each > context call > - Links with URLs to new pages are added/defined by current Wicket Page (in > Web layer) > Wicket Page done > > Other queries/commands examples: > userOrganizations = getContext().user("432").organizations().index(); > organizationUsers = getContext().organization("117").users().index(); > getContext().user("432").organizations().create(organizationDTO); > getContext().organization("117").users().create(userDTO); > etc. > > Am I on a viable path with this approach? Mis-/non-understandings, > pros/cons? > The con with this approach, the component is not reusable. > It seems as though Phil's solution to detache the session in > http://old.nabble.com/Web-framework-ts24548505.html#a24555233 > supposes to deal with EntityComposites (entities) extending EntityIModel > from within the Wicket layer. But isn't it better to receive DTO's from the > Context, change them and send them back to the Context for persistence (not > exposing the domain objects)? Or should I clone immutable ValueObjects? > Sorry, if I'm mixing up the terms. > To be honest, I don't know how to solve this issue generically. Correct me if I'm wrong, but I don't know how that approach works in "new entity + wizard" use case. Regards, Edward Yakop
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
