Jason van Zyl wrote:
>
> We are definitely interested in reuse. Can you give an example of a
> small component that you would like to applied in a hierarchical way?
>
Jason,
thanks for your answer. I will be a bit more detailed with what I mean and use
an example from my current project.
Two components are involved: a car configurator, which allows you to select the
exact model, engine, accessories, etc. of a car (that, e.g., you want to
order). The second is a finance calculator, which runs along with the
configurator through all steps and gives you financing options, along with the
terms that result on the options you selected. The amount that the calculator
works on is that of the car in the current status of configuration.
Now, it would be good if both of these components could make use of the whole
set of options made available by turbine. For both it makes sense to have their
own way through the MVC implementation, so that each can choose the appropriate
view for the current state in their Action, etc.
To make that possible, the easiest way is to develop each such component as
individual applications and later assemble them on one page which the is a
container. This is where the hierarchy comes in. A container needs only put
together the components needed and have them available in the view to display
the result.
The effect that is reached is very close to what could be achieved with html
frames - once such a component is developed it can be reused in virtually any
place and any application. These components could even be thought of as
`widgets' in classic windowing terms. Components can `communicate' through
request- or session-scope, depending on the implementation (the finance
calculator needs to know the price that it is supposed to work with).
To sketch a use case, I can outline how the implementation that I have made for
struts would be used to handle above scenario.
Container Action:
handleRequest(...) {
Include.performInclude("configurator", "/components/configurator.do");
Include.performInclude("calculator", "/components/calculator.do");
return mapping.findForward("display");
}
the jsp:
<!-- some surrounding html -->
<include:printResult key="calculator"/>
<!-- more html -->
<include:printResult key="configurator"/>
<!-- still more -->
It is important that the include (this is NO include that can be made with
RequestDispatcher) is done in the Controller, as order may matter. If the
include is made from the view, the needed order of functionality dictates the
order of elements in the view, i.e. the configurator (from which the calculator
needs to know the new price) could not appear after the calculator on the screen.
In above example, each of the two components have their own action and view
associated with them and do not depend on the context in which they are used,
only that the calculator expects a price to operate on in a defined request
attribute.
The two components can be reused anywhere they are needed. That way, the
calculator could easily be reused to finance a totally different type of product.
Of course, there is no need to stop at two levels in the hierarchy. Each of the
components could again use other components (which in fact they do), and these
even more.
I hope I could clarify my question a bit without writing too much.
Cheers,
Ben
--
Benjamin Peter +49-69-96244395
Application Engineer Moerfelder Landstr. 55
(zentropy:partners) 60598 Frankfurt, Germany
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
