(Tried to email this post directly to the mailing list yesterday, but it
didn't turn up here. Sorry if you got this (slightly modified) post twice -
in that case, please disregard the former post).
I hope that some of you can help me clarifying some issues about how to
access the Context layer in a Qi4j-Wicket-DCI setup:
In Streamflow, the DCI process flow seems to be "top-down" where
dci.api.CommandQueryRestlet has the central role of handling the whole life
cycle from all requests through URL mapping, Context/Interactions
mapping/processing, Template choosing/merging/rendering to final redirection
of response to the browser. I can see great benefits of minimal duplication
of trivial plumbing code with this generic approach.
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?
Could one compare the Context to the old Controller (in MVC) - at least with
regards to being an access point to the domain? Or is the Wicket Page in a
way the controller - a responsability distributor (still knowing only the
domain from the "outside" through the Context)? I guess some old terms don't
map to DCI...
Below I have compared the process flow of Streamflow to how I imagine I can
do in Wicket. I'm interested in hearing what pitfalls you see in my way of
calling the Context layer:
Streamflow
CommandQueryRestlet.handle(Request, Response) runs the show:
- Restlet handles GET/POST
- URL segments extracted from Request
- newUnitOfWork()
- DCI Context initiated, setting app root subContexts
- getInteractions() maps segments through the SubContext/Interactions chain
- Invoking found interaction (a context method corresponding to last segment
in the URL)
- Responsewriter merges result from interaction invocation with view
template and renders result to response
- Links with URLs to new pages are created in Contexts (URL composition
stays out of Web layer)
- uow.complete()
CommandQueryRestlet done
Wicket
Wicket java Page runs the show:
- Wicket handles GET/POST
- RequestCycleProcessor.onBeginRequest(): newUnitOfWork() // should uow
start here or around each context call?
- 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?
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.
Thanks for any input!
Cheers,
Marc
--
View this message in context:
http://old.nabble.com/Qi4j-Wicket-DCI-context-access-tp29093321p29093321.html
Sent from the Qi4j-dev mailing list archive at Nabble.com.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
