[Mav-user] Creating patches
Hey folks, Since there's no dev list for this projects, should we post / discuss possible patches here to this list? I haven't contributed to any open source before, so I don't want to break a rule of etiquette. Thanks, Roy --- 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] Creating patches
Thanks Scott.. I actually am on the list but not under the email address
that I thought. Here's the patch; very simple - the throwaway beans had
some Javadoc from an older version that threw me off when I was getting
started with them. I admit that this is a learning-to-use-CVS patch, but
I've got to start somewhere. :)
Thanks,
Roy
- Original Message -
From: "Scott Hernandez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, July 02, 2002 10:54 AM
Subject: Re: [Mav-user] Creating patches
> Yes, please send what you have to this list. If it is really big > 200k
(?)
> please just announce it and someone will contact you for the patch files.
>
> We are pretty laid back here, don't worry about etiquette. We try not to
:)
>
> Roy, you might want to check that you are on the list. I've cc'd you
because
> I had to approve this post because it didn't come from a subscribed email.
>
> - Original Message -
> From: "Roy Truelove" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, July 01, 2002 7:06 PM
> Subject: [Mav-user] Creating patches
>
>
> > Hey folks,
> >
> > Since there's no dev list for this projects, should we post /
discuss
> > possible patches here to this list? I haven't contributed to any open
> > source before, so I don't want to break a rule of etiquette.
> >
> > Thanks,
> > Roy
>
>
> ---
> 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/
Index: src/java/org/infohazard/maverick/ctl/Throwaway2.java
===
RCS file: /cvsroot/mav/maverick/src/java/org/infohazard/maverick/ctl/Throwaway2.java,v
retrieving revision 1.2
diff -u -r1.2 Throwaway2.java
--- src/java/org/infohazard/maverick/ctl/Throwaway2.java9 Jun 2002 22:10:43
- 1.2
+++ src/java/org/infohazard/maverick/ctl/Throwaway2.java2 Jul 2002 16:30:23
+-
@@ -34,7 +34,7 @@
/**
* Sets up the servlet parameters and calls through to the
-* parameterless rawPerform() method. Does not result in
+* parameterless go() method. Does not result in
* bean population.
*
* @see Controller#perform
Index: src/java/org/infohazard/maverick/ctl/ThrowawayBean2.java
===
RCS file:
/cvsroot/mav/maverick/src/java/org/infohazard/maverick/ctl/ThrowawayBean2.java,v
retrieving revision 1.2
diff -u -r1.2 ThrowawayBean2.java
--- src/java/org/infohazard/maverick/ctl/ThrowawayBean2.java9 Jun 2002 22:10:43
- 1.2
+++ src/java/org/infohazard/maverick/ctl/ThrowawayBean2.java2 Jul 2002 16:30:23
+-
@@ -33,6 +33,8 @@
}
/**
+* Populates this classes' bean properties, sets "this" as the model, and
+* calls through to the perform() method.
*/
protected final String go() throws Exception
{
[Mav-user] specifying redirects in the maverick.xml file
Hello all, I have a proposal to deal with redirects in the maverick.xml file. Right now redirect paths to commands have to be "hardcoded", insofar as you have to specify the redirect not as a logical command name but as a physical URL, i.e.: I'd like to write a patch that would support this type of functionality : As well as a standard redirect to a non-command: This way all references to commands are logical references rather than physical. If this sounds like a good idea, please let me know, and I'll get cracking. Thanks, Roy --- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. 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] specifying redirects in the maverick.xml file
Creating a custom view type is a good idea, but only if other people need this kind of functionality. I'm writing a workflow implementation that works with Maverick and will be using redirects very often (for internal "bookmarking" capabilities, etc.) My redirects will mostly be dynamically generated, and not specified in the XML config, so I'd need to know how to generate a full URL from just a command name. Having a view that does this for me would be useful. I proposed it as a patch because I felt for design reasons, it's best to keep URL's out of the config file and keep it all command-only. -Roy - Original Message - From: "jim moore" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 03, 2002 11:41 AM Subject: Re: [Mav-user] specifying redirects in the maverick.xml file > Personally I think this may just confuse things. Right now the behavior of a > redirect is pretty straightforward--its sending a physical redirect to the > browser, telling it to ask for the new url you specify (this could be a > .html, .jsp, .m, .fo, .pdf, /servlet/foo, whatever). I'm not sure I see what > we would achieve be redirecting to a logical view. Are you trying to avoid > the roundtrip to the browser and do something closer to a > RequestDispather.include() or RequestDispather.forward()? > > Either way, I don't think I'm in favor of compromising the > straightforwardness of the standard redirect view as right now it does > exactly what one would expect. That is not to say however that there is no > room for this functionality if you need it. Rather than modifying > RedirectView, why not take a stab at creating your own LogicalRedirectView, > which would take a maverick command as the path attribute, like so: > > > > Maverick is remarkably pluggable, so plugging in new view types is pretty > straigtforward. Check out opt-domify as an example of plugging in a custom > view type. > > --jim > > - Original Message - > From: "Roy Truelove" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, July 03, 2002 11:24 AM > Subject: [Mav-user] specifying redirects in the maverick.xml file > > > > Hello all, > > > > I have a proposal to deal with redirects in the maverick.xml file. > > Right now redirect paths to commands have to be "hardcoded", insofar as > you > > have to specify the redirect not as a logical command name but as a > physical > > URL, i.e.: > > > > > > > > I'd like to write a patch that would support this type of functionality : > > > > > > > > > > > > As well as a standard redirect to a non-command: > > > > > > > > This way all references to commands are logical references rather than > > physical. > > > > If this sounds like a good idea, please let me know, and I'll get > cracking. > > > > Thanks, > > Roy > > > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > No, I will not fix your computer. > > 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 > No, I will not fix your computer. > 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 No, I will not fix your computer. 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] specifying redirects in the maverick.xml file
I can dynamically generate redirects with no trouble using the RedirectView,
but (and I'm probably just being a stickler here) I'd have to hardcode the
URL in my Command classes, before I set it in the model. Technically, I'm
not supposed to know how these URL's are generated, since that's taken care
of with the web.xml file in the URL-Pattern. I'm talking about something
that does kind of the opposite of Dispatcher's extractCommandName(); it
would take a command and push out a URL to be redirected to. This is all
probably just my being design-anal and might not *really* matter...
Thanks,
Roy
- Original Message -
From: "Schnitzer, Jeff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 03, 2002 2:38 PM
Subject: [Mav-user] specifying redirects in the maverick.xml file
> [grrr, SF is bouncing mail from my normal account]
>
> I'm a little confused by what you want to do, but my suspicion is that
> maverick already supports it.
>
> All , , and elements can have
> child elements. These params are available in code from the
> {Controller|View|Transform}Context object.
>
> Redirect views support a number of ways of dynamically generating the
> target. Take a look at the javadocs for
> org.infohazard.maverick.view.RedirectViewFactory. If you set a String
> as the model, it becomes the base URL (the path attribute, if it exists,
> is ignored). Params (set either from the config file or from the
> Controller with ControllerContext.setParam()) become query parameters.
>
> Since you're probably generating the redirect path in your controller,
> perhaps what you want is a node on the element?
>
> Jeff Schnitzer
> [EMAIL PROTECTED]
>
> > -Original Message-
> > From: Roy Truelove [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, July 03, 2002 10:23 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Mav-user] specifying redirects in the maverick.xml file
> >
> > Creating a custom view type is a good idea, but only if other people
> need
> > this kind of functionality. I'm writing a workflow implementation
> that
> > works with Maverick and will be using redirects very often (for
> internal
> > "bookmarking" capabilities, etc.) My redirects will mostly be
> dynamically
> > generated, and not specified in the XML config, so I'd need to know
> how to
> > generate a full URL from just a command name. Having a view that does
> > this
> > for me would be useful.
> >
> > I proposed it as a patch because I felt for design reasons, it's best
> to
> > keep URL's out of the config file and keep it all command-only.
> >
> > -Roy
> >
> > - Original Message -
> > From: "jim moore" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, July 03, 2002 11:41 AM
> > Subject: Re: [Mav-user] specifying redirects in the maverick.xml file
> >
> >
> > > Personally I think this may just confuse things. Right now the
> behavior
> > of
> > a
> > > redirect is pretty straightforward--its sending a physical redirect
> to
> > the
> > > browser, telling it to ask for the new url you specify (this could
> be a
> > > .html, .jsp, .m, .fo, .pdf, /servlet/foo, whatever). I'm not sure I
> see
> > what
> > > we would achieve be redirecting to a logical view. Are you trying to
> > avoid
> > > the roundtrip to the browser and do something closer to a
> > > RequestDispather.include() or RequestDispather.forward()?
> > >
> > > Either way, I don't think I'm in favor of compromising the
> > > straightforwardness of the standard redirect view as right now it
> does
> > > exactly what one would expect. That is not to say however that there
> is
> > no
> > > room for this functionality if you need it. Rather than modifying
> > > RedirectView, why not take a stab at creating your own
> > LogicalRedirectView,
> > > which would take a maverick command as the path attribute, like so:
> > >
> > >
> > >
> > > Maverick is remarkably pluggable, so plugging in new view types is
> > pretty
> > > straigtforward. Check out opt-domify as an example of plugging in a
> > custom
> > > view type.
> > >
> > > --jim
> > >
> > > - Original Message -
> > > From: "Roy Truelove" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, July 03, 2002 11:24 AM
> > > Subject:
[Mav-user] Presentation workflow framework proposal (long)
Hello everybody, I have a proposal for a presentation workflow that I'd like to submit as a plug-in to Maverick. I've already started working on it so some of the functionality is already complete, but I'd like to run it by the list to see what functions people want / need in a presentation workflow framework. I'm sure there are situations that I have not considered that others have run into. Here is a rundown of what I'm starting with. * Functions * - A workflow is a set of commands (or states) that complete some "unit of work", i.e. registering for a site, completing a purchase, etc. Workflows can consist of any number of nested workflows. - Each workflow has a scope, and attributes added to that scope are only visible within that workflow. These are "workflow attributes". - Workflows can be written modularly. This means that one workflow can "call" another workflow to get something done. The caller can pass parameters to the callee, and the callee can return values to the caller. When the callee is complete it simply returns to the state specified by the caller. Calls are put on a stack to keep track of workflow attributes. - Workflows can have an entry point, meaning that if a user tries to enter that workflow s/he will be redirected to the entry point. - Workflows can be modal - the user cannot leave the workflow until the "unit of work" is complete. If they try to go to another page, they will be redirected back. The user *is* allowed to jump around within that workflow. - For workflows that must be completed step by step, states can be numbered within a workflow. A user will be able to go backwards in a workflow but not jump forward. * How it works (basically) * - Workflows are specified within the maverick.xml file. - Each Command class must subclass WorkflowCommand (which subclasses throwawaybean2. if you don't want to use throwawaybean2 you can create your own WorkflowCommand class.) The WorkflowCommand class processes each request to let the Workflow Manager know where the user is, if the user should be bounced somewhere else, etc. - When a workflow wants to call another workflow, it calls a GenerateCall() method which pushes the stack and redirects the client to the called workflow. The called workflow returns by calling generateReturn(), which pops the stack and redirects to the page specified. * Simple Example * A user wants to register for your website, but his company can't be found in your pulldown menu. You write a workflow of about 3 steps that lets a user type in a company, makes sure that the company is not in there (as an acronym or whatever) and lets the user create a company if it's not. This workflow returns a company_id to the registration workflow, and now that workflow can continue. That same "add company" workflow can then be used anywhere else in the application where a company needs to be added to your database. Thanks for any input, and thanks for reading this far. :) Roy --- This sf.net email is sponsored by:ThinkGeek Gadgets, caffeine, t-shirts, fun stuff. 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
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/
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: > > > > > 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 ema
Re: [Mav-user] Params w/child nodes
In the project that I'm working on params can have more than one value (I'm not using the maverick.xml file) I handle it like this : For single valued params : which is of course the usual. For multi-valued params : bar1 bar2 bar3 if the parser sees that the param tag has "value" children but no "value" attribute, it adds all 3 values to a Vector, and maps that Vector with the key "foo2". PS.. Even if the XML looked like this bar1 The data would be put into a Vector of size one, because if the user is using this syntax, then he expects a Vector. This is about as complex as I (hope to) get with my parameters; anything more than this I haven't touched. -Roy - Original Message - From: "Schnitzer, Jeff" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 25, 2002 7:05 PM Subject: RE: [Mav-user] Params w/child nodes > > From: Mike Moulton [mailto:[EMAIL PROTECTED]] > > > > I wanted to start a discussion about a TODO in the XML.java source > > relating > > to how params are handled. > > > > If you look at line 140-141 in XML.java in Mav 2.1.1 the following > todo > > will > > be found: > > > > // TODO: Maybe check to see if there are child nodes and somehow > > //include the child node objects in the map. > > > > For an upcoming project I would like to be able to define several > > configuration elements for retrieval as a single param in a > controller. > > Currently there is no way to do this, however it has obviously been > > thought > > of before. How can this best be approached to still allow the basic > > name/value params, as well as more complex params? > > How would you like it to work? > > How about something along the lines of > > if (paramNode.hasChildren()) > value = paramNode; // or maybe paramNode.getChildren()? > else > value = paramNode.getTextTrim(); > > Jeff Schnitzer > [EMAIL PROTECTED] > > > --- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > ___ > 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: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ 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] Params w/child nodes
> From: Mike Moulton [mailto:[EMAIL PROTECTED]] > Anyone see any problems with this approach? The only problem that I can see with this approach, > if (paramNode.hasChildren()) > value = paramNode.getChildren() > else > value = paramNode.getTextTrim(); is that the client code would have to deal with a List of JDom Elements, as opposed to a List of Objects. I originally had something like this, but I wanted all of the XML parsing to be abstracted out so the client code deals only with Objects. Do we want the client code to have to deal with XML in just this one case, where in all other cases it gets an object? This is not a problem as much as it is a design decision. -Roy > Solution is the best solution to our problem. > > Roy, it seems to me that this solution could also work for you. Obviously it > will require a little change in code, but it will allow you to use a stock > version of mav to support your custom param needs. > > > > -- > Mike Moulton > [EMAIL PROTECTED] > > > On 7/25/02 5:14 PM, "Roy Truelove" <[EMAIL PROTECTED]> wrote: > > > In the project that I'm working on params can have more than one value (I'm > > not using the maverick.xml file) I handle it like this : > > > > For single valued params : > > > > > > > > which is of course the usual. For multi-valued params : > > > > > > bar1 > > bar2 > > bar3 > > > > > > if the parser sees that the param tag has "value" children but no "value" > > attribute, it adds all 3 values to a Vector, and maps that Vector with the > > key "foo2". PS.. Even if the XML looked like this > > > > > > bar1 > > > > > > The data would be put into a Vector of size one, because if the user is > > using this syntax, then he expects a Vector. > > > > This is about as complex as I (hope to) get with my parameters; anything > > more than this I haven't touched. > > > > -Roy > > > > - Original Message - > > From: "Schnitzer, Jeff" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, July 25, 2002 7:05 PM > > Subject: RE: [Mav-user] Params w/child nodes > > > > > >>> From: Mike Moulton [mailto:[EMAIL PROTECTED]] > >>> > >>> I wanted to start a discussion about a TODO in the XML.java source > >>> relating > >>> to how params are handled. > >>> > >>> If you look at line 140-141 in XML.java in Mav 2.1.1 the following > >> todo > >>> will > >>> be found: > >>> > >>> // TODO: Maybe check to see if there are child nodes and somehow > >>> //include the child node objects in the map. > >>> > >>> For an upcoming project I would like to be able to define several > >>> configuration elements for retrieval as a single param in a > >> controller. > >>> Currently there is no way to do this, however it has obviously been > >>> thought > >>> of before. How can this best be approached to still allow the basic > >>> name/value params, as well as more complex params? > >> > >> How would you like it to work? > >> > >> How about something along the lines of > >> > >> if (paramNode.hasChildren()) > >> value = paramNode; // or maybe paramNode.getChildren()? > >> else > >> value = paramNode.getTextTrim(); > >> > >> Jeff Schnitzer > >> [EMAIL PROTECTED] > >> > >> > >> --- > >> This sf.net email is sponsored by: Jabber - The world's fastest growing > >> real-time communications platform! Don't just IM. Build it in! > >> http://www.jabber.com/osdn/xim > >> ___ > >> 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: Jabber - The world's fastest growing > > real-time communications platform! Don't just IM. Build it in! > > http://www.jabber.com/osdn/xim > > ___ > > 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] Params w/child nodes
Hey Mike, I'm sorry, I misunderstood what your aim was; I thought you were only looking for multi-valued params. If params can have *anything* underneath them, then the client code would have to do a bit of XML JDom work. I can't think of any other way around that either. -Roy - Original Message - From: "Mike Moulton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, July 27, 2002 3:19 PM Subject: Re: [Mav-user] Params w/child nodes > On 7/27/02 7:16 AM, "Roy Truelove" <[EMAIL PROTECTED]> wrote: > > >> From: Mike Moulton [mailto:[EMAIL PROTECTED]] > >> Anyone see any problems with this approach? > > > > The only problem that I can see with this approach, > > > >> if (paramNode.hasChildren()) > >> value = paramNode.getChildren() > >> else > >> value = paramNode.getTextTrim(); > > > > is that the client code would have to deal with a List of JDom Elements, as > > opposed to a List of Objects. I originally had something like this, but I > > wanted all of the XML parsing to be abstracted out so the client code deals > > only with Objects. Do we want the client code to have to deal with XML in > > just this one case, where in all other cases it gets an object? This is not > > a problem as much as it is a design decision. > > > > -Roy > > I understand you situation completely, however this functionality is exactly > what I am looking for as I will have quite an extensive document below the > param node for several controllers. For these cases I am expecting the > controller to handle the extraction of data as there is no way maverick can > know the structure of my document. > > I'm trying to think if there is a way that everyone can be happy, but > nothing comes to mind immediately. > > -- > Mike Moulton > [EMAIL PROTECTED] > > > > --- > 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] Assembling views
Hi Chris, I guess the main advantage of doing something like this is that each component would first go through a controller, as opposed to somethink like Tiles or JSP includes where this is not the case. Is that the only functionality that it would provide? Because it would seem easier to just do composites purely on the view side of things. I've never really had a need for my sidebar, header, etc. to have to go through a controller, but that doesn't mean that other people haven't. -Roy - Original Message - From: "Christoph Sturm" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 29, 2002 5:01 PM Subject: [Mav-user] Assembling views > Hey all! > > I'd like to implement some kind of component architecture on top of > maverick. All components are declared as normal maverick commands: > > > > > > > > > > > > > > > > > > One screen would then be configured like this: > > > > > > > > > > > > > > > > > > > > > page.vm would then look like this: > > > > > > $model.topnavi > $model.subnavi$model.content > > > This would make it really easy to create portal applications. It would > also have the advantage that one command only has to take care of one > thing, and it would be easier to reuse commands on different pages. > > This could also be implemented without really changing Maverick > One easy way would be to create a CompositeController, that gets the > page definition passed as child nodes in maverick.xml, or just the name > of the page definition as attribute. > > > class="com.schaumwelt.controller.CompositeController"/> > > > > (in this case it would look up the page named "mainBrowser" in a > different config file, call all the commands defined in it, and store > their result into a resulting model, which is then rendered through a > maverick pipeline. > > > What do you guys think? > > regards > chris > > > > > --- > This sf.net email is sponsored by: Dice - The leading online job board > for high-tech professionals. Search and apply for tech jobs today! > http://seeker.dice.com/seeker.epl?rel_code=31 > ___ > 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: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
[Mav-user] Presentaion workflow skeleton
Hey everyone, A skeleton for the presentation workflow extention (opt-workflow) is complete. I stress the word skeleton, because there should be enough there to give an idea of how the extention works and what it's capable of. You can download the src and read the documentation here : http://www.ietfwatch.net/opt-workflow Testing at this point has been minimal, but it is functional. There are two workflow implementations that need to be written (modal and wizard workflows). Javadocs should also be spruced up. If it seems a project worth pursing then I can work on making it CVS-worthy. Any and all feedback is *greatly* appreciated. Thanks, Roy --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
[Mav-user] Presentation workflow skeleton
Hey everyone, A skeleton for the presentation workflow extention (opt-workflow) is complete. I stress the word skeleton, because there should be enough there to give an idea of how the extention works and what it's capable of. You can download the src and read the documentation here : http://www.ietfwatch.net/opt-workflow Testing at this point has been minimal, but it is functional. There are two workflow implementations that need to be written (modal and wizard workflows). Javadocs should also be spruced up. If it seems a project worth pursing then I can work on making it CVS-worthy. Any and all feedback is *greatly* appreciated. Thanks, Roy --- This sf.net email is sponsored by: Dice - The leading online job board for high-tech professionals. Search and apply for tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31 ___ 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] Assembling views
way to do this through a CompositeView or something. I'll > >have a look at it this evening. > > > >-Thomas > > > >-Original Message- > >From: Christoph Sturm [mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, August 06, 2002 4:15 PM > >To: [EMAIL PROTECTED] > >Subject: Re: [Mav-user] Assembling views > > > > > >Hi Roy! > > > >Basically I am trying to archive just that. I dont want one controller > >for one screen, but one controller for one component, and screens > >assembled from these components. I could just include other commands > >from the view, and assemble my page there, this is how its done in > >webwork for example, maybe its better to do it like this. > > > >Either way it would just be great if I could get the result of a > >maverick command and its view viewpipeline in a string or a writer. An > >really easy solution to that that would be to change MaverickContext to > >be servlet-agnostic. That would make it easy for me to implement what I > >had in mind. > > > >regards > > chris > > > > > >Roy Truelove wrote: > > > > > > > >>Hi Chris, > >> > >> I guess the main advantage of doing something like this is that each > >>component would first go through a controller, as opposed to somethink > like > >>Tiles or JSP includes where this is not the case. Is that the only > >>functionality that it would provide? Because it would seem easier to just > >>do composites purely on the view side of things. I've never really had a > >>need for my sidebar, header, etc. to have to go through a controller, but > >>that doesn't mean that other people haven't. > >> > >>-Roy > >> > >>- Original Message - > >>From: "Christoph Sturm" <[EMAIL PROTECTED]> > >>To: <[EMAIL PROTECTED]> > >>Sent: Monday, July 29, 2002 5:01 PM > >>Subject: [Mav-user] Assembling views > >> > >> > >> > >> > >> > >> > >>>Hey all! > >>> > >>>I'd like to implement some kind of component architecture on top of > >>>maverick. All components are declared as normal maverick commands: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>One screen would then be configured like this: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>page.vm would then look like this: > >>> > >>> > >>> > >>> > >>> > >>>$model.topnavi > >>>$model.subnavi$model.content > >>> > >>> > >>>This would make it really easy to create portal applications. It would > >>>also have the advantage that one command only has to take care of one > >>>thing, and it would be easier to reuse commands on different pages. > >>> > >>>This could also be implemented without really changing Maverick > >>>One easy way would be to create a CompositeController, that gets the > >>>page definition passed as child nodes in maverick.xml, or just the name > >>>of the page definition as attribute. > >>> > >>> > >>>>>>class="com.schaumwelt.controller.CompositeController"/> > >>> > >>> > >>> > >>>(in this case it would look up the page named "mainBrowser" in a > >>>different config file, call all the commands defined in it, and store > >>>their result into a resulting model, which is then rendered through a > >>>maverick pipeline. > >>> > >>> > >>>What do you guys think? > >>> > >>>regards > >>>chris > >>> > >>> > >>> > >>> > >>>
[Mav-user] Using "decorator" pattern on controllers
Hey all, I'm looking into the feasablity of using the Decorator pattern* to create Controllers. In the friendbook example, each controller inherits from another controller which inherits from another controller, each one adding a little functionality. The problem with this is that you can't pick and choose which controllers you want to use, you have to use extentions of extentions. This would certainly help with the composite view issues that are being discussed, as well as securing controllers, etc. The problem is .. how can this be done while keeping Maverick backwards compatable *and* keeping configuration to a minimum? Any ideas? Since controllers are instantiated using reflections and not explicitly, is the Decorator pattern even possible? *Decorator pattern info : http://www.javaworld.com/javaworld/jw-12-2001/jw-1214-designpatterns.html -Roy --- 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] Using "decorator" pattern on controllers
Actually I just found the ControllerWithParams class in the Javadoc which is defined as a "a Decorator pattern, adding params defined for a controller". Are they any examples of how this is used? -Roy - Original Message - From: "jim moore" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 09, 2002 12:23 PM Subject: Re: [Mav-user] Using "decorator" pattern on controllers > This shouldn't be too difficult. Just have your decorator implement > ControllerSingleton, then you will get an init method in which the > controller node from maverick.xml is passed in. > > If you had a controller node that looked like: > > > > > > Your decorator could hold an internal controller. When the decorator's go > method was called, it could call go on the decorated controller, read the > result and the model, and still do its own thing. This is actually similar > to what I just sent as the CompositeController. > > --jim > > - Original Message - > From: "Roy Truelove" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, August 09, 2002 12:04 PM > Subject: [Mav-user] Using "decorator" pattern on controllers > > > > Hey all, > > > > I'm looking into the feasablity of using the Decorator pattern* to > > create Controllers. In the friendbook example, each controller inherits > > from another controller which inherits from another controller, each one > > adding a little functionality. The problem with this is that you can't > pick > > and choose which controllers you want to use, you have to use extentions > of > > extentions. This would certainly help with the composite view issues that > > are being discussed, as well as securing controllers, etc. > > > > The problem is .. how can this be done while keeping Maverick backwards > > compatable *and* keeping configuration to a minimum? Any ideas? Since > > controllers are instantiated using reflections and not explicitly, is the > > Decorator pattern even possible? > > > > *Decorator pattern info : > > http://www.javaworld.com/javaworld/jw-12-2001/jw-1214-designpatterns.html > > > > -Roy > > > > > > > > --- > > 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/
