Yeah, it's somewhat doing too much. However, the fallback scheme that
we have right now is somewhat magical also. I got actually confused at
first by the Index -> Default -> parent's Default scheme. The Default
class actually gets somewhat "inherited" but not the rest of the screen
classes. It strikes me as somewhat odd.
Anyway, the question I have is, what's the point of falling back the
Default to the parent's Default anyway? I assume the goal is that you
can reuse the group of Context objects that you stuff in the parent's
Default. If the parent's Default provides a "general" screen class for
the directory structure below it, it's actually harder to override this
behavior if the only thing you can override is the Default class. For
example, if I have Index.class, Foo.class, and Bar.class in the parent's
directory, I can't really override each of the classes individually in
the child directories. I have to put all the stuff into the
Default.class.
Will
> So okay, that will work. I'm still a bit worried about the possibility
> of invoking a screen class by accident (you have a template
> "foo/Index.vm" and it doesn't have a scren class, and then your top level
> Index.vm does have a class, and that class gets invoked for foo/Index.vm
> even though you didn't mean it. Seems like too much magic to me (at
> least if you have a class called Default it's pretty obvious that it may
> get invoked for a variety of reasons...)
>
> --
> Sean Legassick
> [EMAIL PROTECTED]
> Ek is 'n man: niks menslik is vreemd vir my nie
>
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
