[Struts Wiki] Update of RoughSpots by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/RoughSpots -- * [jcarreira] I can attest that the Spring scoped components work well with WebWork. It's what we use at work for maintaining session or request state. * [plightbo] Let's not dismiss Tim's comments too quickly. While we might not implement a solution exactly like he suggests, his point is valid that handling state management in WebWork has always been a very week area. The ScopeInterceptor isn't a great option either, especially considering one of my other issues specifically asks that we avoid having to create custom interceptor stacks for various actions. * [jcarreira] I'm open to hearing good ideas for state management. Especially short-lived wizard type state. Long lived session state (things like your user profile) work really well as Spring session-scoped components, but state which is just used for the next 4 or 5 pages isn't such a good fit. + * [MJ] I think talking in terms of pages does not really get us further from ancient SAF1 practices. A web resource can have one view (page) or ten. A wizard can have ten pages defined, but it can use only 3 or 5 of them depending on current state and transitions. It is better to think in terms of web resources, and when it goes out of scope. A wizard is a distinct web resource, who cares how many pages it has. I have built a wizard engine a year ago, and it proved its viability and robustness. No XML, by the way. Check the [http://www.superinterface.com/wizard/signupWizard.do sample]. Try to break it with Reload, Back and Forward buttons. The wizard code hasn't been changed for almost a year, which shows the maturity. I can provide the code and the docs if there is interest. I know that Tim as well as Jason dislike session-scoped data. I hope you guys change your point of view. + * [MJ] In regards to wizards and Redirect-After-Post pattern, does Webwork have something like FlashScope? FlashScope works for only one redirect call, so there may be something longer than FlashScope, but shorter than session. At best, it would be great if a stateful component like a wizard, could be assigned to its own FlashScope+ . 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and maybe more importantly, it wouldn't automatically be available to helper classes as it is as a !ThreadLocal. That would address my concern about inappropriate usage of !ActionContext. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/RoughSpots -- Some things that could be addresssed before Action 2.0.0. (If we don't address them, we'll be stuck supporting them throughout all eternity or until Struts 3.0.0, whichever comes first. ;)) - We have a small number of existing WebWork users compared to the number of Struts users we'll (hopefully) eventually have. This is a new framework (if only in name) and a major release. This is our one chance to break compatibility. We must get it right now, because we will *not* be able to fix most of these problems later (the cost of breaking existing Struts users will almost always outweigh the value of the fix). + We have a small number of existing !WebWork users compared to the number of Struts users we'll (hopefully) eventually have. This is a new framework (if only in name) and a major release. This is our one chance to break compatibility. We must get it right now, because we will *not* be able to fix most of these problems later (the cost of breaking existing Struts users will almost always outweigh the value of the fix). We do not need to expose Struts users to XWork; they do not care. At the very least we should build a thin abstraction layer to isolate users from XWork. XWork should be an implementation detail not part of the SAF API. We can make most of the following changes in SAF's abstraction layer and avoid breaking existing XWork users. @@ -220, +220 @@ 1. How does WW help the user with state management? As far as I can tell, if I want to keep a 'user' object around I have to interact with the map returned by ActionContext.getSession(). Actions should in general have a type-safe and transparent way to do this, e.g. by subclassing ActionContext and providing getUser()/setUser() which store the user in session. This allows for re-working of the storage strategy (e.g. write a cookie and lookup the user each time) without affecting actions. 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). 1. HTML analog tags should stick to HTML attributes. I dont' mean they shouldn't have more functionality, but the attributes should be identical where possible, and they shouldn't do things like render a label and an input. Keeping them more like regular HTML tags makes them easier to ramp up on, and more non-developer friendly + * [MJ] I see the following options when it comes to tags. (1) Use plain HTML + implicit scoped variables like actionName, actionAddress, etc. to create dynamic values; this looks pretty compact with JSP 2.0. (2) Use 1:1 relation between WW tags and HTML tags. (3) Use 1:M relation between WW tags and HTML tags, like to create data entry form or a table. (4) Use non-HTML-looking tags + more abstract attributes + media attribute, thus creating something like JSF renderer for different media. Choosing between (1) and (2) I prefer the first one. 1. Actions should return concrete objects, not symbolic results. Symbolic results might have been optimal when you had one event/method per action and the outcomes were always whole-page views, but they get in the way now. When you want to return anything that requires more than the symbol, you have to do some less than intuitive things to make the Action and the Result cooperate. I'd prefer to see a concrete Result get returned from Action methods, which would allows developers to do more powerful things more easily. There are a bunch of ways to make it backward compatible too. You could return 'new SymbolicResult(success)' and have the SymbolicResult do the lookup stuff (You could even redefine the String constants to be SymbolicResults). You could alternatively use a static class to do Results.find(SUCCESS). Or you could even allow method to continue to return String or Result, and if String wrap it in a SymbolicResult. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/RoughSpots The comment on the change is: XML-free configuration if JDK 1.5 is the target -- * [jcarreira] We've been using JDK 1.5 on Tomcat 5+ for over a year... Everything we write and wire together is using generics and annotations. * [crazybob] +1 for JDK 1.5 since it came out. I have a lot of code I could contribute which depends on the new concurrency libraries, etc. + * [MJ] With JDK 1.5 as a requirement for SAF2-based projects, users may be inclined to take a look at [http://stripes.mc4j.org/confluence/display/stripes/Home Stripes] first. It is compact, it features event-dispatching, built-in validation and conversion, Action and !ActionForm being one entity, and it allows to forgo XML config files by using annotations. The last feature alone is worth sack o'gold. If SAF2 is going to require JDK 1.5, it should allow XML-free configuration, at least for simple use cases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/RoughSpots The comment on the change is: Plugged in EventActionDispatcher information -- 1. `TextProvider` is a bad name. The JDK refers to these as messages everywhere. - 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... + 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... (MJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. Also, these links might help: DataEntryForm, EventActionDispatcher) 1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. I think we should rename these `#request` for request parameters and `#requestAttributes` for request attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
