You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Ben Peter <bp...@zentropypartners.com> on 2002/03/13 08:57:36 UTC
Implementing HMVC with turbine
All,
after weeks of trying to implement HMVC with struts, I have now had a look at
turbine (which I find more flexible and 'clean' from a first look), of which
the documentation says that HMVC can be implemented, even if the straight road
does not lead you there.
Has anyone used turbine for that and can provide examples or a rough outline?
I have found that HMVC (Hierarchical Model-View-Controller) is the only way to
cleanly develop true 'components' which can be separately tested and very
easily reused. Still, I have not found a framework which has easy support for
this, so that I had to have my own implementations / extensions, which I do not
trust ;-) - for struts, they rely on doing subrequests, which is both costly
and unelegant...
Any help, suggestions, and comments are appreciated.
Cheers,
Ben
--
Benjamin Peter +49-69-96244395
Application Engineer Moerfelder Landstr. 55
(zentropy:partners) 60598 Frankfurt, Germany
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing HMVC with turbine
Posted by Ben Peter <bp...@zentropypartners.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Implementing HMVC with turbine
Posted by Jason van Zyl <jv...@zenplex.com>.
On Wed, 2002-03-13 at 02:57, Ben Peter wrote:
> All,
>
> after weeks of trying to implement HMVC with struts, I have now had a look at
> turbine (which I find more flexible and 'clean' from a first look), of which
> the documentation says that HMVC can be implemented, even if the straight road
> does not lead you there.
>
> Has anyone used turbine for that and can provide examples or a rough outline?
All things view related in Turbine are dealt with in templates, usually
velocity templates?
So are you looking for a hierarchical structure for visual attributes?
So if you have a tree for your site and a particular attribute isn't
specified you want a mechanism to walk back up the tree to find that
attribute? That would be easy relatively easy to do.
But if you mean programmatic components then I'm not quite sure what you
have in mind.
> I have found that HMVC (Hierarchical Model-View-Controller) is the only way to
> cleanly develop true 'components' which can be separately tested and very
> easily reused. Still, I have not found a framework which has easy support for
> this, so that I had to have my own implementations / extensions, which I do not
> trust ;-) - for struts, they rely on doing subrequests, which is both costly
> and unelegant...
>
> Any help, suggestions, and comments are appreciated.
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?
> Cheers,
> Ben
>
> --
> Benjamin Peter +49-69-96244395
> Application Engineer Moerfelder Landstr. 55
> (zentropy:partners) 60598 Frankfurt, Germany
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: many module.packages and velocity resource loader path
Posted by Gunter Miessbrandt <mi...@ixtern.de>.
Thanks,
that is it what i want to hear!!
;-)
Gunter M.
> -----Ursprüngliche Nachricht-----
> Von: Jason van Zyl [mailto:jvanzyl@zenplex.com]
> Gesendet: Mittwoch, 13. März 2002 16:05
> An: Turbine Users List
> Betreff: Re: many module.packages and velocity resource loader path
>
>
> On Wed, 2002-03-13 at 03:16, Gunter Miessbrandt wrote:
> > Hello List,
> >
> > if i have many entries in the following
> TurbineResources.properties lines,
> > is there an really noticeable impact on the performance of the wepapp,
> > because
> > turbine must search all these entries for needed templates or classes?
> >
> > module.packages
> > services.VelocityService.file.resource.loader.path
>
> If you have caching on the performance impact would be negligible. Once
> the template is parsed it is not parsed again (unless you have caching
> off).
>
> > Thanks
> > Gunter M.
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: many module.packages and velocity resource loader path
Posted by Jason van Zyl <jv...@zenplex.com>.
On Wed, 2002-03-13 at 03:16, Gunter Miessbrandt wrote:
> Hello List,
>
> if i have many entries in the following TurbineResources.properties lines,
> is there an really noticeable impact on the performance of the wepapp,
> because
> turbine must search all these entries for needed templates or classes?
>
> module.packages
> services.VelocityService.file.resource.loader.path
If you have caching on the performance impact would be negligible. Once
the template is parsed it is not parsed again (unless you have caching
off).
> Thanks
> Gunter M.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
many module.packages and velocity resource loader path
Posted by Gunter Miessbrandt <mi...@ixtern.de>.
Hello List,
if i have many entries in the following TurbineResources.properties lines,
is there an really noticeable impact on the performance of the wepapp,
because
turbine must search all these entries for needed templates or classes?
module.packages
services.VelocityService.file.resource.loader.path
Thanks
Gunter M.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>