would you call it sloppy if we changed the word "cascading" into
"inheritance"? virtually the same thing happens in your java code, so why
not in the maverick.xml command hierarchy?
wait, i'm on a roll here... hows about reusing the notion of "class" instead
of what we might have been calling "command group". think of the commands as
the methods, and the views as fields.
package maverick.xml;
class city {
view failure;
view needLogin;
view logout;
class street {
command walkTheCat();
command eatDinner();
view dinnerTable;
view failure; // overrides city's failure
}
class office {
command thinkHard();
command goofOff();
view working;
view relaxing;
}
}
gotta admit, people coding with maverick will be all too familiar with java
class semantics (such as scoping, overriding). might get an even more "oh
yeah.. of course" newbie response than maverick is already getting
(medallions were already being minted).
On Thursday 14 February 2002 21:22, Scott Hernandez wrote:
> I see what you are saying about cascading.
>
> Is this something like what you are talking about?
>
> <!-- Global views -->
> <views global="true">
> <view ..../>
> <view ..../>
> <view ..../>
> </view>
>
> So that any views element with a global attribute of true should be
> inherited for each command? Then the collection of views for any command
> would be the set of "Global" views with local views mapped over?
>
> I think that we do need to do something like this. But I want the
> default behavior to not be sloppy, like 1.0 was. I want it to be much
> more clear where the definition for each view comes from and what is
> available to the controller for any given command.
>
> Thoughts?
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Gerald de
> Jong
> Sent: Thursday, February 14, 2002 12:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [Mav-user] global views
>
> when i first understood the "global view" concept (no name for it at the
> time) i assumed it was a hierarchical thing. i figured you could corral
> a
> bunch of commands together and give them a few views to fall back on.
> turns
> out they were truly global. i was thinking "cascade".
>
> what say we talk about groups of commands with groups of default views?
> make
> just one of these groups and you've got the elegance of 1.0. make a
> whole
> bunch of them and you can get granularity as high as you please.
>
> you end up with a "command-set" rather than a single "command" being
> self-contained.
>
> isn't this a good way to scope views?
>
> On Thursday 14 February 2002 20:34, Scott Hernandez wrote:
> > Before I go into a discussion of the why... Let me ask this:
> >
> > Should there be an option to have global views work they used to? (I
> was
> > thinking along the lines of a param for the config file to switch
> modes)
> >
> >
> > -----------------
> > Jeff and I spent a good amount of time discussing this since the 1.0
> > release. What we wanted to provide was a way to define global views,
> > like we already had, but not always to copy them into each command. We
> > basically wanted to be able to guarantee that a command could be
> > self-contained. If you looked at the command def, you would see all
> view
> > paths out. This led us down the road of global views with local
> command
> > refs.
>
> --
> Beautiful Code BV
> Rotterdam, The Netherlands
> http://www.beautifulcode.nl
>
> _______________________________________________
> Mav-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/mav-user
>
> _______________________________________________
> Mav-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/mav-user
>
>
--
Beautiful Code BV
Rotterdam, The Netherlands
http://www.beautifulcode.nl
_______________________________________________
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user
