William Lee wrote:
>
> Actually, looking for the screen class before changing the template
> doesn't really work. The TurbineTemplateService actually looks for
> whether the template exists (in the /template/screens/ directory) before
> return the screen class. Since my template is in screens/html/en/Index
> but not in screens/Index, it would complain. Thus, I need to change the
> template before looking for screen.
>
> Anyway, I think I have a patch on changing this search sequence for
> loading the screen class. I just wonder if anyone is interested.
>
Hmmm, this is a problem without a quick and good solution. (Unless I am
wrong and I start to like your solution.) The main problem I have with
adding the addition class check at every level is that implies that
there might be some reason that you would want to have
screens.Index and a screens.es.Index classes.
We are trying to work towards reducing the template dependence on
specific Screens, so even if there are reasons it might make sense to
have such an arrangement I think it is better to try to come to a
solution that avoids it.
So then the only reason to have the fall through is because you would
never have a screens.es.Index class.
I do not have a solution to offer, but I think we need to explore the
reason we cannot apply a simple solution which would be to avoid the
multiple template roots that require us to locate the template prior to
the mapping. First off, the multiple path possibility as it currently
exists is not too useful, for one thing you cannot have similar relative
paths within the different roots. So you cannot have for example
Index.vm at the top of both roots. Only one of them will ever be
chosen.
I think the multiple path possibility as it currently stands could be
dropped, but maybe someone who is using it could explain its benefit.
But we should not just drop it, because ...
We need to come up with a better way to support multiple roots that
distinguishes one from another, so that we could for example support
pluggable applications. Someone proposed a solution some time ago but
unfortunately I dropped the ball on it. Was it you, Santiago Gala?
Recent discussions regarding multiple Turbine applications in one JVM
have also occurred, so hopefully the grand solution that supports
multiple applications and language support is just around the corner.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
