RE: [Mav-user] global views
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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of jim moore Sent: Thursday, February 14, 2002 9:41 AM To: [EMAIL PROTECTED] Subject: [Mav-user] global views I've finally ported both maverick projects I'm working on to mav 2, and so far I think it is great. The one small detail I don't quite get is the reasoning behind the way the global views are set up. In mav 1, a global view was truly global--every command got it by default. Now in mav 2, I need to explicitly declare a reference to the global view in each command: Why is this? I have 20 or so commands and 4 global views so far. That means I have to add 80 seemingly unncessary lines to my maverick.xml file. Is this to support shunting or something else that I haven't come across yet (so far I have just done the basic port from mav 1 to mav 2--haven't used any new functionality)? ___ 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
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
RE: [Mav-user] global views
I see what you are saying about cascading. Is this something like what you are talking about? 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
Re: [Mav-user] global views
i just noticed i forgot to close the view tags in the commands. should be: - Original Message - From: "jim moore" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, February 14, 2002 3:31 PM Subject: Re: [Mav-user] global views > I think the param in the config file may be too black and white. I kind of > like the direction Gerald is thinking. > > You could have something like: > > > > > > > > > > > > > > > > > > > > > > > > Group global could be a standard group--anything in there gets automagically > included in every command (though you are free not to use it if you want to > keep the commands self contained). Views in group "protected" get included > in a command if they specifically include that group ( group="protected">) under the command. The example above also shows a way to > allow multiple groups to share the same view by including it by ref. > > This was obviously put together pretty quickly, so it deserves some debate, > but its just what I was thinking right now... > > --jim > ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
Re: [Mav-user] global views
I think the param in the config file may be too black and white. I kind of like the direction Gerald is thinking. You could have something like: Group global could be a standard group--anything in there gets automagically included in every command (though you are free not to use it if you want to keep the commands self contained). Views in group "protected" get included in a command if they specifically include that group () under the command. The example above also shows a way to allow multiple groups to share the same view by including it by ref. This was obviously put together pretty quickly, so it deserves some debate, but its just what I was thinking right now... --jim ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
RE: [Mav-user] global views
The reason the original "global view" concept was dropped was a complaint on this list that it's easy to make mistakes. I ended up doing this myself accidentally a few times: It only has one view, so why bother naming it, right? It all works great until the rare circumstance that somebody tries to access the page without being logged in, in which case they get an exception instead of the usual "You must log in first" page. It's a terrible kind of error because it can go undiscovered for a looong time. If you have to explicitly specify each possible view, this problem won't come up. However, it sounds like there is a lot of desire to revisit the issue despite the risk. Maybe something like this? Another thing to consider is a suggestion that Chris Sturm made to allow an XSL transform of the maverick.xml before it is processed. With a transformation, it would be easy to create a config file like this: The XSL could add the two extra views (loginRequired and loginFailed) to any views with the protected attribute. Jeff Schnitzer [EMAIL PROTECTED] > -Original Message- > From: Gerald de Jong [mailto:[EMAIL PROTECTED]] > 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
Re: [Mav-user] global views
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?
>
>
>
>
>
>
>
>
> 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
Re: [Mav-user] global views
On Thursday 14 February 2002 22:21, Gerald de Jong wrote: > 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? btw, another way to represent an inheritance hierarchy in maverick.xml would be to use something resembling Ant's build.xml with its dependencies (rather than nesting the tags). with Ant you say depends="OtherTask", whereas in Java we would say "extends OtherClass", so maybe.. -- Beautiful Code BV Rotterdam, The Netherlands http://www.beautifulcode.nl ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
RE: [Mav-user] global views
An XML structure is *definitely* preferable; I've written both yacc-based and recursive descent parsers before, and it's wy overkill for this project :-) I'm starting to get a little worried about feature creep, so I have a proposal: Lets address the issue of how to make views global in a subsequent 2.1 release. In the mean time, I'll make the name attribute default to the ref so that can be used, which is a little shorter. I will also add the ability to specify an XSL for transforming the configuration before load. I'll get these features implemented RSN and launch another beta. When the manual is complete(ish), and there are no obvious outstanding bugs, we'll do the formal 2.0 release. Everything else gets slated for 2.1. Sound good? (this doesn't mean that the discussion should stop :-) Jeff Schnitzer [EMAIL PROTECTED] > -Original Message- > From: Gerald de Jong [mailto:[EMAIL PROTECTED]] > Sent: Friday, February 15, 2002 12:22 AM > To: [EMAIL PROTECTED] > Subject: Re: [Mav-user] global views > > On Thursday 14 February 2002 22:21, Gerald de Jong wrote: > > 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? > > btw, another way to represent an inheritance hierarchy in maverick.xml > would > be to use something resembling Ant's build.xml with its dependencies > (rather > than nesting the tags). with Ant you say depends="OtherTask", whereas in > Java we would say "extends OtherClass", so maybe.. > > > > > > > > > > > > > > > > > -- > 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
