Just a couple comments: In Maverick 1.0, global views were automatically visible from all commands. While this did provide a more terse syntax for the config file, it tended to result in a lot of programming mistakes, both name collisions and "forgetting" to name views because it looked like there was only one view to be used.
There are a couple ways of simplifying the config file though. The first is that you can specify an XSLT transformation which is run against the config file just prior to processing. So you could define commands like this: <command name="foo" requireSession="true"> ... </command> And have an XSLT that that adds your extra views when the requireSession attribute is found. This is a lot more flexible than building some sort of namespacing facility into Maverick. The other thing you can do to simplify your maverick config file is to split it up into separate individual files. No maverick features are necessary; this can be done by using the ENTITY features of XML parsers. A good explanation for how to do this can be found here: http://www.docbook.org/tdg/en/html/ch01.html#s-entities Dan, if all you're trying to do is remember state so that (for instance) a user can be redirected to the original destination after logging in, this is pretty easy to do - just store the destination in the session attributes. A workflow framework might be nice, but it's pretty easy to do by hand. Jeff Schnitzer [EMAIL PROTECTED] P.S. Today I officially left the fun-filled world of free agency and became a Maxoid! :-) So much for free time! P.P.S. If anyone is in the San Francisco area tomorrow (7/23) night, I'm hosting a dinner party at my new digs in the Mission. Scott will be there too. Email me privately and I'll send details. > -----Original Message----- > From: Roy Truelove [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 22, 2002 10:42 AM > To: [EMAIL PROTECTED] > Subject: Re: [Mav-user] Work Flow > > From: "Dan Finkelstein" <[EMAIL PROTECTED]> > > I thought I'd throw in my 2 cents worth on this workflow issue in > relation > > to Maverick. I have developed a fairly large application under Maverick > > and have found the maverick.xml file to have grow somewhat unwieldy. I > > think that with some sort of abstractions added to the maverick.xml > > features, it could be pared down quite a bit -- some of this might fall > > under what you're calling workflow. Here's what I mean: > > > > 1. All my commands include the following two views: > > > > <view name="noSession" ref="noSession"/> > > <view name="systemError" ref="systemError"/> > > > > These two lines are repeated many times through my mav.xml file. It > would > > be nice if when a command were run, that if the view wasn't specified, > it > > would look in some default place. Since putting "code" in one and only > one > > place is a desirable, then this would help with the understandability > and > > maintenance of the codebase. > > I agree with you on this, but I don't think it's in the scope of what I'm > working on. When I first started using Mav, I figured that since I'm > specifying "global" views with the "views" tag, then they shouldn't need > to > be referenced in each command. I believe that something like this would > require a patch to the current source, and not an addon, but it would be > nice to have. > > > 2. If I happen to be missing a view, I don't know about it until the > > program is run and happens across this issue. It would be nice if the > > controller had an ability to accept a list of views that it needs. We > can > > create this list for each of our controllers -- that's no big deal. > Then > > Maverick could on startup, check that no views are missing from the > mav.xml > > file. Maybe a method like String [] getRequiredViews(). > > I don't follow you on this one. If you're going through the trouble of > making a list of views per controller, can't you just check your xml file > to > make sure that each controller has it's appropriate views? Seems like > double work, if I'm understanding you correctly. > > > 3. Some sort of namespace convention might also be nice. For example, > I > > have two main areas in my mav.xml file, one area for the main site and > > another for admin. The admin stuff is intermingled with the main site > > stuff and it is only through naming conventions that I keep them > separate, > > but it has been the source of a few bugs. I have thought of separating > > these two areas into two different war files, which would solve the > > problem, but perhaps there is a structure within mav.xml that can > encourage > > separation also. > > So each command would have a name and an optional namespace? I can > understand your need for that, but again, that's out of the scope of the > project I'm working on. After working on huge projects using Struts, I've > gotten very good at creating naming conventions for my commands and views, > and grouping them in the XML file. Given Mav's philosophy, adding a > namespace might add unnecessary complications. > > > 4. Regarding workflow in particular, I also have come across cases where > I > > would have liked to "remember" state as I go through a sequence so I can > > return to it. For example, it a "visitor" or "guest" tries to access a > > page that requires logging in, I would like to take them to the login > > workflow, and at the end of that workflow return them to the page they > > wanted to access in the first place. This would be such a cool and > > powerful feature. I haven't figured out a way to do this within the > > current system. > > This is the kind of functionality you'll be able to get (and more!!) with > the project I'm working on. A command generates a "call" to a workflow > (in > this case, the workflow handles logging in a user) and after that workflow > does it's thing, it returns to where it's told. I'm trying to make it as > flexible and extendable as possible, so people who have special needs from > a > workflow can create their own and plug it in. > > > Please take these comments within the context they are given: I am a > very > > happy and satisfied Maverick user, and would make the same decision to > go > > with mav today even knowing these limitations! > > > > Dan > > > > > > At 07:19 PM 7/18/02 -0400, you wrote: > > >Hello Scott.. > > > > > > I'm going to try to throw a skeleton together so that it can be > added to > > >the CVS, so people can help out as they wish. Hopefully early next > week > (?) > > >there'll be enough for people to follow what's going on and see where > they > > >can help. > > > > > >-Roy > > > > > >----- Original Message ----- > > >From: "Scott Bechtel" <[EMAIL PROTECTED]> > > >To: <[EMAIL PROTECTED]> > > >Sent: Thursday, July 18, 2002 4:20 PM > > >Subject: [Mav-user] Work Flow > > > > > > > > > > Hey guys, > > > > I'm very interested in the work flow system since I am ready to > create > a > > >web > > > > site that requires one. If you need any assistance in coding or > testing > > >be > > > > in touch. > > > > > > > > Scott Bechtel > > > > [EMAIL PROTECTED] > > > > www.newconquest.com > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > _______________________________________________ > > > > Mav-user mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/mav-user > > > > Archives are available at http://www.mail-archive.com/ > > > > > > > > > > > >------------------------------------------------------- > > >This sf.net email is sponsored by:ThinkGeek > > >Welcome to geek heaven. > > >http://thinkgeek.com/sf > > >_______________________________________________ > > >Mav-user mailing list > > >[EMAIL PROTECTED] > > >https://lists.sourceforge.net/lists/listinfo/mav-user > > >Archives are available at http://www.mail-archive.com/ > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Mav-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/mav-user > > Archives are available at http://www.mail-archive.com/ > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mav-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mav-user > Archives are available at http://www.mail-archive.com/ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
