Good points. On 2, I've noticed that I end up with lots of controllers, and there are a whole slew of named views which might be called. When I'm writing a controller, it's pretty clear to me which views are actually used, so I could easily enumerate them. On the other hand, trying to go through one controller manually after the fact (let alone 50) and weed out which views are used is error-prone. You know, some views could come from inherited classes or whereever. Without this feature, my tendency is to add in views left, right and center in the hopes of not missing one. I'm just suggesting that each controller has n different exit paths, and ensuring a one-to-one mapping is error-prone.
I'll look forward to your workflow system, Dan At 01:41 PM 7/22/02 -0400, you wrote: >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/
