Re: [Mav-user] Work Flow
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. 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(). 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. 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. 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/
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
RE: [Mav-user] Work Flow
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
Re: [Mav-user] Work Flow
: 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/
