> > It is generally possible to do both, perhaps through > a configuration switch that > controls whether to report errors on missing message > keys or to treat them as > the message.
I guess I don't really care about this one... Using keys all the time would actually be easier for me, since we only use keys, but I think you'll drive off new users or people just wanting to do something quick-n-dirty. > > I agree that we should move away from basically > requiring ActionSupport to be > extended, which is why I was wondering about the > possibility of moving those > *Aware interfaces over to Request to decorate the > Request instance. > We really need to specify what the thing called "Request" now is, and possibly break it up. It should DEFINITELY be renamed, since it's caused several of us to be confused. > > I'd like to see it implement Map directly, allowing > you to treat it as a simple > Map if your requirements are simple enough. The use > of standard collections is > something I'd like to retain from WebWork 2. > Uh... I think there's a fundamental disconnect between what you're saying, Don, and what Bob was saying / showing in code. I'm not particularly fond of either design yet... I just want ONE thing I can add messages to, easily, with easy to understand method names. > > > > I've been thinking Validatable should extend > ErrorAware, but I wanted > > to see what you guys thought first. I don't like > the idea of > > validate() return Messages. I never liked the fact > that I had to > > create an errors object in Struts. I also want to > be able to easily > > add validation messages from setters (I like doing > field level > > validation in the setter and cross field > validations in validate()). > > I think Jason had a good observation here concerning > ValidationContext. I like > having a context (or perhaps Request itself) that > implements Error/MessageAware > and have that passed around. I agree the user > shouldn't be creating this > themselves. I think we should be careful not to use what is now known as "Request" as a dumping ground for everything... There should be something to collect messages, but I'm not sure what it should be and how it fits in yet. > > > > This is something I've been kicking around since > generics came out. > > Now that we have generics, it seems funny to be > passing around a > > heterogeneously typed map. The new way results in > better type safety > > and less code. Here are some examples for > comparison: > > > > > > Testing is actually easier--it's easier to mock out > Attribute than Map. ... > While I can appreciate the type safety and perhaps we > do want to keep it as an > option, it just looks way to complicated for new > users. If people need to put > things in the session, they can just get the map from > Request and put it in > there. The annotations are nice, and would be an > interesting addition when we > do that layer. > I actually really like the Attribute stuff, but I'm not sure how easy it will be for new users to "get" it. Maybe I'm underestimating though... > > I talked with Pat about whether we should build an > abstraction layer > > over the servlet/portlet APIs, and we decided > against it. The portlet > > API really should have tried harder to embrace the > servlet API. To > > support the portlet API, we plan to implement a > servlet API adapter to > > it. > > Well, I'm of the opinion that the Portlet API > specifically shouldn't have > extended the Servlet API, but I think there is > something to use implementing > Servlet API classes with Portlet implementations. As > I've previously mentioned, > this is the approach Cocoon is either looking to do > or has done by now, and I > think we should work with them to complete that > library and perhaps move it to > Jakarta Commons. > Ugh... I really don't like that... really... seems like using an ugly hack instead of defining a higher-level abstraction. > > The deal breaker for me was that users will be able > to reuse the same > > code inside and outside of our framework. They > won't have to port > > their code from the servlet API to our new > abstraction API. And it > > makes less work for us and fewer new things for > users to learn. ;) Well, we can do that without tieing to HttpServletRequest and providing a hack to make a PortletRequest look like an HttpServletRequest. How about just higher-level abstractions which let you get to the stuff you need without knowing which one you're accessing? There are going to be Portlet specific and Http specific stuff that you're still going to need to get to the native thing anyway, so let's control the spots where the abstraction leaks... like a pressure valve :-) > > > > We've been playing with some ideas here. First off, > actions should > > pretty much never see this Request object. They > still get everything > > they need through the *Aware interfaces, etc. > > > > I'm thinking of creating an ActionContext interface > and moving all the > > information about the currently executing action > into there. Then we'd > > have Request.getCurrentActionContext(), and we > could even provide > > access to the contexts of other actions in the > chain if we need to. > > Hmm... I remember something about an ActionContext with information about the current Action execution... sounds familiar... :-) > > I'm not sure I understand what you mean about > moving the servlet > > methods into a separate interface. Can you provide > an example? To be > > clear, users wouldn't implement the Request > interface, but framework > > implementors would. > > What I'm talking about is making Request the > decorated core object used to share > and access information, however rather than build all > possible methods into it, > split them out in a similar way to *Provider > interfaces. Then, an advanced user > _could_ create their own Request object with special > application-specific methods. > > For example: > > o.a.s.action2.spi.ServletProvider > o.a.s.action2.spi.MessagesProvider > o.a.s.action2.spi.LocaleProvider > > then o.a.s.action2.spi.Request would extend all these > interfaces. Then, code > that uses the Request could only specify the more > specific interface like > ServletProvider, making it easier to mock and extend. > > I haven't thought it out fully, but I'm wondering if > that would help reduce our > need for a buff'ed up ActionSupport parent class. > I think what's needed here are some use cases... right now this conversation is lacking seriously in concreteness... --------------------------------------------------------------------- Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=57236#57236 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
